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.
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.
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.
6 Comments
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)
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
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)
Thanks Harish,
What version of vCenter or ESXi did you use? Thanks!
Steve
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.
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.