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 "Venkat Reddy (JIRA)" <ax...@ws.apache.org> on 2005/06/02 08:48:52 UTC

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

     [ http://issues.apache.org/jira/browse/AXIS-2008?page=all ]
     
Venkat Reddy resolved AXIS-2008:
--------------------------------

    Resolution: Fixed

Patch from Jaya is applied.

> 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