Home > vSphere API > How to Set up Connection Timeout in VI Java API

How to Set up Connection Timeout in VI Java API

Per community requests, two methods were added into VI Java API 2.1 (GAed last summer) for changing the default connection and read timeouts. Both methods are defined in WSClient.java.

The first method setConnectTimeout() sets a specified timeout in milliseconds. It intends to be used when opening a communications link to the resource referenced by the URLConnection inside the WSClient object. If the timeout expires before the connection can be established, a java.net.SocketTimeoutException is raised. A timeout of zero is interpreted as an infinite timeout.

Time to learn how to "Google" and manage your VMware and clouds in a fast and secure

HTML5 App

The second method setReadTimeout() sets a specified time in milliseconds. It intends to be used for reading from the server when a connection has been established. If the timeout expires before there is data available for read, a java.net.SocketTimeoutException is raised. A timeout of zero is interpreted as an infinite timeout.

Since these two methods are not commonly used, it’s only defined at WSClient.java type. To access them, you just need to get hold of the WSClient object, which may not as straight-forward as you expect it to be. But here is a quick sample:

WSClient wsc = si.getServerConnection().getVimService().getWsc();
wsc.setConnectTimeout(30*1000);
wsc.setReadTimeout(10*1000);

Note that the si variable is the reference to a ServiceInstance object. Because getServerConnection() is defined in ManagedObject type, so you can use any reference to a VirtualMachine, HostSystem, etc.

Categories: vSphere API Tags:
  1. Thulasinathan Kandasamy
    May 4th, 2011 at 09:53 | #1

    Hi Steve,

    It’ll be helpful if we can specify the timeout values in the ServiceInstance constructor itself. How does the connection timeout help if we have already got the instance of ServiceInstance?

    In a WebService wouldn’t it be better to have a single ServiceInstance created and shared by all the requests for that WebService?

    Regards,
    Tulsi

  2. May 4th, 2011 at 10:11 | #2

    Hi Thulasinathan,

    It helps even if you have the instance already. If you look into the code WSClient.java, you can find the details.

    You guessed right – you’d better share the ServiceInstance. I have another article on scalability with shared connection. Just search it.

    Steve

  3. Thulasinathan Kandasamy
    May 6th, 2011 at 10:42 | #3

    Hi Steve,

    We thought this may be useful to you. On one of the hung threads we got the following trace.

    java.lang.Thread.State: RUNNABLE
    at java.net.SocketInputStream.socketRead0(Native Method)
    at java.net.SocketInputStream.read(SocketInputStream.java:129)
    at com.sun.net.ssl.internal.ssl.InputRecord.readFully(InputRecord.java:293)
    at com.sun.net.ssl.internal.ssl.InputRecord.read(InputRecord.java:331)
    at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:789)
    – locked (a java.lang.Object)
    at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1112)
    – locked (a java.lang.Object)
    at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1139)
    at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1123)
    at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:434)
    at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:166)
    at sun.net.www.protocol.http.HttpURLConnection.getOutputStream(HttpURLConnection.java:904)
    – locked (a sun.net.www.protocol.https.DelegateHttpsURLConnection)
    at sun.net.www.protocol.https.HttpsURLConnectionImpl.getOutputStream(HttpsURLConnectionImpl.java:230)
    – locked (a sun.net.www.protocol.https.HttpsURLConnectionImpl)
    at com.vmware.vim25.ws.WSClient.post(WSClient.java:249)
    at com.vmware.vim25.ws.WSClient.invoke(WSClient.java:175)
    at com.vmware.vim25.ws.WSClient.invoke(WSClient.java:123)
    at com.vmware.vim25.ws.VimStub.retrieveServiceContent(VimStub.java:1449)
    at com.vmware.vim25.mo.ServiceInstance.(ServiceInstance.java:85)
    at com.vmware.vim25.mo.ServiceInstance.(ServiceInstance.java:69)
    at test.VCenterConnection.initServiceInstance(VCenterConnection.java:280)
    at test.VCenterConnection.getServiceInstance(VCenterConnection.java:343)

    Regards,
    Tulsi

  4. May 6th, 2011 at 17:43 | #4

    Thanks Tulsi, it’s useful. It seems like the hanging happened during handshaking. Do you know the root case? certificate? Thanks!
    Steve

  5. Thulasinathan Kandasamy
    May 13th, 2011 at 10:58 | #5

    Steve,

    We don’t know the root cause. Certificate is a suspect too.

    Regards,
    Tulsi

  6. Mike Matczynski
    July 14th, 2011 at 09:56 | #6

    Hi Steve,

    We’re also seeing the same problem as Thulasinathan on the initial vijava connect. It would be great if we could pass in arguments via the constructor, or maybe add a context object that can hold miscellaneous parameters like timeout values?

    Thanks!
    Mike

  7. July 15th, 2011 at 09:46 | #7

    Hi Mike

    Thanks for sharing the information. Would you please file a feature request at vijava.sf.net?

    Steve

  8. Mike Matczynski
    July 15th, 2011 at 16:55 | #8

    Feature request ID: 3368240

    Thanks again!
    Mike

  9. Mike Matczynski
    July 28th, 2011 at 10:41 | #9

    I’ve attached a patch to the SourceForge issue.

    Thanks!
    Mike

  10. Mike Matczynski
    August 1st, 2011 at 16:57 | #10

    In the meantime, I’ve forked the vijava2.1 repo and applied the patch there:
    https://github.com/mikem2005/vijava

    This change allows configuring the read/connect timeouts before any connection is attempted.

    Mike

  11. David Taylor
    March 16th, 2014 at 21:31 | #11

    Steve,

    I inherited a project that I believe is using VI API. The jar file Im linked against is:

    vim25-JAXWS-520110926.jar

    I tried to find the classes from your example above,

    WSClient wsc = si.getServerConnection().getVimService().getWsc();

    but could not find them in the vim25 jar.

    Should I upgrade to a newer version, or is there another way to set the connect and read timeouts with the vim25 code base … We are seeing socket reads hang infinitely…

    Thanks,

    David

  12. March 17th, 2014 at 10:41 | #12

    Hi David,

    I don’t remember I have released anything with names like that, therefore cannot comment much. The vijava source code is available online and therefore people can make customized build.

    Steve

  13. Cody
    August 6th, 2015 at 02:00 | #13

    Hi,
    I used the above code to modify the default timeout, but I still get the same error while cretaing the service instance. Could you please help me out on this?

  1. No trackbacks yet.