axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Amila Suriarachchi <amilasuriarach...@gmail.com>
Subject Re: Sandesha 2 test case failures.
Date Thu, 23 Sep 2010 07:55:13 GMT
On Thu, Sep 23, 2010 at 11:09 AM, Andreas Veithen <andreas.veithen@gmail.com
> wrote:

> On Thu, Sep 23, 2010 at 06:41, Amila Suriarachchi
> <amilasuriarachchi@gmail.com> wrote:
> >
> >
> > On Tue, Sep 21, 2010 at 12:22 AM, Andreas Veithen
> > <andreas.veithen@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.
>
> 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 <GATFORA@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 : gatfora@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-unsubscribe@axis.apache.org
> >> For additional commands, e-mail: java-dev-help@axis.apache.org
> >>
> >
> >
> >
> > --
> > Amila Suriarachchi
> > WSO2 Inc.
> > blog: http://amilachinthaka.blogspot.com/
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> For additional commands, e-mail: java-dev-help@axis.apache.org
>
>


-- 
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/

Mime
View raw message