On Tue, Sep 21, 2010 at 12:22 AM, Andreas Veithen <andreas.veit...@gmail.com
> wrote:
> Hi Andrew,
>
> Note that I initially reverted Jarek's changes because of the test
> failures it caused in Rampart and Sandesha. However, after some more
> investigation, we came to the conclusion that the change is actually
> correct and that Rampart and Sandesha are wrong (see previous
> discussions on this list). The reason is this: the effect of
> commenting out those lines in AbstractHTTPSender is that the HTTP
> transport will simply abandon outgoing TCP connections without
> properly closing or reusing them. This eventually leads to resource
> (file descriptor) starvation at the OS level.
>
But the solution you provide by hard coding 2 connections per host at one
time is also not
a proper solution.
thanks,
Amila.
>
> The real issue is that by design (more precisely because of deferred
> parsing of response messages), it is mandatory to call
> TransportSender#cleanup(MessageContext) after processing a response.
> When using a ServiceClient, this is done explicitly by a call to
> ServiceClient#cleanupTransport() or implicitly when sending another
> request. However, Rampart and Sandesha were lacking the necessary
> invocations of cleanupTransport. For Rampart, I was able to locate the
> problematic code and fixed the issue in r992868. I did an attempt to
> fix the issue in Sandesha, but it looks like this is more complicated
> than Rampart. So, we need somebody familiar with the Sandesha code to
> determine where these calls are missing.
>
> Regards,
>
> Andreas
>
> On Mon, Sep 20, 2010 at 17:45, Andrew K Gatford <gatf...@uk.ibm.com>
> wrote:
> > Hi,
> >
> > I've been investigating the unit test failures for Sandesha2.
> > I've traced the problem to an Axis2 commit
> >
> > Revision: 992877
> > Author: veithen
> > Date: 20:38:56, 05 September 2010
> > Message:
> > Attempt to solve both the CLOSE_WAIT issue and AXIS2-4751 on the trunk:
> > * Reverted r963710 (Jarek's second change for AXIS2-4751 on the trunk) to
> > get back to the correct baseline for merging r790721.
> > * Merged r790721 (CLOSE_WAIT issue) from the 1.5 branch back to the
> trunk.
> > This had never been done, presumably because it caused issues in Rampart
> > (that were actually due to a bug in Rampart, fixed in r992868).
> > * Merged r824340 (Another change to AbstractHTTPSender that Glen only
> > applied to the 1.5 branch) to the trunk.
> > * Merged r958718 (Jarek's original change for AXIS2-4751 on the 1.5
> branch)
> > to the trunk.
> >
> > Modified :
> >
> /axis/axis2/java/core/trunk/modules/transport/http/src/org/apache/axis2/transport/http/AbstractHTTPSender.java
> >
> >
> > The exact problem was caused by the change to AbstractHTTPSender.
> > The uncommenting of the line
> >
> > if (connManager == null) {
> > log.trace("Making new ConnectionManager");
> > connManager = new
> MultiThreadedHttpConnectionManager();
> >
> >
> //configContext.setProperty(HTTPConstants.MULTITHREAD_HTTP_CONNECTION_MANAGER,
> > // connManager);
> > }
> >
> > I commented the line out again as above and the sandesha2 tests pass
> again.
> > This may require a change to the RMScenariosTest but need some advice on
> > what to do - or to comment out the line above again.
> >
> > Any suggestions ?
> >
> > Andrew Gatford
> > WebSphere Development Manager
> >
> > IBM United Kingdom Limited,
> > MP211, Hursley Park, Winchester, SO21 2JN
> > Telephone :
> > Internal (7) 245743
> > External 01962 815743
> > Internet : gatf...@uk.ibm.com
> >
> >
> > ________________________________
> >
> > Unless stated otherwise above:
> > IBM United Kingdom Limited - Registered in England and Wales with number
> > 741598.
> > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
> 3AU
> >
> >
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscr...@axis.apache.org
> For additional commands, e-mail: java-dev-h...@axis.apache.org
>
>
--
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/
