You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by "Jayachandra Sekhara Rao Sunkara (JIRA)" <ax...@ws.apache.org> on 2005/06/01 08:16:00 UTC

[jira] Updated: (AXIS-2008) Axis HttpSender can cause a socket resource leak

     [ 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