[
https://issues.apache.org/jira/browse/AXIS2-6009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17420697#comment-17420697
]
Eoghan O'Hare commented on AXIS2-6009:
--------------------------------------
Hi Robert,
To recap, the issue I was having was that my client could only create a max of
5 http connections at a time - even though I had the configuration for default
max connections per host and max total connection set to a high number. This
was causing backup of web service requests in axis2 and therefore causing
delays in the requests being sent out.
As you referenced, in HTTPCLIENT-2172, I came to the conclusion after doing a
debug build of some of the apache components with additional tracing, that the
issue was actually to do with the axis2 thread pool.
The axis2 thread pool core size is set to 5. From investigation, with this type
thread pool, the thread pool threads will not increase from 5 until the thread
pool queue has filled. This is what was preventing the number of http
connections from increasing past 5 concurrent connections and causing the web
service requests to backup as there were not enough http connections to send
the requests out on time. The thread pool queue is likely large.
>From looking at the axis2 code, correct me if I am wrong, but the thread pool
>is only used if the client is using async web services. Which makes sense.
With the current axis2 behavior, if async web services are being used, to
increase the max http connections that are created, the client needs to create
their own larger thread pool and set it in axis2 on the configuration context.
For example;
configurationContext.setThreadPool(new ThreadPool(200, Integer.MAX_VALUE));
I assume this is also possible in axis2.xml?
For async web services the max number of concurrent http connections that axis2
can create has a direct relationship with the thread pool size. If thread pool
size is 100, then there is a max of 100 http connections. This information
would be a useful addition to the documentation.
Regarding the different http client versions.
I had tested with http commons client 3 as well as with http client 4. The same
issue occurred for both clients where a max of 5 http connections were created.
The solution was the same - to set a thread pool instance from the calling code.
For axis2 1.7.9 with http commons client 3, I was using
MultiThreadedHttpConnectionManager (as you referenced this was documented in
https://axis.apache.org/axis2/java/core/docs/http-transport.html#reusing_httpclient_object).
There were no deprecated classes required.
For axis2 1.7.9 with http client 4, I was using PoolingClientConnectionManager.
There was a requirement to use deprecated classes (DefaultHttpClient,
PoolingClientConnectionManager as well as Scheme and SchemeRegistry for SSL).
This kind of makes people question whether they should be using them - but
there is no way around it that I could find. I know these classes are http
client library classes.
It would certainly be useful to have similar documentation specifying how to
setup a reusable http client with http client 4 in axis2 1.7.9.
Also some documentation on how to force http client 4 by configuring it
directly from the code would be good.
I had to do something like below - part of this was a suggestion from you I
believe. However the init method was important, without init method call a null
pointer was thrown;
TransportOutDescription transportOut = new TransportOutDescription("https");
HTTPClient4TransportSender sender = new HTTPClient4TransportSender();
sender.init(stub._getServiceClient().getServiceContext().getConfigurationContext(),
transportOut);
transportOut.setSender(sender);
options.setTransportOut(transportOut);
With axis2.xml I believe the same null pointer was thrown and I would require
setting transport out as shown the above. Not sure if that should be the case?
Is it a bug? If it is not a bug maybe it should be documented also.
Finally it would be good if there was similar documentation for axis2 1.8.0
regarding setup of reusable http client, since that used different http client
classes again (PoolingHttpClientConnectionManager, HttpClientBuilder,
HttpClient etc).
Note that all our web services are auto generated stubs using OperationClient.
Not sure if I have captured everything here or if it useful to you.
Thanks,
Eoghan
> ServiceClient::createClient intermittently under load blocks for 5 seconds
> --------------------------------------------------------------------------
>
> Key: AXIS2-6009
> URL: https://issues.apache.org/jira/browse/AXIS2-6009
> Project: Axis2
> Issue Type: Bug
> Affects Versions: 1.7.9
> Reporter: Eoghan O'Hare
> Priority: Major
> Attachments: ExceptionStackTrace.txt, axis2.xml, axis2client.7z,
> axis2client_httpclient4.log
>
>
> Using the axis2-kernel-1.7.9.jar.
> Our application is using automatically generated WS stubs for asynchronous
> SOAP web services over https.
> ServiceClient::createClient is called for every asynchronous web service
> request.
> Callbacks are registered using OperationClient::setCallback().
> The non blocking web service request is sent by the API
> OperationClient::execute(false).
> The option isUseSeparateListener is set to false.
> The default number of http connections are created, this is two from looking
> at pcap traces.
> Under low load rates, 20 requests per second, 1000 total requests,
> intermittently the call to ServiceClient::createClient blocks the calling
> thread for 5 seconds. Seems to be just over 5 seconds every time it occurs
> (between 5000ms and 5030ms), so it sounds like some timeout.
> The blocking seems to occur when a response to a previous web service is
> received at a similar time.
> After the 5 second blocking, an Exception is thrown from axis2 to our
> applications error callback. Exception stack trace is attached.
> I have tried to enable axis2 logging on the client side however there was
> nothing obvious in it from my point of view. Attaching the log. In the log
> the 5 second delay is between;
> 06:47:50:574
> 06:47:55:579
> If you require additional logging to be enabled to debug please let me know.
> Or if you need any further information, please let me know.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@axis.apache.org
For additional commands, e-mail: java-dev-h...@axis.apache.org
