Workaround: vSphere Java API with Java Web Start
A community user recently reported an issue in this scenario. His test application was launched via Web Start jnlp. “First, when run a single test thread everything is fine and the VM tasks operate normally. However as soon as we kick off a second test thread while the first test thread is running, we get an invalid login exception when the ServiceInstance object is getting instantiated.”
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.
Note that the second thread connects to the same server with same credential as the first thread. You may doubt why it’s done this way. Well, that is application level decision and beyond the scope of this discussion.
It turns out that the same application ran without any problem if launched as standalone. This prompted me to the unique things of Web Start, for example, the “sandbox” which limits the access to local computing resources such as disk and network. As confirmed, it had been signed and therefore authorized the same as standalone.
Further reading and research started from the InvalidLogin exception for log files, sessions, etc. Finally the problem was nailed down to the HttpURLConnection class, which is part of the Java standard library: (credit goes to the reporter of the issue, not me)
“It was within the HTTP post (the HttpURLConnection object) of the SOAP XML envelope to the VMWare Services API on the server, that on the first ServiceInstance instantiation, the session would login successfully, however each subsequent attempt would cause a 500 error to be returned from the VMWare Web Services Server. Tailing the hostd.log with an SSH session to the ESXi server, we could watch as the first session login successfully and every one after fail with the login error (using the same credentials).”
Well, it’s known in Java community that the HttpURLConnection is not perfect. There is a source code for the real implementation classes. Therefore it’s impossible to dig further.
In such case, unless you are API designer for that part, you should move on seeking for alternatives. And that is what the user did. He came up with a nice workaround using Apache HttpClient (Java code is included here). For that to work, all you need is to modify one method in the vijava API (This is a great testimonial itself of a good software design :-))
Currently I don’t plan to include the code into trunk because it’s a rare use case most of us won’t get into. But if you happen to be there, you want to check out this discussion thread for the workaround.