On Thu, Sep 23, 2010 at 11:09 AM, Andreas Veithen <[email protected] > wrote:
> On Thu, Sep 23, 2010 at 06:41, Amila Suriarachchi > <[email protected]> wrote: > > > > > > On Tue, Sep 21, 2010 at 12:22 AM, Andreas Veithen > > <[email protected]> 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. > > Couple of comments: > * It is not _my_ solution. For r992877 I even didn't edit a single > line of code. I only executed a sequence of svn commands (described in > the commit log) to reconcile the trunk with the changes done on the > 1.5 branch. I think the main issue is that we did a change on the 1.5 > branch for the 1.5.1 release, but that change had not been merged back > to the trunk. That is something we should definitely avoid in the > future. > please have a look at the thread under the [VOTE] [axis2] Release Axis2 1.5.1 (take 2). and related topics at that time. you can not make this as an excuse to commit this to trunk without a proper discussion in axis-dev. thanks, Amila. > * The 2 connections per host limit is not simply hard coded, it is a > default value that is actually required by the HTTP specs. > * As I said earlier, there are good reasons to increase that value. > However, fixing Sandesha is not one of these good reasons. Chances are > high that after increasing the limit, the Sandesha build will succeed. > However, as the example of Rampart shows, chances are also high that > this would just be a workaround for a real bug that needs to be fixed > in Sandesha. > > > 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 <[email protected]> > >> 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 : [email protected] > >> > > >> > > >> > ________________________________ > >> > > >> > 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: [email protected] > >> For additional commands, e-mail: [email protected] > >> > > > > > > > > -- > > Amila Suriarachchi > > WSO2 Inc. > > blog: http://amilachinthaka.blogspot.com/ > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- Amila Suriarachchi WSO2 Inc. blog: http://amilachinthaka.blogspot.com/
