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.

Bothered by SLOW Web UI to manage vSphere? Want to manage ALL your VMware vCenters, AWS, Azure, Openstack, container behind a SINGLE pane of glass? Want to search, analyze, report, visualize VMs, hosts, networks, datastores, events as easily as Google the Web? Find out more about vSearch 3.0: the search engine for all your private and public clouds.

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.

This entry was posted in vSphere API and tagged . Bookmark the permalink. Post a comment or leave a trackback: Trackback URL.

13 Comments

  1. Thulasinathan Kandasamy
    Posted May 4, 2011 at 9:53 am | Permalink

    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. Posted May 4, 2011 at 10:11 am | Permalink

    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
    Posted May 6, 2011 at 10:42 am | Permalink

    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. Posted May 6, 2011 at 5:43 pm | Permalink

    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
    Posted May 13, 2011 at 10:58 am | Permalink

    Steve,

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

    Regards,
    Tulsi

  6. Mike Matczynski
    Posted July 14, 2011 at 9:56 am | Permalink

    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. Posted July 15, 2011 at 9:46 am | Permalink

    Hi Mike

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

    Steve

  8. Mike Matczynski
    Posted July 15, 2011 at 4:55 pm | Permalink

    Feature request ID: 3368240

    Thanks again!
    Mike

  9. Mike Matczynski
    Posted July 28, 2011 at 10:41 am | Permalink

    I’ve attached a patch to the SourceForge issue.

    Thanks!
    Mike

  10. Mike Matczynski
    Posted August 1, 2011 at 4:57 pm | Permalink

    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
    Posted March 16, 2014 at 9:31 pm | Permalink

    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. Posted March 17, 2014 at 10:41 am | Permalink

    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
    Posted August 6, 2015 at 2:00 am | Permalink

    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?

Post a Comment

Your email is never published nor shared. Required fields are marked *

*
*

You may use these HTML tags and attributes <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

  • NEED HELP?


    My company has created products like vSearch ("Super vCenter"), vijavaNG APIs, EAM APIs, ICE tool. We also help clients with virtualization and cloud computing on customized development, training. Should you, or someone you know, need these products and services, please feel free to contact me: steve __AT__ doublecloud.org.

    Me: Steve Jin, VMware vExpert who authored the VMware VI and vSphere SDK by Prentice Hall, and created the de factor open source vSphere Java API while working at VMware engineering. Companies like Cisco, EMC, NetApp, HP, Dell, VMware, are among the users of the API and other tools I developed for their products, internal IT orchestration, and test automation.