hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roland Weber <ossf...@dubioso.net>
Subject Re: Connection Manager Garbage Collection
Date Thu, 26 Jul 2007 14:58:37 GMT
Hi Mike,

> connection managers should always be shutdown though.  I see
> finalizers as an unreliable last resort.

I agree, although I think that shutdown of the JVM is the only
case where it isn't called. I intend to use the finalizers anyway,
because I want to make the cleanup thread optional. Finalizers
will provide a fallback if the cleanup thread is disabled and
the application misbehaves.

>> 1. move TSCCM into a separate package
>> 2. factor out some of the inner classes
>>   a) replace the nesting with weak or hard references
>>   b) introduce interfaces where needed
>> 3. move static maps into a separate class which
>>    is marked for extinction
>> 4. document the relations between the classes
>>    in a package.html
>> 5. perform remaining cleanup, exterminate 3.
>> 6. see what can be generalized
>> (not sure about the order of 4 and 5)
> Yes, either order should be fine.  Could really skip three and go
> straight to 5 if you like.

Having the obsolete stuff in a single class makes it easier
to sort the rest, and later to identify the references to
the obsolete parts. That way, I don't waste time reformatting
the code I want to delete :-)

> Not sure how much of TSCCM can be generalized.  Will be nice to
> separate things out, but I wouldn't put too much effort into
> generalization unless we really think there's a case for reuse or
> substitution.

Right now I'm mostly concerned with making the code better
understandable for others, and easier to handle for myself.
In the long run, I'd like to develop a connection manager with
a more agressive re-use strategy and stricter enforcement of
connections-per-host limits. It's mentioned in the Wiki, in
the last paragraph of the implementation review:

After the restructuring, it should be possible to replace
only the ConnectionPool, while all the other logic related
to garbage collection and operations is re-used. But that's
something for 4.1.


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

View raw message