Hi Dennis-

The workaround of forcing to HTTP 1.0 wont work for .NET clients so another
solution is necessary

what happens when you set StaleCheckingEnabled for the
HttpConnectionManagerParams?

e.g.

        MultiThreadedHttpConnectionManager connectionManager = new
MultiThreadedHttpConnectionManager();
        HttpConnectionManagerParams connectionManagerParams = new
HttpConnectionManagerParams();
        connectionManagerParams.setStaleCheckingEnabled(true);
        connectionManager.setParams(connectionManagerParams);

?
Martin-
----- Original Message -----
From: "Dennis Merkel (JIRA)" <[EMAIL PROTECTED]>
To: <axis-dev@ws.apache.org>
Sent: Saturday, April 12, 2008 3:09 PM
Subject: [jira] Commented: (AXIS2-3725) TCP connections in CLOSE_WAIT state
after axis calls resulting in an exception


>
>     [
https://issues.apache.org/jira/browse/AXIS2-3725?page=com.atlassian.jira.plu
gin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12588305#action_
12588305 ]
>
> Dennis Merkel commented on AXIS2-3725:
> --------------------------------------
>
> Regarding workarounds suggested in comment
https://issues.apache.org/jira/browse/AXIS2-2883?focusedCommentId=12555249#a
ction_12555249
>
> 1) we do use http v1.0
> 2) this workaround did not help
>
> > TCP connections in CLOSE_WAIT state after axis calls resulting in an
exception
>
> --------------------------------------------------------------------------
----
> >
> >                 Key: AXIS2-3725
> >                 URL: https://issues.apache.org/jira/browse/AXIS2-3725
> >             Project: Axis 2.0 (Axis2)
> >          Issue Type: Bug
> >          Components: codegen
> >    Affects Versions: 1.3, 1.1.1
> >         Environment: BEA-Weblogic 8.1 SP6
> >            Reporter: Dennis Merkel
> >
> > Similar problems reported in AXIS-2430, AXIS-2883 and SOAP-170.
> > PROBLEM-DESCRIPTION
> > Every axis call resulting in an exception (whether the server is down or
server responding with wsdl:fault) leaves behind a new tcp connection in the
CLOSE_WAIT state.
> > Once the maximum number for SOCKET_WAITs is reached (depending on
operating system - the maximum number of open file descriptors) no more
calls could be handled until restart of BEA-Weblogic-Server.
> > WORKAROUND
> > The problem was fixed by adapting each java (wsdl:operation)-method of
the generated client stub as followed: the try-catch-block was extended with
the finally block
> > finally{
> >             if(_messageContext != null){
> >
_messageContext.getTransportOut().getSender().cleanup(_messageContext);
> >             }
> >         }
> > The cleanup method in original stub is called only in try-block, so if
an exception rises during a web service call, code execution is continued in
catch block without calling the cleanup method leading by that to a new not
cleaned up connection in the CLOSE_WAIT state.
> > P.S.:
> > - It is required to move the declaration of _messageContext variable
before the try block to make it visible in finally block
> > - Problem was initialy found on axis2 1.1.1, upgrade to 1.3 did not
eliminate the problem
>
> --
> 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]
>
>


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

Reply via email to