axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Veithen <andreas.veit...@gmail.com>
Subject Re: Sandesha 2 test case failures.
Date Thu, 23 Sep 2010 05:39:37 GMT
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.
* 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


Mime
View raw message