Re: connection leak in HttpMethodBase when HttpRecoverableException is re-thrown

2003-09-25 Thread danch
Thanks Michael. If you determine that HttpClient shouldn't be automatically releasing in this case, I'll take the issue up on the Axis side. thanks again, danch Michael Becke wrote: I will investigate automatic release for this case and will let you know what I come up with. If anyone else has

connection leak in HttpMethodBase when HttpRecoverableException is re-thrown

2003-09-24 Thread danch
Hello, I'm using HttpClient (2.0 rc1) under Axis (using their CommonsHttpSender class) and we've run into some problems with a web application locking up (deadlock). A little research and a test application revealed that this our application arrived at this condition after receiving a couple of

Re: connection leak in HttpMethodBase when HttpRecoverableException is re-thrown

2003-09-24 Thread Eric Johnson
Danch, Note the bugs: http://issues.apache.org/bugzilla/show_bug.cgi?id=23137 http://issues.apache.org/bugzilla/show_bug.cgi?id=22841 If you can, pull the latest code from CVS, or grab a nightly build, and try it again, as the bug may very well be fixed already. Let us know how it goes. - Eric

Re: connection leak in HttpMethodBase when HttpRecoverableException is re-thrown

2003-09-24 Thread danch
Thanks for the reply. I pulled down the release2 branch to do this testing. The branch built without my patch locks up in 'doGetConnection' if I start a multithreaded test then kill the webservices server, causing IOExceptions as I described. I'm rather leary of trying HEAD both because I need

Re: connection leak in HttpMethodBase when HttpRecoverableException is re-thrown

2003-09-24 Thread Michael Becke
Danch, Are you calling method.releaseConnection() in the exception case? Mike danch wrote: Thanks for the reply. I pulled down the release2 branch to do this testing. The branch built without my patch locks up in 'doGetConnection' if I start a multithreaded test then kill the webservices

Re: connection leak in HttpMethodBase when HttpRecoverableException is re-thrown

2003-09-24 Thread danch
from where? Should HttpClient's client (Axis in this case) be calling releaseConnection in the exception case? Normally, Axis is relying on AutoCloseInputStream to route the release back into HttpClient via ResponseConsumeWatcher. I was unsure on where this should be and decided on this fix

Re: connection leak in HttpMethodBase when HttpRecoverableException is re-thrown

2003-09-24 Thread Michael Becke
danch, Method.releaseConnection() should be called for all methods executed, including those that end in an exception. This is the general rule, though it should only be necessary for methods that could potentially return a response. If the response will be read outside of the context of

Re: connection leak in HttpMethodBase when HttpRecoverableException is re-thrown

2003-09-24 Thread danch
Right, but my question is where should it be called? Or really, why is the HttpClient code calling it in some exception cases but not others? Michael Becke wrote: danch, Method.releaseConnection() should be called for all methods executed, including those that end in an exception. This is the