[ 
https://issues.apache.org/jira/browse/AXIS2-935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12513543
 ] 

guillaume cottenceau commented on AXIS2-935:
--------------------------------------------

I think it is probably not resolved. Several observations:

1. Deepal: REUSE_HTTP_CLIENT is *very* important, please don't remove it. In 
case of HTTPS connection, reusing an existing connection dramatically improves 
the performance because it saves a potentially rather long SSL handshake. I 
have the experience of something like 10 seconds cut down to less than 1 second 
on subsequent requests.

2. In recent version 1.2 of axis2, this problem is still there (of course). 
With REUSE_HTTP_CLIENT, a server responding with 502 bad gateway blocks my axis 
sending process after only two send attempts (probably because httpclient uses 
maximum 2 connections per host by default). In my opinion, this is a high 
priority problem which would advocate a new stable sub release. As far as I can 
tell, it is the code generation from WSDL which is at fault (I use adb): when 
invoking a SOAP request, the following line of code from the stub handles 
releasing the connection:

                           
_messageContext.getTransportOut().getSender().cleanup(_messageContext);

however, this code is not executed in case an AxisFault exception is catched, 
which is the case with HTTP 502. The cleanup code would be a good candidate for 
being executed within a finally block instead of within the try block.

3. Revision 537188 seems to be a good effort towards the right direction, 
though:

3.a. it seems that it doesn't make sense to not activate 
AUTO_RELEASE_CONNECTION; if you read httpclient tutorial - 
http://jakarta.apache.org/commons/httpclient/tutorial.html - you'll see that 
invoking HttpMethod#releaseConnection "is a crucial step to keep things 
flowing. We must tell HttpClient that we are done with the connection and that 
it can now be reused. Without doing this HttpClient will wait indefinitely for 
a connection to free up so that it can be reused."

3.b. as far as I can read from axis2 1.2 code, HTTPSender's part of revision 
537188 means calling method.releaseConnection() prior to parsing the response 
input stream (AbstractHTTPSender#processResponse merely sets the response input 
stream in the MessageContext but it's not parsed at that step), so I think the 
logic might be flawed - this is actually confirmed by the last comment 
([03/Jul/07 11:08 PM]) from issue 2593)


> Connections are not properly released causing them to stick in the 
> "CLOSE_WAIT" state and cause "Too many files open"
> ---------------------------------------------------------------------------------------------------------------------
>
>                 Key: AXIS2-935
>                 URL: https://issues.apache.org/jira/browse/AXIS2-935
>             Project: Axis 2.0 (Axis2)
>          Issue Type: Bug
>          Components: kernel
>    Affects Versions: 1.0
>         Environment: Weblogic 8.1.2, Solaris 8 (dont ask!)
>            Reporter: Jeff Peterson
>            Assignee: Deepal Jayasinghe
>            Priority: Critical
>         Attachments: AXIS2-935.patch
>
>
> It appears that org.apache.axis2.transport.http.SOAPOverHTTPSender does not 
> properly cleanup the http post connection after payload has been sent.
> The symptoms of this problem show up in `netstat` as literally hundreds of 
> connections in the "CLOSE_WAIT" state.  On a busy server this can cause the 
> application to report exceptions with the message "Too many open files."
> I looked in the source code for axis2 1.0 and discovered that in 
> SOAPOverHTTPSender.java the releaseConnection() is never called on the 
> postMethod variable.  This seems to be a likely candidate for the source of 
> the issue.
> See SOAPOverHTTPSender.java:97-118

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to