0

I am working on an Axis 2 (1.6.1) java client generated with wsdl2java.

It seems to be working fine but from time to time I get the following error :

14:38:04,855 INFO [HTTPSender] Unable to sendViaPost to url[...]

java.net.SocketException: Connection reset
at java.net.SocketInputStream.read(SocketInputStream.java:168)
at com.sun.net.ssl.internal.ssl.InputRecord.readFully(InputRecord.java:293)
at com.sun.net.ssl.internal.ssl.InputRecord.read(InputRecord.java:331)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:798)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readDataRecord(SSLSocketImpl.java:755)
at com.sun.net.ssl.internal.ssl.AppInputStream.read(AppInputStream.java:75)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
at java.io.BufferedInputStream.read(BufferedInputStream.java:237)
at org.apache.commons.httpclient.HttpParser.readRawLine(HttpParser.java:78)
at org.apache.commons.httpclient.HttpParser.readLine(HttpParser.java:106)

I am wondering if this could be a multi-threading issue and would like to get some answers on the matter. I use a stub that caches the HttpClient. The HttpClient uses the MultiThreadedHttpConnectionManager and I set the setDefaultMaxConnectionsPerHost to 20.

I understand that the HttpClient by virtue of the associated MultiThreadedHttpConnectionManager will be thread-safe. The question is what happens with the Axis2 stub ? Will the stub be thread-safe as well ?

I have seen some posts where it is stated that Axis stubs are not thread-safe by design. If that is the case, what is the benefit of using a multi-threaded HttpClient ? How can I make sure the Axis client stub is usable in a multi-threaded environment ?

Thank you

dan radu
  • 21
  • 1
  • 2

1 Answers1

0

A "Connection reset" error means that the server closed the connection unexpectedly. When you get that error, the problem is in the remote server, not your client.

MultiThreadedHttpConnectionManager is a multithread-safe cache for HTTP connections. Multiple threads can fetch connections from the cache or return them to the cache without the cache becoming a bottleneck. An individual HttpClient, or a stub which owns the HttpClient, should only be used by one thread at a time. The HttpClient owns an actual TCP connection to a remote server, and that connection only supports one in-progress request at a time.

Kenster
  • 23,465
  • 21
  • 80
  • 106
  • Thank you for the reply. I guess that gives me some relief if it is not a problem with the client coed. – dan radu Jun 30 '12 at 18:55
  • Assuming the stub is not thread-safe I really have three options: 1. Create/destroy the stub every time I make a request 2. use a ThreadLocal stub or 3. Synchronize the access to a shared instance (or pool of instances) of the stub. The ThreadLocal option would have the least impact CPU wise but could increase the memory footprint significantly on a server with large thread pools. The other two would keep the memory footprint to a minimum but would require significantly (?) more CPU. Based on your experience, would you recommend one approach ? Thank you – dan radu Jun 30 '12 at 19:33