You are viewing a plain text version of this content. The canonical link for it is here.
Posted to rampart-dev@ws.apache.org by Andrew K Gatford <GA...@uk.ibm.com> on 2010/09/20 17:45:00 UTC
Sandesha 2 test case failures.
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
Re: Sandesha 2 test case failures.
Posted by Andreas Veithen <an...@gmail.com>.
It looks like there are still issues with Sandesha2 and the connection
handling fixes in Axis2. I'm currently unable to successfully execute
the Sandesha2 test suite with Axis2 1.5.x. One problem seems to be
that when WS-RM is enabled, the server may return a 200 response, even
if useSeparateListeners=true. In that case, nobody cleans up the
connection. Actually, if useSeparateListeners=true, then the HTTP
transport doesn't even store the HttpMethod object in the message
context, so that the connection will not be released, even if somebody
calls TransportSender#cleanup(). What I don't understand yet is why
this doesn't cause issues when using Sandesha2 with Axis2 trunk...
Andreas
On Sat, Sep 25, 2010 at 21:08, Andreas Veithen
<an...@gmail.com> wrote:
> I fixed an issue in the HTTP transport that prevented it from properly
> releasing the connection in some scenarios with 202 responses. See
> r1001279. The Sandesha2 test suite now completes successfully.
>
> Andreas
>
> On Mon, Sep 20, 2010 at 17:45, Andrew K Gatford <GA...@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
Re: Sandesha 2 test case failures.
Posted by Andreas Veithen <an...@gmail.com>.
I fixed an issue in the HTTP transport that prevented it from properly
releasing the connection in some scenarios with 202 responses. See
r1001279. The Sandesha2 test suite now completes successfully.
Andreas
On Mon, Sep 20, 2010 at 17:45, Andrew K Gatford <GA...@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
Re: Sandesha 2 test case failures.
Posted by Andreas Veithen <an...@gmail.com>.
I fixed an issue in the HTTP transport that prevented it from properly
releasing the connection in some scenarios with 202 responses. See
r1001279. The Sandesha2 test suite now completes successfully.
Andreas
On Mon, Sep 20, 2010 at 17:45, Andrew K Gatford <GA...@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
Re: Sandesha 2 test case failures.
Posted by Glen Daniels <gl...@thoughtcraft.com>.
Folks:
Just another quick point before disappearing into meetings (and switching
to the other thread. :) ) I'm not actually averse to being able to spin
off new MHCMs (or even single-threaded ones!) / HTTPClients when desired or
appropriate - I just want to make sure that we clean them up correctly.
--Glen
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: Sandesha 2 test case failures.
Posted by Glen Daniels <gl...@thoughtcraft.com>.
Folks:
Just another quick point before disappearing into meetings (and switching
to the other thread. :) ) I'm not actually averse to being able to spin
off new MHCMs (or even single-threaded ones!) / HTTPClients when desired or
appropriate - I just want to make sure that we clean them up correctly.
--Glen
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: Sandesha 2 test case failures.
Posted by Glen Daniels <gl...@thoughtcraft.com>.
Folks:
Just another quick point before disappearing into meetings (and switching
to the other thread. :) ) I'm not actually averse to being able to spin
off new MHCMs (or even single-threaded ones!) / HTTPClients when desired or
appropriate - I just want to make sure that we clean them up correctly.
--Glen
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: Sandesha 2 test case failures.
Posted by Glen Daniels <gl...@thoughtcraft.com>.
Folks:
Just another quick point before disappearing into meetings (and switching
to the other thread. :) ) I'm not actually averse to being able to spin
off new MHCMs (or even single-threaded ones!) / HTTPClients when desired or
appropriate - I just want to make sure that we clean them up correctly.
--Glen
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: Sandesha 2 test case failures.
Posted by Glen Daniels <gl...@thoughtcraft.com>.
Folks:
Just another quick point before disappearing into meetings (and switching
to the other thread. :) ) I'm not actually averse to being able to spin
off new MHCMs (or even single-threaded ones!) / HTTPClients when desired or
appropriate - I just want to make sure that we clean them up correctly.
--Glen
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: Sandesha 2 test case failures.
Posted by Andreas Veithen <an...@gmail.com>.
On Tue, Sep 21, 2010 at 02:15, Glen Daniels <gl...@thoughtcraft.com> wrote:
> On 9/20/2010 2:52 PM, Andreas Veithen wrote:
>> 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.
>
> I'm wondering if this isn't something to do with Sandesha opening up another
> (server) connection for ACKs and sharing the same ConfigurationContext with
> the client-side, therefore running into the default 2-connection limit on the
> shared connection manager.
That would mean that there is a valid scenario where two invocations
are blocked on the server side waiting for a third invocation. I don't
know the details of WS-RM, but this seems very unlikely to me.
> I haven't dug in detail into the problem yet
> either, but I wonder if manually setting a MultithreadedHTTPConnectionManager
> with a higher number of connections per host might help. If so, we can work
> around this in Sandesha and then consider raising the default from 2 to maybe 6.
By increasing that value (which might indeed be a good idea for other
reasons) you will always be able to work around the issue. However,
you will probably miss an opportunity to fix a bug in Sandesha.
> --Glen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> For additional commands, e-mail: java-dev-help@axis.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: Sandesha 2 test case failures.
Posted by Andreas Veithen <an...@gmail.com>.
On Tue, Sep 21, 2010 at 02:15, Glen Daniels <gl...@thoughtcraft.com> wrote:
> On 9/20/2010 2:52 PM, Andreas Veithen wrote:
>> 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.
>
> I'm wondering if this isn't something to do with Sandesha opening up another
> (server) connection for ACKs and sharing the same ConfigurationContext with
> the client-side, therefore running into the default 2-connection limit on the
> shared connection manager.
That would mean that there is a valid scenario where two invocations
are blocked on the server side waiting for a third invocation. I don't
know the details of WS-RM, but this seems very unlikely to me.
> I haven't dug in detail into the problem yet
> either, but I wonder if manually setting a MultithreadedHTTPConnectionManager
> with a higher number of connections per host might help. If so, we can work
> around this in Sandesha and then consider raising the default from 2 to maybe 6.
By increasing that value (which might indeed be a good idea for other
reasons) you will always be able to work around the issue. However,
you will probably miss an opportunity to fix a bug in Sandesha.
> --Glen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> For additional commands, e-mail: java-dev-help@axis.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: Sandesha 2 test case failures.
Posted by Andreas Veithen <an...@gmail.com>.
On Tue, Sep 21, 2010 at 02:15, Glen Daniels <gl...@thoughtcraft.com> wrote:
> On 9/20/2010 2:52 PM, Andreas Veithen wrote:
>> 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.
>
> I'm wondering if this isn't something to do with Sandesha opening up another
> (server) connection for ACKs and sharing the same ConfigurationContext with
> the client-side, therefore running into the default 2-connection limit on the
> shared connection manager.
That would mean that there is a valid scenario where two invocations
are blocked on the server side waiting for a third invocation. I don't
know the details of WS-RM, but this seems very unlikely to me.
> I haven't dug in detail into the problem yet
> either, but I wonder if manually setting a MultithreadedHTTPConnectionManager
> with a higher number of connections per host might help. If so, we can work
> around this in Sandesha and then consider raising the default from 2 to maybe 6.
By increasing that value (which might indeed be a good idea for other
reasons) you will always be able to work around the issue. However,
you will probably miss an opportunity to fix a bug in Sandesha.
> --Glen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> For additional commands, e-mail: java-dev-help@axis.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: Sandesha 2 test case failures.
Posted by Andreas Veithen <an...@gmail.com>.
On Tue, Sep 21, 2010 at 02:15, Glen Daniels <gl...@thoughtcraft.com> wrote:
> On 9/20/2010 2:52 PM, Andreas Veithen wrote:
>> 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.
>
> I'm wondering if this isn't something to do with Sandesha opening up another
> (server) connection for ACKs and sharing the same ConfigurationContext with
> the client-side, therefore running into the default 2-connection limit on the
> shared connection manager.
That would mean that there is a valid scenario where two invocations
are blocked on the server side waiting for a third invocation. I don't
know the details of WS-RM, but this seems very unlikely to me.
> I haven't dug in detail into the problem yet
> either, but I wonder if manually setting a MultithreadedHTTPConnectionManager
> with a higher number of connections per host might help. If so, we can work
> around this in Sandesha and then consider raising the default from 2 to maybe 6.
By increasing that value (which might indeed be a good idea for other
reasons) you will always be able to work around the issue. However,
you will probably miss an opportunity to fix a bug in Sandesha.
> --Glen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> For additional commands, e-mail: java-dev-help@axis.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: Sandesha 2 test case failures.
Posted by Andreas Veithen <an...@gmail.com>.
On Tue, Sep 21, 2010 at 02:15, Glen Daniels <gl...@thoughtcraft.com> wrote:
> On 9/20/2010 2:52 PM, Andreas Veithen wrote:
>> 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.
>
> I'm wondering if this isn't something to do with Sandesha opening up another
> (server) connection for ACKs and sharing the same ConfigurationContext with
> the client-side, therefore running into the default 2-connection limit on the
> shared connection manager.
That would mean that there is a valid scenario where two invocations
are blocked on the server side waiting for a third invocation. I don't
know the details of WS-RM, but this seems very unlikely to me.
> I haven't dug in detail into the problem yet
> either, but I wonder if manually setting a MultithreadedHTTPConnectionManager
> with a higher number of connections per host might help. If so, we can work
> around this in Sandesha and then consider raising the default from 2 to maybe 6.
By increasing that value (which might indeed be a good idea for other
reasons) you will always be able to work around the issue. However,
you will probably miss an opportunity to fix a bug in Sandesha.
> --Glen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> For additional commands, e-mail: java-dev-help@axis.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: Sandesha 2 test case failures.
Posted by Glen Daniels <gl...@thoughtcraft.com>.
On 9/20/2010 2:52 PM, Andreas Veithen wrote:
> 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.
I'm wondering if this isn't something to do with Sandesha opening up another
(server) connection for ACKs and sharing the same ConfigurationContext with
the client-side, therefore running into the default 2-connection limit on the
shared connection manager. I haven't dug in detail into the problem yet
either, but I wonder if manually setting a MultithreadedHTTPConnectionManager
with a higher number of connections per host might help. If so, we can work
around this in Sandesha and then consider raising the default from 2 to maybe 6.
--Glen
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: Sandesha 2 test case failures.
Posted by Glen Daniels <gl...@thoughtcraft.com>.
On 9/20/2010 2:52 PM, Andreas Veithen wrote:
> 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.
I'm wondering if this isn't something to do with Sandesha opening up another
(server) connection for ACKs and sharing the same ConfigurationContext with
the client-side, therefore running into the default 2-connection limit on the
shared connection manager. I haven't dug in detail into the problem yet
either, but I wonder if manually setting a MultithreadedHTTPConnectionManager
with a higher number of connections per host might help. If so, we can work
around this in Sandesha and then consider raising the default from 2 to maybe 6.
--Glen
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: Sandesha 2 test case failures.
Posted by Andreas Veithen <an...@gmail.com>.
On Sat, Sep 25, 2010 at 17:02, Amila Suriarachchi
<am...@gmail.com> wrote:
>
>
> On Thu, Sep 23, 2010 at 5:10 PM, Glen Daniels <gl...@thoughtcraft.com> wrote:
>>
>> Gentlefolk:
>>
>> A few comments from me as well.
>>
>> 1) Clearly it was a serious oversight on my part not to have merged the
>> 1.5.1
>> code over to the trunk. :(
>>
>> 2) Aside from simply sharing the MHCM, there is another important change
>> to
>> the 1.5.1 (and now trunk) code, and that is to clean up, by default, the
>> previous request for a given client each time sendReceive() is called -
>> this
>> allows the user to run up to two threads of many requests to the same host
>> without manually calling cleanup, and without blocking or connection
>> starvation.
>
> if the MHCM is shared then users have to call cleanUpTransport method. These
> kind of workarounds
> won't solve the problem entirely. This may be the case with Sandesha.
The point is that by design (because of support for deferred parsing),
users have to call cleanupTransport anyway. This is not a workaround
and has nothing to do with the choice of a shared MCHM. Even if the
transport opened a new connection for every request, it would still be
necessary to call cleanupTransport to make sure that the connection is
closed properly.
>>
>> 3) The right solution, IMO, is not to simply go back to creating a new
>> MHCM/HTTPClient for each request - the old code had resource leakage
>> issues
>> even when you switched on all the switches that people put in trying to
>> fix
>> problems prior to 1.5.1,
>
> You need to explain this with proper details. For me (I may have miss
> something) your fix
> technically do the same thing as setting a shared MHCM using parameters.
>
>>
>> which is why the CLOSE_WAIT issues kept being
>> reopened. Resource leakage / failing to close connections correctly is a
>> bug, plain and simple.
>>
>> 4) The current code certainly isn't ideal, and we should figure out how to
>> make it cleaner/easier/better for 1.6. I opened up a specific thread for
>> this topic: http://markmail.org/thread/wfpsfpxm5kmhf7yx - can we continue
>> the
>> discussion there?
>
> I think we have discussed every thing regarding above issue. Better thing is
> to call a vote
> to decide whether we need to make MHCM sharing by default or not.
> if there are majority votes for that then we need to clean up the existing
> code ( and adding creating a new
> connection as an option). otherwise simply revert the patch.
>
> thanks,
> Amila.
>
>>
>> Thanks,
>> --Glen
>>
>> ---------------------------------------------------------------------
>> 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
Re: Sandesha 2 test case failures.
Posted by Andreas Veithen <an...@gmail.com>.
On Sat, Sep 25, 2010 at 17:02, Amila Suriarachchi
<am...@gmail.com> wrote:
>
>
> On Thu, Sep 23, 2010 at 5:10 PM, Glen Daniels <gl...@thoughtcraft.com> wrote:
>>
>> Gentlefolk:
>>
>> A few comments from me as well.
>>
>> 1) Clearly it was a serious oversight on my part not to have merged the
>> 1.5.1
>> code over to the trunk. :(
>>
>> 2) Aside from simply sharing the MHCM, there is another important change
>> to
>> the 1.5.1 (and now trunk) code, and that is to clean up, by default, the
>> previous request for a given client each time sendReceive() is called -
>> this
>> allows the user to run up to two threads of many requests to the same host
>> without manually calling cleanup, and without blocking or connection
>> starvation.
>
> if the MHCM is shared then users have to call cleanUpTransport method. These
> kind of workarounds
> won't solve the problem entirely. This may be the case with Sandesha.
The point is that by design (because of support for deferred parsing),
users have to call cleanupTransport anyway. This is not a workaround
and has nothing to do with the choice of a shared MCHM. Even if the
transport opened a new connection for every request, it would still be
necessary to call cleanupTransport to make sure that the connection is
closed properly.
>>
>> 3) The right solution, IMO, is not to simply go back to creating a new
>> MHCM/HTTPClient for each request - the old code had resource leakage
>> issues
>> even when you switched on all the switches that people put in trying to
>> fix
>> problems prior to 1.5.1,
>
> You need to explain this with proper details. For me (I may have miss
> something) your fix
> technically do the same thing as setting a shared MHCM using parameters.
>
>>
>> which is why the CLOSE_WAIT issues kept being
>> reopened. Resource leakage / failing to close connections correctly is a
>> bug, plain and simple.
>>
>> 4) The current code certainly isn't ideal, and we should figure out how to
>> make it cleaner/easier/better for 1.6. I opened up a specific thread for
>> this topic: http://markmail.org/thread/wfpsfpxm5kmhf7yx - can we continue
>> the
>> discussion there?
>
> I think we have discussed every thing regarding above issue. Better thing is
> to call a vote
> to decide whether we need to make MHCM sharing by default or not.
> if there are majority votes for that then we need to clean up the existing
> code ( and adding creating a new
> connection as an option). otherwise simply revert the patch.
>
> thanks,
> Amila.
>
>>
>> Thanks,
>> --Glen
>>
>> ---------------------------------------------------------------------
>> 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
Re: Sandesha 2 test case failures.
Posted by Andreas Veithen <an...@gmail.com>.
On Sat, Sep 25, 2010 at 17:02, Amila Suriarachchi
<am...@gmail.com> wrote:
>
>
> On Thu, Sep 23, 2010 at 5:10 PM, Glen Daniels <gl...@thoughtcraft.com> wrote:
>>
>> Gentlefolk:
>>
>> A few comments from me as well.
>>
>> 1) Clearly it was a serious oversight on my part not to have merged the
>> 1.5.1
>> code over to the trunk. :(
>>
>> 2) Aside from simply sharing the MHCM, there is another important change
>> to
>> the 1.5.1 (and now trunk) code, and that is to clean up, by default, the
>> previous request for a given client each time sendReceive() is called -
>> this
>> allows the user to run up to two threads of many requests to the same host
>> without manually calling cleanup, and without blocking or connection
>> starvation.
>
> if the MHCM is shared then users have to call cleanUpTransport method. These
> kind of workarounds
> won't solve the problem entirely. This may be the case with Sandesha.
The point is that by design (because of support for deferred parsing),
users have to call cleanupTransport anyway. This is not a workaround
and has nothing to do with the choice of a shared MCHM. Even if the
transport opened a new connection for every request, it would still be
necessary to call cleanupTransport to make sure that the connection is
closed properly.
>>
>> 3) The right solution, IMO, is not to simply go back to creating a new
>> MHCM/HTTPClient for each request - the old code had resource leakage
>> issues
>> even when you switched on all the switches that people put in trying to
>> fix
>> problems prior to 1.5.1,
>
> You need to explain this with proper details. For me (I may have miss
> something) your fix
> technically do the same thing as setting a shared MHCM using parameters.
>
>>
>> which is why the CLOSE_WAIT issues kept being
>> reopened. Resource leakage / failing to close connections correctly is a
>> bug, plain and simple.
>>
>> 4) The current code certainly isn't ideal, and we should figure out how to
>> make it cleaner/easier/better for 1.6. I opened up a specific thread for
>> this topic: http://markmail.org/thread/wfpsfpxm5kmhf7yx - can we continue
>> the
>> discussion there?
>
> I think we have discussed every thing regarding above issue. Better thing is
> to call a vote
> to decide whether we need to make MHCM sharing by default or not.
> if there are majority votes for that then we need to clean up the existing
> code ( and adding creating a new
> connection as an option). otherwise simply revert the patch.
>
> thanks,
> Amila.
>
>>
>> Thanks,
>> --Glen
>>
>> ---------------------------------------------------------------------
>> 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
Re: Sandesha 2 test case failures.
Posted by Andreas Veithen <an...@gmail.com>.
On Sat, Sep 25, 2010 at 17:02, Amila Suriarachchi
<am...@gmail.com> wrote:
>
>
> On Thu, Sep 23, 2010 at 5:10 PM, Glen Daniels <gl...@thoughtcraft.com> wrote:
>>
>> Gentlefolk:
>>
>> A few comments from me as well.
>>
>> 1) Clearly it was a serious oversight on my part not to have merged the
>> 1.5.1
>> code over to the trunk. :(
>>
>> 2) Aside from simply sharing the MHCM, there is another important change
>> to
>> the 1.5.1 (and now trunk) code, and that is to clean up, by default, the
>> previous request for a given client each time sendReceive() is called -
>> this
>> allows the user to run up to two threads of many requests to the same host
>> without manually calling cleanup, and without blocking or connection
>> starvation.
>
> if the MHCM is shared then users have to call cleanUpTransport method. These
> kind of workarounds
> won't solve the problem entirely. This may be the case with Sandesha.
The point is that by design (because of support for deferred parsing),
users have to call cleanupTransport anyway. This is not a workaround
and has nothing to do with the choice of a shared MCHM. Even if the
transport opened a new connection for every request, it would still be
necessary to call cleanupTransport to make sure that the connection is
closed properly.
>>
>> 3) The right solution, IMO, is not to simply go back to creating a new
>> MHCM/HTTPClient for each request - the old code had resource leakage
>> issues
>> even when you switched on all the switches that people put in trying to
>> fix
>> problems prior to 1.5.1,
>
> You need to explain this with proper details. For me (I may have miss
> something) your fix
> technically do the same thing as setting a shared MHCM using parameters.
>
>>
>> which is why the CLOSE_WAIT issues kept being
>> reopened. Resource leakage / failing to close connections correctly is a
>> bug, plain and simple.
>>
>> 4) The current code certainly isn't ideal, and we should figure out how to
>> make it cleaner/easier/better for 1.6. I opened up a specific thread for
>> this topic: http://markmail.org/thread/wfpsfpxm5kmhf7yx - can we continue
>> the
>> discussion there?
>
> I think we have discussed every thing regarding above issue. Better thing is
> to call a vote
> to decide whether we need to make MHCM sharing by default or not.
> if there are majority votes for that then we need to clean up the existing
> code ( and adding creating a new
> connection as an option). otherwise simply revert the patch.
>
> thanks,
> Amila.
>
>>
>> Thanks,
>> --Glen
>>
>> ---------------------------------------------------------------------
>> 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
Re: Sandesha 2 test case failures.
Posted by Andreas Veithen <an...@gmail.com>.
On Sat, Sep 25, 2010 at 17:02, Amila Suriarachchi
<am...@gmail.com> wrote:
>
>
> On Thu, Sep 23, 2010 at 5:10 PM, Glen Daniels <gl...@thoughtcraft.com> wrote:
>>
>> Gentlefolk:
>>
>> A few comments from me as well.
>>
>> 1) Clearly it was a serious oversight on my part not to have merged the
>> 1.5.1
>> code over to the trunk. :(
>>
>> 2) Aside from simply sharing the MHCM, there is another important change
>> to
>> the 1.5.1 (and now trunk) code, and that is to clean up, by default, the
>> previous request for a given client each time sendReceive() is called -
>> this
>> allows the user to run up to two threads of many requests to the same host
>> without manually calling cleanup, and without blocking or connection
>> starvation.
>
> if the MHCM is shared then users have to call cleanUpTransport method. These
> kind of workarounds
> won't solve the problem entirely. This may be the case with Sandesha.
The point is that by design (because of support for deferred parsing),
users have to call cleanupTransport anyway. This is not a workaround
and has nothing to do with the choice of a shared MCHM. Even if the
transport opened a new connection for every request, it would still be
necessary to call cleanupTransport to make sure that the connection is
closed properly.
>>
>> 3) The right solution, IMO, is not to simply go back to creating a new
>> MHCM/HTTPClient for each request - the old code had resource leakage
>> issues
>> even when you switched on all the switches that people put in trying to
>> fix
>> problems prior to 1.5.1,
>
> You need to explain this with proper details. For me (I may have miss
> something) your fix
> technically do the same thing as setting a shared MHCM using parameters.
>
>>
>> which is why the CLOSE_WAIT issues kept being
>> reopened. Resource leakage / failing to close connections correctly is a
>> bug, plain and simple.
>>
>> 4) The current code certainly isn't ideal, and we should figure out how to
>> make it cleaner/easier/better for 1.6. I opened up a specific thread for
>> this topic: http://markmail.org/thread/wfpsfpxm5kmhf7yx - can we continue
>> the
>> discussion there?
>
> I think we have discussed every thing regarding above issue. Better thing is
> to call a vote
> to decide whether we need to make MHCM sharing by default or not.
> if there are majority votes for that then we need to clean up the existing
> code ( and adding creating a new
> connection as an option). otherwise simply revert the patch.
>
> thanks,
> Amila.
>
>>
>> Thanks,
>> --Glen
>>
>> ---------------------------------------------------------------------
>> 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
Re: Sandesha 2 test case failures.
Posted by Amila Suriarachchi <am...@gmail.com>.
On Thu, Sep 23, 2010 at 5:10 PM, Glen Daniels <gl...@thoughtcraft.com> wrote:
> Gentlefolk:
>
> A few comments from me as well.
>
> 1) Clearly it was a serious oversight on my part not to have merged the
> 1.5.1
> code over to the trunk. :(
>
> 2) Aside from simply sharing the MHCM, there is another important change to
> the 1.5.1 (and now trunk) code, and that is to clean up, by default, the
> previous request for a given client each time sendReceive() is called -
> this
> allows the user to run up to two threads of many requests to the same host
> without manually calling cleanup, and without blocking or connection
> starvation.
>
if the MHCM is shared then users have to call cleanUpTransport method. These
kind of workarounds
won't solve the problem entirely. This may be the case with Sandesha.
>
> 3) The right solution, IMO, is not to simply go back to creating a new
> MHCM/HTTPClient for each request - the old code had resource leakage issues
> even when you switched on all the switches that people put in trying to fix
> problems prior to 1.5.1,
You need to explain this with proper details. For me (I may have miss
something) your fix
technically do the same thing as setting a shared MHCM using parameters.
> which is why the CLOSE_WAIT issues kept being
> reopened. Resource leakage / failing to close connections correctly is a
> bug, plain and simple.
>
> 4) The current code certainly isn't ideal, and we should figure out how to
> make it cleaner/easier/better for 1.6. I opened up a specific thread for
> this topic: http://markmail.org/thread/wfpsfpxm5kmhf7yx - can we continue
> the
> discussion there?
>
I think we have discussed every thing regarding above issue. Better thing is
to call a vote
to decide whether we need to make MHCM sharing by default or not.
if there are majority votes for that then we need to clean up the existing
code ( and adding creating a new
connection as an option). otherwise simply revert the patch.
thanks,
Amila.
>
> Thanks,
> --Glen
>
> ---------------------------------------------------------------------
> 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/
Re: Sandesha 2 test case failures.
Posted by Amila Suriarachchi <am...@gmail.com>.
On Thu, Sep 23, 2010 at 5:10 PM, Glen Daniels <gl...@thoughtcraft.com> wrote:
> Gentlefolk:
>
> A few comments from me as well.
>
> 1) Clearly it was a serious oversight on my part not to have merged the
> 1.5.1
> code over to the trunk. :(
>
> 2) Aside from simply sharing the MHCM, there is another important change to
> the 1.5.1 (and now trunk) code, and that is to clean up, by default, the
> previous request for a given client each time sendReceive() is called -
> this
> allows the user to run up to two threads of many requests to the same host
> without manually calling cleanup, and without blocking or connection
> starvation.
>
if the MHCM is shared then users have to call cleanUpTransport method. These
kind of workarounds
won't solve the problem entirely. This may be the case with Sandesha.
>
> 3) The right solution, IMO, is not to simply go back to creating a new
> MHCM/HTTPClient for each request - the old code had resource leakage issues
> even when you switched on all the switches that people put in trying to fix
> problems prior to 1.5.1,
You need to explain this with proper details. For me (I may have miss
something) your fix
technically do the same thing as setting a shared MHCM using parameters.
> which is why the CLOSE_WAIT issues kept being
> reopened. Resource leakage / failing to close connections correctly is a
> bug, plain and simple.
>
> 4) The current code certainly isn't ideal, and we should figure out how to
> make it cleaner/easier/better for 1.6. I opened up a specific thread for
> this topic: http://markmail.org/thread/wfpsfpxm5kmhf7yx - can we continue
> the
> discussion there?
>
I think we have discussed every thing regarding above issue. Better thing is
to call a vote
to decide whether we need to make MHCM sharing by default or not.
if there are majority votes for that then we need to clean up the existing
code ( and adding creating a new
connection as an option). otherwise simply revert the patch.
thanks,
Amila.
>
> Thanks,
> --Glen
>
> ---------------------------------------------------------------------
> 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/
Re: Sandesha 2 test case failures.
Posted by Amila Suriarachchi <am...@gmail.com>.
On Thu, Sep 23, 2010 at 5:10 PM, Glen Daniels <gl...@thoughtcraft.com> wrote:
> Gentlefolk:
>
> A few comments from me as well.
>
> 1) Clearly it was a serious oversight on my part not to have merged the
> 1.5.1
> code over to the trunk. :(
>
> 2) Aside from simply sharing the MHCM, there is another important change to
> the 1.5.1 (and now trunk) code, and that is to clean up, by default, the
> previous request for a given client each time sendReceive() is called -
> this
> allows the user to run up to two threads of many requests to the same host
> without manually calling cleanup, and without blocking or connection
> starvation.
>
if the MHCM is shared then users have to call cleanUpTransport method. These
kind of workarounds
won't solve the problem entirely. This may be the case with Sandesha.
>
> 3) The right solution, IMO, is not to simply go back to creating a new
> MHCM/HTTPClient for each request - the old code had resource leakage issues
> even when you switched on all the switches that people put in trying to fix
> problems prior to 1.5.1,
You need to explain this with proper details. For me (I may have miss
something) your fix
technically do the same thing as setting a shared MHCM using parameters.
> which is why the CLOSE_WAIT issues kept being
> reopened. Resource leakage / failing to close connections correctly is a
> bug, plain and simple.
>
> 4) The current code certainly isn't ideal, and we should figure out how to
> make it cleaner/easier/better for 1.6. I opened up a specific thread for
> this topic: http://markmail.org/thread/wfpsfpxm5kmhf7yx - can we continue
> the
> discussion there?
>
I think we have discussed every thing regarding above issue. Better thing is
to call a vote
to decide whether we need to make MHCM sharing by default or not.
if there are majority votes for that then we need to clean up the existing
code ( and adding creating a new
connection as an option). otherwise simply revert the patch.
thanks,
Amila.
>
> Thanks,
> --Glen
>
> ---------------------------------------------------------------------
> 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/
Re: Sandesha 2 test case failures.
Posted by Amila Suriarachchi <am...@gmail.com>.
On Thu, Sep 23, 2010 at 5:10 PM, Glen Daniels <gl...@thoughtcraft.com> wrote:
> Gentlefolk:
>
> A few comments from me as well.
>
> 1) Clearly it was a serious oversight on my part not to have merged the
> 1.5.1
> code over to the trunk. :(
>
> 2) Aside from simply sharing the MHCM, there is another important change to
> the 1.5.1 (and now trunk) code, and that is to clean up, by default, the
> previous request for a given client each time sendReceive() is called -
> this
> allows the user to run up to two threads of many requests to the same host
> without manually calling cleanup, and without blocking or connection
> starvation.
>
if the MHCM is shared then users have to call cleanUpTransport method. These
kind of workarounds
won't solve the problem entirely. This may be the case with Sandesha.
>
> 3) The right solution, IMO, is not to simply go back to creating a new
> MHCM/HTTPClient for each request - the old code had resource leakage issues
> even when you switched on all the switches that people put in trying to fix
> problems prior to 1.5.1,
You need to explain this with proper details. For me (I may have miss
something) your fix
technically do the same thing as setting a shared MHCM using parameters.
> which is why the CLOSE_WAIT issues kept being
> reopened. Resource leakage / failing to close connections correctly is a
> bug, plain and simple.
>
> 4) The current code certainly isn't ideal, and we should figure out how to
> make it cleaner/easier/better for 1.6. I opened up a specific thread for
> this topic: http://markmail.org/thread/wfpsfpxm5kmhf7yx - can we continue
> the
> discussion there?
>
I think we have discussed every thing regarding above issue. Better thing is
to call a vote
to decide whether we need to make MHCM sharing by default or not.
if there are majority votes for that then we need to clean up the existing
code ( and adding creating a new
connection as an option). otherwise simply revert the patch.
thanks,
Amila.
>
> Thanks,
> --Glen
>
> ---------------------------------------------------------------------
> 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/
Re: Sandesha 2 test case failures.
Posted by Amila Suriarachchi <am...@gmail.com>.
On Thu, Sep 23, 2010 at 5:10 PM, Glen Daniels <gl...@thoughtcraft.com> wrote:
> Gentlefolk:
>
> A few comments from me as well.
>
> 1) Clearly it was a serious oversight on my part not to have merged the
> 1.5.1
> code over to the trunk. :(
>
> 2) Aside from simply sharing the MHCM, there is another important change to
> the 1.5.1 (and now trunk) code, and that is to clean up, by default, the
> previous request for a given client each time sendReceive() is called -
> this
> allows the user to run up to two threads of many requests to the same host
> without manually calling cleanup, and without blocking or connection
> starvation.
>
if the MHCM is shared then users have to call cleanUpTransport method. These
kind of workarounds
won't solve the problem entirely. This may be the case with Sandesha.
>
> 3) The right solution, IMO, is not to simply go back to creating a new
> MHCM/HTTPClient for each request - the old code had resource leakage issues
> even when you switched on all the switches that people put in trying to fix
> problems prior to 1.5.1,
You need to explain this with proper details. For me (I may have miss
something) your fix
technically do the same thing as setting a shared MHCM using parameters.
> which is why the CLOSE_WAIT issues kept being
> reopened. Resource leakage / failing to close connections correctly is a
> bug, plain and simple.
>
> 4) The current code certainly isn't ideal, and we should figure out how to
> make it cleaner/easier/better for 1.6. I opened up a specific thread for
> this topic: http://markmail.org/thread/wfpsfpxm5kmhf7yx - can we continue
> the
> discussion there?
>
I think we have discussed every thing regarding above issue. Better thing is
to call a vote
to decide whether we need to make MHCM sharing by default or not.
if there are majority votes for that then we need to clean up the existing
code ( and adding creating a new
connection as an option). otherwise simply revert the patch.
thanks,
Amila.
>
> Thanks,
> --Glen
>
> ---------------------------------------------------------------------
> 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/
Re: Sandesha 2 test case failures.
Posted by Glen Daniels <gl...@thoughtcraft.com>.
Gentlefolk:
A few comments from me as well.
1) Clearly it was a serious oversight on my part not to have merged the 1.5.1
code over to the trunk. :(
2) Aside from simply sharing the MHCM, there is another important change to
the 1.5.1 (and now trunk) code, and that is to clean up, by default, the
previous request for a given client each time sendReceive() is called - this
allows the user to run up to two threads of many requests to the same host
without manually calling cleanup, and without blocking or connection starvation.
3) The right solution, IMO, is not to simply go back to creating a new
MHCM/HTTPClient for each request - the old code had resource leakage issues
even when you switched on all the switches that people put in trying to fix
problems prior to 1.5.1, which is why the CLOSE_WAIT issues kept being
reopened. Resource leakage / failing to close connections correctly is a
bug, plain and simple.
4) The current code certainly isn't ideal, and we should figure out how to
make it cleaner/easier/better for 1.6. I opened up a specific thread for
this topic: http://markmail.org/thread/wfpsfpxm5kmhf7yx - can we continue the
discussion there?
Thanks,
--Glen
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: Sandesha 2 test case failures.
Posted by Amila Suriarachchi <am...@gmail.com>.
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
> <am...@gmail.com> wrote:
> >
> >
> > On Tue, Sep 21, 2010 at 12:22 AM, Andreas Veithen
> > <an...@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 <GA...@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/
Re: Sandesha 2 test case failures.
Posted by Glen Daniels <gl...@thoughtcraft.com>.
Gentlefolk:
A few comments from me as well.
1) Clearly it was a serious oversight on my part not to have merged the 1.5.1
code over to the trunk. :(
2) Aside from simply sharing the MHCM, there is another important change to
the 1.5.1 (and now trunk) code, and that is to clean up, by default, the
previous request for a given client each time sendReceive() is called - this
allows the user to run up to two threads of many requests to the same host
without manually calling cleanup, and without blocking or connection starvation.
3) The right solution, IMO, is not to simply go back to creating a new
MHCM/HTTPClient for each request - the old code had resource leakage issues
even when you switched on all the switches that people put in trying to fix
problems prior to 1.5.1, which is why the CLOSE_WAIT issues kept being
reopened. Resource leakage / failing to close connections correctly is a
bug, plain and simple.
4) The current code certainly isn't ideal, and we should figure out how to
make it cleaner/easier/better for 1.6. I opened up a specific thread for
this topic: http://markmail.org/thread/wfpsfpxm5kmhf7yx - can we continue the
discussion there?
Thanks,
--Glen
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: Sandesha 2 test case failures.
Posted by Amila Suriarachchi <am...@gmail.com>.
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
> <am...@gmail.com> wrote:
> >
> >
> > On Tue, Sep 21, 2010 at 12:22 AM, Andreas Veithen
> > <an...@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 <GA...@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/
Re: Sandesha 2 test case failures.
Posted by Amila Suriarachchi <am...@gmail.com>.
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
> <am...@gmail.com> wrote:
> >
> >
> > On Tue, Sep 21, 2010 at 12:22 AM, Andreas Veithen
> > <an...@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 <GA...@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/
Re: Sandesha 2 test case failures.
Posted by Amila Suriarachchi <am...@gmail.com>.
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
> <am...@gmail.com> wrote:
> >
> >
> > On Tue, Sep 21, 2010 at 12:22 AM, Andreas Veithen
> > <an...@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 <GA...@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/
Re: Sandesha 2 test case failures.
Posted by Glen Daniels <gl...@thoughtcraft.com>.
Gentlefolk:
A few comments from me as well.
1) Clearly it was a serious oversight on my part not to have merged the 1.5.1
code over to the trunk. :(
2) Aside from simply sharing the MHCM, there is another important change to
the 1.5.1 (and now trunk) code, and that is to clean up, by default, the
previous request for a given client each time sendReceive() is called - this
allows the user to run up to two threads of many requests to the same host
without manually calling cleanup, and without blocking or connection starvation.
3) The right solution, IMO, is not to simply go back to creating a new
MHCM/HTTPClient for each request - the old code had resource leakage issues
even when you switched on all the switches that people put in trying to fix
problems prior to 1.5.1, which is why the CLOSE_WAIT issues kept being
reopened. Resource leakage / failing to close connections correctly is a
bug, plain and simple.
4) The current code certainly isn't ideal, and we should figure out how to
make it cleaner/easier/better for 1.6. I opened up a specific thread for
this topic: http://markmail.org/thread/wfpsfpxm5kmhf7yx - can we continue the
discussion there?
Thanks,
--Glen
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: Sandesha 2 test case failures.
Posted by Glen Daniels <gl...@thoughtcraft.com>.
Gentlefolk:
A few comments from me as well.
1) Clearly it was a serious oversight on my part not to have merged the 1.5.1
code over to the trunk. :(
2) Aside from simply sharing the MHCM, there is another important change to
the 1.5.1 (and now trunk) code, and that is to clean up, by default, the
previous request for a given client each time sendReceive() is called - this
allows the user to run up to two threads of many requests to the same host
without manually calling cleanup, and without blocking or connection starvation.
3) The right solution, IMO, is not to simply go back to creating a new
MHCM/HTTPClient for each request - the old code had resource leakage issues
even when you switched on all the switches that people put in trying to fix
problems prior to 1.5.1, which is why the CLOSE_WAIT issues kept being
reopened. Resource leakage / failing to close connections correctly is a
bug, plain and simple.
4) The current code certainly isn't ideal, and we should figure out how to
make it cleaner/easier/better for 1.6. I opened up a specific thread for
this topic: http://markmail.org/thread/wfpsfpxm5kmhf7yx - can we continue the
discussion there?
Thanks,
--Glen
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: Sandesha 2 test case failures.
Posted by Glen Daniels <gl...@thoughtcraft.com>.
Gentlefolk:
A few comments from me as well.
1) Clearly it was a serious oversight on my part not to have merged the 1.5.1
code over to the trunk. :(
2) Aside from simply sharing the MHCM, there is another important change to
the 1.5.1 (and now trunk) code, and that is to clean up, by default, the
previous request for a given client each time sendReceive() is called - this
allows the user to run up to two threads of many requests to the same host
without manually calling cleanup, and without blocking or connection starvation.
3) The right solution, IMO, is not to simply go back to creating a new
MHCM/HTTPClient for each request - the old code had resource leakage issues
even when you switched on all the switches that people put in trying to fix
problems prior to 1.5.1, which is why the CLOSE_WAIT issues kept being
reopened. Resource leakage / failing to close connections correctly is a
bug, plain and simple.
4) The current code certainly isn't ideal, and we should figure out how to
make it cleaner/easier/better for 1.6. I opened up a specific thread for
this topic: http://markmail.org/thread/wfpsfpxm5kmhf7yx - can we continue the
discussion there?
Thanks,
--Glen
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: Sandesha 2 test case failures.
Posted by Amila Suriarachchi <am...@gmail.com>.
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
> <am...@gmail.com> wrote:
> >
> >
> > On Tue, Sep 21, 2010 at 12:22 AM, Andreas Veithen
> > <an...@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 <GA...@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/
Re: Sandesha 2 test case failures.
Posted by Andreas Veithen <an...@gmail.com>.
On Thu, Sep 23, 2010 at 06:41, Amila Suriarachchi
<am...@gmail.com> wrote:
>
>
> On Tue, Sep 21, 2010 at 12:22 AM, Andreas Veithen
> <an...@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 <GA...@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
Re: Sandesha 2 test case failures.
Posted by Andreas Veithen <an...@gmail.com>.
On Thu, Sep 23, 2010 at 06:41, Amila Suriarachchi
<am...@gmail.com> wrote:
>
>
> On Tue, Sep 21, 2010 at 12:22 AM, Andreas Veithen
> <an...@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 <GA...@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
Re: Sandesha 2 test case failures.
Posted by Andreas Veithen <an...@gmail.com>.
On Thu, Sep 23, 2010 at 06:41, Amila Suriarachchi
<am...@gmail.com> wrote:
>
>
> On Tue, Sep 21, 2010 at 12:22 AM, Andreas Veithen
> <an...@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 <GA...@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
Re: Sandesha 2 test case failures.
Posted by Andreas Veithen <an...@gmail.com>.
On Thu, Sep 23, 2010 at 06:41, Amila Suriarachchi
<am...@gmail.com> wrote:
>
>
> On Tue, Sep 21, 2010 at 12:22 AM, Andreas Veithen
> <an...@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 <GA...@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
Re: Sandesha 2 test case failures.
Posted by Andreas Veithen <an...@gmail.com>.
On Thu, Sep 23, 2010 at 06:41, Amila Suriarachchi
<am...@gmail.com> wrote:
>
>
> On Tue, Sep 21, 2010 at 12:22 AM, Andreas Veithen
> <an...@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 <GA...@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
Re: Sandesha 2 test case failures.
Posted by Amila Suriarachchi <am...@gmail.com>.
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.
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 <GA...@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/
Re: Sandesha 2 test case failures.
Posted by Amila Suriarachchi <am...@gmail.com>.
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.
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 <GA...@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/
Re: Sandesha 2 test case failures.
Posted by Glen Daniels <gl...@thoughtcraft.com>.
On 9/20/2010 2:52 PM, Andreas Veithen wrote:
> 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.
I'm wondering if this isn't something to do with Sandesha opening up another
(server) connection for ACKs and sharing the same ConfigurationContext with
the client-side, therefore running into the default 2-connection limit on the
shared connection manager. I haven't dug in detail into the problem yet
either, but I wonder if manually setting a MultithreadedHTTPConnectionManager
with a higher number of connections per host might help. If so, we can work
around this in Sandesha and then consider raising the default from 2 to maybe 6.
--Glen
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: Sandesha 2 test case failures.
Posted by Glen Daniels <gl...@thoughtcraft.com>.
On 9/20/2010 2:52 PM, Andreas Veithen wrote:
> 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.
I'm wondering if this isn't something to do with Sandesha opening up another
(server) connection for ACKs and sharing the same ConfigurationContext with
the client-side, therefore running into the default 2-connection limit on the
shared connection manager. I haven't dug in detail into the problem yet
either, but I wonder if manually setting a MultithreadedHTTPConnectionManager
with a higher number of connections per host might help. If so, we can work
around this in Sandesha and then consider raising the default from 2 to maybe 6.
--Glen
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: Sandesha 2 test case failures.
Posted by Amila Suriarachchi <am...@gmail.com>.
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.
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 <GA...@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/
Re: Sandesha 2 test case failures.
Posted by Amila Suriarachchi <am...@gmail.com>.
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.
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 <GA...@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/
Re: Sandesha 2 test case failures.
Posted by Amila Suriarachchi <am...@gmail.com>.
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.
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 <GA...@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/
Re: Sandesha 2 test case failures.
Posted by Glen Daniels <gl...@thoughtcraft.com>.
On 9/20/2010 2:52 PM, Andreas Veithen wrote:
> 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.
I'm wondering if this isn't something to do with Sandesha opening up another
(server) connection for ACKs and sharing the same ConfigurationContext with
the client-side, therefore running into the default 2-connection limit on the
shared connection manager. I haven't dug in detail into the problem yet
either, but I wonder if manually setting a MultithreadedHTTPConnectionManager
with a higher number of connections per host might help. If so, we can work
around this in Sandesha and then consider raising the default from 2 to maybe 6.
--Glen
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: Sandesha 2 test case failures.
Posted by Andreas Veithen <an...@gmail.com>.
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.
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 <GA...@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
Re: Sandesha 2 test case failures.
Posted by Andreas Veithen <an...@gmail.com>.
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.
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 <GA...@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
Re: Sandesha 2 test case failures.
Posted by Andreas Veithen <an...@gmail.com>.
I fixed an issue in the HTTP transport that prevented it from properly
releasing the connection in some scenarios with 202 responses. See
r1001279. The Sandesha2 test suite now completes successfully.
Andreas
On Mon, Sep 20, 2010 at 17:45, Andrew K Gatford <GA...@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
Re: Sandesha 2 test case failures.
Posted by Andreas Veithen <an...@gmail.com>.
I fixed an issue in the HTTP transport that prevented it from properly
releasing the connection in some scenarios with 202 responses. See
r1001279. The Sandesha2 test suite now completes successfully.
Andreas
On Mon, Sep 20, 2010 at 17:45, Andrew K Gatford <GA...@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
Re: Sandesha 2 test case failures.
Posted by Andreas Veithen <an...@gmail.com>.
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.
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 <GA...@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
Re: Sandesha 2 test case failures.
Posted by Andreas Veithen <an...@gmail.com>.
I fixed an issue in the HTTP transport that prevented it from properly
releasing the connection in some scenarios with 202 responses. See
r1001279. The Sandesha2 test suite now completes successfully.
Andreas
On Mon, Sep 20, 2010 at 17:45, Andrew K Gatford <GA...@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
Re: Sandesha 2 test case failures.
Posted by Andreas Veithen <an...@gmail.com>.
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.
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 <GA...@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
Re: Sandesha 2 test case failures.
Posted by Andreas Veithen <an...@gmail.com>.
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.
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 <GA...@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