Contributor
Contributor

VCSA 6.9.2 - VI Java SDK connection failure exception

Hi,

VMware recently released the VCSA 7.0 Beta version 6.9.2-14311646.  With this VCSA we are unable to register any client plugin due to the below exception. We see the call to vijava api "getServiceInstance" fails. 

The same call works fine until VCSA 6.8.x. Please let us know of any logs we should capture.

2019-08-26 14:58:06,826 INFO [com.emulex.ocm.viplugin.core.client.utility.ElxRegistryUtility][http-nio-443-exec-5] - Reading the value from the properties file and not registry.
2019-08-26 14:58:07,376 INFO [com.emulex.ocm.viplugin.core.vcenter.security.VSphereServerSecurityHandler][http-nio-443-exec-5] - Looks like the vSphere server rejected the connection
java.rmi.RemoteException: VI SDK invoke exception:java.rmi.RemoteException: VI SDK invoke exception:org.dom4j.DocumentException: null Nested exception: null
at com.vmware.vim25.ws.WSClient.invoke(WSClient.java:122)
at com.vmware.vim25.ws.VimStub.retrieveServiceContent(VimStub.java:1433)
at com.vmware.vim25.mo.ServiceInstance.<init>(ServiceInstance.java:85)
at com.vmware.vim25.mo.ServiceInstance.<init>(ServiceInstance.java:69)

at com.emulex.ocm.viplugin.core.vcenter.security.VSphereServerSecurityHandler.getServiceInstance(VSphereServerSecurityHandler.java:207)
at com.emulex.ocm.viplugin.core.vcenter.register.VCenterExtensionRegistrationUtility.getVMwareVCenterVersion(VCenterExtensionRegistrationUtility.java:237)
at com.emulex.ocm.viplugin.core.vcenter.register.VCenterExtensionRegistrationUtility.isVMwareHTMLClientSupported(VCenterExtensionRegistrationUtility.java:256)
at com.emulex.ocm.viplugin.core.vcenter.VCenterClientPluginInstallManager.installClientPlugin(VCenterClientPluginInstallManager.java:123)
at com.emulex.ocm.viplugin.register.VIPluginRegistrationResource.install(VIPluginRegistrationResource.java:167)
at com.emulex.ocm.viplugin.register.VIPluginRegistrationResource.execute(VIPluginRegistrationResource.java:140)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.springframework.web.bind.annotation.support.HandlerMethodInvoker.invokeHandlerMethod(HandlerMethodInvoker.java:176)
at org.springframework.web.servlet.mvc.annotation.AnnotationMethodHandlerAdapter.invokeHandlerMethod(AnnotationMethodHandlerAdapter.java:427)
at org.springframework.web.servlet.mvc.annotation.AnnotationMethodHandlerAdapter.handle(AnnotationMethodHandlerAdapter.java:415)
at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:788)
at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:717)
at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:644)
at org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServlet.java:560)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:646)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:303)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
at org.apache.catalina.filters.CorsFilter.handleNonCORS(CorsFilter.java:439)
at org.apache.catalina.filters.CorsFilter.doFilter(CorsFilter.java:178)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:220)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:122)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:503)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:170)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:103)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:116)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:421)
at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1070)
at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:611)
at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1736)
at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1695)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Unknown Source)

17 Replies
VMware Employee
VMware Employee

Hi abby21,

 

Just looking at the exception, we could not determine what the root cause might be.
If you can reproduce this with an existing sample of the SDK, we will be glad to help, 
but I think it will be more useful to post this question in the VI Java forum.
 

Best,
Martin

0 Kudos
VMware Employee
VMware Employee

Hi Abby,

Please also keep in mind vijava is not a VMware supported library. It is external library - wrapper around vCenter Server APIs so it is playing catch-up with the actual product and any updates to the VIM API can come later.

The recommended library is vim25. Could you please check if you can reproduce the same issue with the latest vim25 from the beta or older vim25 versions?

Cheers,

Vladi

0 Kudos
Contributor
Contributor

Thanks Martin and Valdi,

I will try the suggestions to use vim25 and reproduce the error with plugin sample in SDK and come back.

Thanks for your suggestions.

Regards,

Abhishek

0 Kudos
Contributor
Contributor

Hi Martin/Valdi,

We are indeed using vim25 version 5.5. We also see the this version is supported by VCSA 6.9.2.

Since the same code works fine with 6.8.x but not with 6.9.x.

We believe there could be some regression on the latest VCSA build that is failing to provide backward compatibility for API 5.5.

As per SDK guide we understand:

  • vCenter server adjusts the Web Services SDK APIs it supports based on the API version the Client was developed in.
  • This is determined by the SOAPAction header value sent with the WebServices POST request - ex: urn:vim25/5.1, urn:vim25/5.5 etc
  • The Client (VI Java wrapper in our case) sends this header and in vCenter versions above 5.5 it defaults to urn:vim25/5.5.

pastedImage_0.png

0 Kudos
VMware Employee
VMware Employee

Hi Abby,

Thanks for the detailed report.

This is not specific to plugins, it is rather a vCenter API so I will take it up with some internal teams.

That said, given this is a beta build, we cannot provide details in this public forum. Let's take further feedback offline.

Cheers,

Vladi

0 Kudos
Contributor
Contributor

Thanks Valdi, Hope you can access my email id. I do not have access to view your email.

0 Kudos
VMware Employee
VMware Employee

Hi Abby,

This turned out to be a known issue with this build. Should be fixed in a follow-up one.

In any case, we do recommend vim25 over vijava.

Cheers,

Vladi

0 Kudos
Contributor
Contributor

Hi Valdi,

We tried with the new release version:

VMware-VCSA-all-6.9.3-14559651

VMware-VCSA-all-6.9.3-14560202

The issue still exists. Please let us know in which build is the fix expected.

0 Kudos
VMware Employee
VMware Employee

Hi Abby,

Correct, this is not fixed in the beta builds. Normally, such API mismatches are sorted for RC but this is related to the vCenter API (not the Client API), so I don't have more info.

If I am not mistaken you also have a DCPN case open on this and it is the better place than the Forum to discuss any beta feedback as the relevant VMware teams are looped in.

Cheers,

Vladi

0 Kudos
Contributor
Contributor

Hi Vladi

I am experiencing the same issue as Abby, any idea who I need to escalate this with so I can get a resolution.
We really cant wait until the product is in release since our customers will see the issue before we have a chance to fix it.
I have been told we are a TAP member, is there a channel we need to take this up on?

Kind Regards
Angelo

0 Kudos
VMware Employee
VMware Employee

Hi Angelo,

Normally such issues are resolved by RC so that partners can accommodate to any changes.

I am not responsible for this API but this particular instance should have already been resolved. If you are a TAP partner please file a DCPN case or check other channels available to you (which you certainly have if you got a beta vSphere version for testing).

Again: this is a beta vSphere version and vijava is not a VMware-supported library so this public forum is not the right place to discuss such topics.

Cheers,

Vladi

0 Kudos
Contributor
Contributor

Vladi,

I raised an issue related to this one on the beta forums, which I believe is the correct place for beta issues, over a week ago and have received no response whatsoever.

If this issue is not going to be fixed in the beta and we have to wait for an RC build, then there is little point in the beta for us.  It should be that the beta is an oportunity for us to test our product with the new version so that we can fix any issues and go through the certification process ahead of release.  If we have to wait for the RC to be able to get as far as registering a plug-in then we will not have time to resolve any issues before release, let alone certification.

Pointing the finger at vijava doesn't really help.  This is an issue caused by a change at the vCenter API end that needs to be fixed in order for us to make any progress.

If it's possible to get someone on the vCenter API team to look at the beta forums, it would be much appreciated.

Many thanks,

Gavin.

0 Kudos
VMware Employee
VMware Employee

Hi Gavin,

I understand your points and have raised attention to this problem.

This has been escalated internally in VMware by different partners and the vCenter API team is on top of it.

I have no visibility over the vSphere beta release plans with regards to fixing this issue - any such communication will go through the standard beta channels.

Cheers,

Vladi

0 Kudos
Contributor
Contributor

We are also facing the same issue. We do have the DCPN open but it is not reaching anywhere. Our early access testing is blocked and would appreciate if this issue gets attention and if we get a beta build with this issue fixed.

0 Kudos
VMware Employee
VMware Employee

If you are a plugin developer I would encourage you to send a mail to plugin@vmware.com and indicate your DCPN case id, vendor name and plugin name. This is the alias of all PM, ecosystem and engineering folks on the plugin side who can help you out (even though the issue is not specific to plugins).

Neither you, nor the SDK team can provide any meaningful info publicly so the Forum is not the right channel to chase next steps.

0 Kudos
Contributor
Contributor

Understood and make sense. Thanks for the clarification _vladi_

0 Kudos
Contributor
Contributor

For the benefit of others, the fix for this has been recently posted in yavijava. More details here -> https://github.com/yavijava/yavijava/issues/278

Starting vSphere 7.0, any SOAP request with empty soapAction header value is treated as a non-compliance with HTTP 1.1 specs and is rejected.

0 Kudos