[ http://issues.apache.org/jira/browse/AXIS-2008?page=all ]
Jayachandra Sekhara Rao Sunkara updated AXIS-2008:
--------------------------------------------------
Attachment: 2008.patch
For any sort of exception we throw an AxisFault and are not going to come back
to reuse the socket, so I guess we can close the socket for any kind of
excpetion not just socket time out exception. Also currently the way socket is
being created does take into consideration the timeout value set in the msg
context, so the socket creation described in Tom's above patch is redundant.
With the above said points put together I've prepared a patch and am attaching
it (cvs -q diff -u format) here. 'ant all-tests' ran fine.
Thanks
Jayachandra
> Axis HttpSender can cause a socket resource leak
> ------------------------------------------------
>
> Key: AXIS-2008
> URL: http://issues.apache.org/jira/browse/AXIS-2008
> Project: Axis
> Type: Bug
> Versions: 1.1, 1.2
> Environment: Axis java, 1.1 and 1.2, unix platforms
> Reporter: Tom Diepenbrock
> Attachments: 2008.patch
>
> Under certain circumstances, the HttpSender class can leave sockets connected
> that should be closed. For example:
> In our application, we connect to several different web service providers
> using Axis. Some of them are poorly behaved--they will accept our socket
> connection, but then send no data back. Although we set the timeout value in
> the Call object (which ultimately causes the Socket.setSoTimeout(millis)
> method to be called), what happens is that the read() call to the socket's
> InputStream will throw a SocketTimeoutException, which gets caught in the
> HttpSender.invoke() method, wrapped up in an AxisFault, and then that is
> thrown back to the caller.
> Unfortunately, the SocketTimeoutException does not close the socket--the
> socket is still open and connected as per the jdk javadocs for Socket and
> SocketTimeoutException. In this case, what happens is that the socket
> remains connected at the operating system level, resulting in a resource leak
> (unix file descriptors) that eventually forces the JVM to be restarted so
> that the idle sockets can be removed.
> The problem is that there is no way for the calling application to get access
> to the still-connected socket to close it explicitly. Since the HttpSender
> treats all exceptions as fatal to that particular web service call, perhaps
> the HttpSender should catch SocketTimeoutException and close the socket, if
> no further attempts to read from it will be made, before wrapping it up into
> an AxisFault to be thrown back to the caller.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
