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.
Mike
On Aug 9, 2004, at 7:30 PM, [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
