hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Becke <be...@u.washington.edu>
Subject Re: Follow up to Bug 30514
Date Tue, 10 Aug 2004 02:32:16 GMT
Hi Neil,

My guess is that the lost connections are eventually GCed.  The 
multi-threaded connection manager listens for GCed connections and 
decrements the count of created connections when this occurs.  This 
feature is meant as a fail safe and should not be relied upon as 
garbage collection is by design sporadic and unreliable.


On Aug 9, 2004, at 7:30 PM, Neil.Thier@trilogy.com wrote:

> Hi,
> This is in reference to a bug I filed where HttpClient seemed to freeze
> when under heavy concurrent access.  The bug was closed noting that I
> wasn't closing the connection in my test.  This was true, however if I 
> set
> the connection pool size to be much larger than the number of threads 
> the
> problem never occurs.  The pool comes close to filling up and then it
> cleans itself out.
> What I'd like to know is - is there a case when the cleaner thread
> realizes it can clean these not-closed connections out?  I can't 
> reproduce
> this problem in the single-threaded case, and need to know more to be 
> able
> to reproduce this and verify it has been fixed in our application.
> Thanks for your help,
> Neil Thier

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