Discontinuous Response Stream from vSphere

Last month a question was raised in our open source vSphere Java API forum regarding an exception during HostSystem.getSummary() method call. As you can see from the stack trace, the actual exception was “org.dom4j.DocumentException.”

java.lang.RuntimeException: java.rmi.RemoteException: VI SDK invoke exception:org.dom4j.DocumentException: null Nested exception: null
        at com.vmware.vim25.mo.ManagedObject.retrieveObjectProperties(ManagedObject.java:158)
        at com.vmware.vim25.mo.ManagedObject.getCurrentProperty(ManagedObject.java:179)
        at com.vmware.vim25.mo.HostSystem.getSummary(HostSystem.java:96)
caused by: java.rmi.RemoteException: VI SDK invoke exception:org.dom4j.DocumentException: null Nested exception: null
        at com.vmware.vim25.ws.WSClient.invoke(WSClient.java:182)
        at com.vmware.vim25.ws.WSClient.invoke(WSClient.java:124)
        at com.vmware.vim25.ws.VimStub.retrieveProperties(VimStub.java:77)
        at com.vmware.vim25.mo.PropertyCollector.retrieveProperties(PropertyCollector.java:107)
        at com.vmware.vim25.mo.ManagedObject.retrieveObjectProperties(ManagedObject.java:155)
        ... 9 more

Thanks to the reporter PC Varma who actually debugged the issue, he found the root cause of the problem was discontinuous response stream that fails the dom4j XML parser. Even better, he offered a quick fix to the problem. Instead of feeding the response stream directly to the parser, just read it to a string buffer and then feed the string to the parser. The environment as reported is vCenter 4.1.0 build 258902. Should you get into similar issue and want a workaround, you can take a look the fix PC provided in the discussion thread.

Lost VMs or Containers? Too Many Consoles? Too Slow GUI? Time to learn how to "Google" and manage your VMware and clouds in a fast and secure HTML5 App.

Given that this is the only incident I’ve heard so far, the fix is not taken into the trunk. More importantly, the fix has performance implications. If you followed closely what I did in 2.0 beta, I first used the same approach but later on changed to the current implementation, which is feeding the response stream directly to the parser. The reason is rather simple: while waiting for coming bytes from the server, the parser can parse the received ones. In so doing, we basically get the parsing for free, or close to free.

Performance wise, the open source Java API is way ahead (10x times as reported) of other approaches for the moment. So we have enough room to revert back to the slower approach if really needed. If you get into similar issue, please don’t hesitate to report it. I need your feedbacks on this.

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

6 Comments

  1. Rags
    Posted January 12, 2012 at 2:43 pm | Permalink

    We hit the same issue in our environment. I checked session count on server using mob and it was only a handful. Is there a way to see the history of session count?

    java.rmi.RemoteException: VI SDK invoke exception:org.dom4j.DocumentException: null Nested exception: null
    at com.vmware.vim25.ws.WSClient.invoke(Unknown Source)
    at com.vmware.vim25.ws.WSClient.invoke(Unknown Source)
    at com.vmware.vim25.ws.VimStub.retrieveServiceContent(Unknown Source)
    at com.vmware.vim25.mo.ServiceInstance.(Unknown Source)
    at com.vmware.vim25.mo.ServiceInstance.(Unknown Source)

  2. Posted January 12, 2012 at 9:00 pm | Permalink

    What is exactly your environment? vCenter/ESX/ESXi, versions? During which method call? Any way to reproduce it? Did the quick fix solve the issue?

    Steve

  3. Harish
    Posted May 22, 2013 at 12:51 pm | Permalink

    I hit the same issue while trying to get updates of a property collector for certain events.

    UpdateSet updateSet = propertycollector.waitForUpdatesEx(version, options );

    This happens only once in every hour or so. while i am blocking for the updates.

    java.rmi.RemoteException: VI SDK invoke exception:org.dom4j.DocumentException: null Nested exception: null
    at com.vmware.vim25.ws.WSClient.invoke(WSClient.java:183)
    at com.vmware.vim25.ws.WSClient.invoke(WSClient.java:125)
    at com.vmware.vim25.ws.VimStub.waitForUpdatesEx(VimStub.java:96)
    at com.vmware.vim25.mo.PropertyCollector.waitForUpdatesEx(PropertyCollector.java:125)
    at com.harish.EventsMonitor.main(EventsMonitor.java:91)

  4. Posted May 26, 2013 at 1:57 pm | Permalink

    Thanks Harish,

    What version of vCenter or ESXi did you use? Thanks!

    Steve

  5. Meena
    Posted September 13, 2013 at 4:58 am | Permalink

    Hi Steve,

    I am hitting the same issue when I try to use waitForUpdatesEx API.

    java.rmi.RemoteException: VI SDK invoke exception:org.dom4j.DocumentException: null Nested exception: null
    at com.vmware.vim25.ws.WSClient.invoke(WSClient.java:183)
    at com.vmware.vim25.ws.WSClient.invoke(WSClient.java:125)
    at com.vmware.vim25.ws.VimStub.waitForUpdatesEx(VimStub.java:96)
    at com.vmware.vim25.mo.PropertyCollector.waitForUpdatesEx(PropertyCollector.java:125)

    The vcenter and Esx versions that we are using is 5.1.

  6. Marc Olin
    Posted January 12, 2014 at 4:31 pm | Permalink

    Steve,

    We have a bunch of customers that have hit what seems like the same Issue based on our debugging of the problem. They seem to use both vCenter 5.0 or 5.1. We have only seem this not working with Java 7 (could be just brings it out more).

    We have a test the eventually will hit this after running for a few hours.

    I also created a thread of vijava forum before digging deep and finding that it looks like this issue. It has some more information:

    http://sourceforge.net/p/vijava/discussion/826592/thread/e1353f2e/

    Any help would be great as we are hitting this more and more as our customers move to Java 7.

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.