Mailing-List: contact commons-httpclient-dev-help@jakarta.apache.org;
 run by ezmlm
Precedence: bulk
Reply-To: "Commons HttpClient Project"
 <commons-httpclient-dev@jakarta.apache.org>
Message-ID: <3F71F20D.9050301@u.washington.edu>
Date: Wed, 24 Sep 2003 15:35:41 -0400
From: Michael Becke <becke@u.washington.edu>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.5b) Gecko/20030901 Thunderbird/0.2
MIME-Version: 1.0
To: Commons HttpClient Project <commons-httpclient-dev@jakarta.apache.org>
Subject: Re: connection leak in HttpMethodBase when HttpRecoverableException
 is re-thrown
References: <3F71DE97.1010606@danch.com> <3F71E1E5.6050702@tibco.com>
 <3F71E772.4050205@danch.com> <3F71E984.5090903@u.washington.edu>
 <3F71EFA5.90203@danch.com>
In-Reply-To: <3F71EFA5.90203@danch.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

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
> 


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