Are the Stubs generated by WSDL2JAVA (using XMLBeans binding option) through Axis2 1.5.4 thread-safe?
Actually I have created one Stub for a Web Service that I am invoking through multiple threads. I have configured my own MultiThreadedHttpConnectionmanager
and set the HTTPConstants.REUSE_HTTP_CLIENT
as well but I am seeing some NullPointerExceptions in stub._getServiceClient().cleanupTransport
that I call after each invocation.
Sometimes the threads hang too.
At the same time I noticed that in the generated Stub in the Web Service operation method, cleanup() is called already in the finally block. Should I not call stub._getServiceClient().cleanupTransport
myself afterwards?
My code:
httpConnMgr = new MultiThreadedHttpConnectionManager();
HttpConnectionManagerParams params = httpConnMgr.getParams();
if (params == null) {
params = new HttpConnectionManagerParams();
}
params.setDefaultMaxConnectionsPerHost(numberOfThreads);
httpConnMgr.setParams(params);
HttpClient httpClient = new HttpClient(httpConnMgr);
service = new Service1Stub(this.endPointAddress);
service._getServiceClient().getOptions()
.setTimeOutInMilliSeconds(this.timeOut);
service._getServiceClient().getOptions()
.setProperty(HTTPConstants.REUSE_HTTP_CLIENT, Boolean.TRUE);
service._getServiceClient().getOptions()
.setProperty(HTTPConstants.AUTO_RELEASE_CONNECTION, Boolean.FALSE);
service._getServiceClient()
.getOptions()
.setProperty(HTTPConstants.SO_TIMEOUT, (int) (this.timeOut));
service._getServiceClient()
.getOptions()
.setProperty(HTTPConstants.CONNECTION_TIMEOUT,
(int) (this.timeOut));
service._getServiceClient().getServiceContext().getConfigurationContext()
.setProperty(HTTPConstants.CACHED_HTTP_CLIENT, httpClient);
Meanwhile in the generated stub, I noticed that cleanUp is already been called:
finally {
_messageContext.getTransportOut().getSender().cleanup(_messageContext);
}
Any suggestion would be greatly helpful. Thanks.
When I looked into Axis2 some time ago, I also had thread-safe related questions about it.
Finding information about Axis2's thread safety was difficult, but I finally ended up with the following Jira issue: https://issues.apache.org/jira/browse/AXIS2-4357
It is mentioned that:
The issue itself is closed with a
Won't Fix
status and with the following note:That about did it for me at that time.
Basically you need to use one stub per thread or you can use a stub pool as (if I remember correctly) the stubs can be reused (but still need to use one stub per thread to avoid any issues). Other seem to have used stub pools with success (see related SO question here).
One advice I usually follow regarding thread safety is: If it is not explicitly stated that something is thread safe, then assume it is not.