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: <[email protected]>
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]
