On Tue, 2011-07-19 at 11:53 -0400, Jon Moore wrote:
> I was in the process of working on the connection reuse strategy in
> the context of HTTPCLIENT-1108, and was adding unit tests, when I ran
> across this:
>
> If I obtain a BasicPoolEntry and then return it to the pool via
> freeEntry() with reusable set to "false", the underlying connection
> doesn't actually get closed there, which seems odd to me. Roughly, the
> code says:
>
> if (reusable) {
> // add to free pool
> } else {
> rospl.dropEntry(); // this doesn't close the entry's connection either
> numConnections--;
> }
>
> So it seems like we are just losing all the references to the
> underlying OperatedClientConnection; is it getting closed via GC or
> finalization then?
In HttpClient the reusable flag is set to false and the underlying
connection is closed at the same. See
AbstractClientConnAdaptor#abortConnection() for example. This does have
a certain design smell, though.
> Seems like adding a closeConnection(entry) to the
> "else" clause above would be the right thing to do.
>
Absolutely.
> Or am I misunderstanding how this works?
>
The connection management code in HttpClient has a long and somewhat
unpleasant history. I intend to have it completely rewritten for the
next feature release (4.2).
Cheers
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
