hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From danch <da...@danch.com>
Subject Re: connection leak in HttpMethodBase when HttpRecoverableException is re-thrown
Date Wed, 24 Sep 2003 19:48:15 GMT
Right, but my question is where should it be called? Or really, why is the HttpClient code
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 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 HttpClient.execute() then closing or fully reading the response 
> stream is sufficient.  In short, always calling releaseConnection() is 
> the way to go.
> Mike
> danch wrote:
>> 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 because some exception cases _are_ handled 
>> internally to
>> HttpClient (IOException from connection.open is handled in
>> HttpClient.executeMethod, for example).
>> What is the rule for who should call the releaseConnection method when?
>> thanks,
>> danch
>> Michael Becke wrote:
>>> 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 server, causing 
>>>> IOExceptions as I described.
>>>> I'm rather leary of trying HEAD both because I need stable code, and 
>>>> because the Axis CommonsHttpSender is written to the 2.0 apis - I'm 
>>>> not sure if anything significant has changed or not. I can give this 
>>>> a shot and see if the current HEAD exhibits the same behavior, but I 
>>>> probably won't be able to do that until tomorrow.
>>>> I'd seen bug 23137 - the patch for that seems to be for HEAD, not 
>>>> the release 2 branch.
>>>> Actually, I'd also seen bug 22841 - that fixes releases where an 
>>>> exception pops out of the close call in releaseConnection. In my 
>>>> case, the problem was that releaseConnection was never called.
>>>> thanks again,
>>>> danch
>>>> Eric Johnson wrote:
>>>>> 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
>>>>> danch wrote:
>>>>>> 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).

To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org

View raw message