Home > vSphere API > Discontinuous Response Stream from vSphere

Discontinuous Response Stream from vSphere

November 28th, 2011 Leave a comment Go to comments

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.

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.

Categories: vSphere API Tags: ,
  1. Rags
    January 12th, 2012 at 14:43 | #1
    Reply | Quote

    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. Steve Jin
    January 12th, 2012 at 21:00 | #2
    Reply | Quote

    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
    May 22nd, 2013 at 12:51 | #3
    Reply | Quote

    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. Steve Jin
    May 26th, 2013 at 13:57 | #4
    Reply | Quote

    Thanks Harish,

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

    Steve

  5. Meena
    September 13th, 2013 at 04:58 | #5
    Reply | Quote

    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
    January 12th, 2014 at 16:31 | #6
    Reply | Quote

    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.

  1. No trackbacks yet.