DoubleCloud => Private Cloud + Public Cloud

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.

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.