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

How to Set up Connection Timeout in VI Java API

March 2nd, 2011 Leave a comment Go to comments

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.

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
    Reply | Quote

    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. Steve Jin
    May 4th, 2011 at 10:11 | #2
    Reply | Quote

    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
    Reply | Quote

    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. Steve Jin
    May 6th, 2011 at 17:43 | #4
    Reply | Quote

    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
    Reply | Quote

    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
    Reply | Quote

    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. Steve Jin
    July 15th, 2011 at 09:46 | #7
    Reply | Quote

    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
    Reply | Quote

    Feature request ID: 3368240

    Thanks again!
    Mike

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

    I’ve attached a patch to the SourceForge issue.

    Thanks!
    Mike

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

    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

  1. No trackbacks yet.