Roland Weber wrote:
Hi Mike, Oleg, all,
I need some advice on TSCCM garbage collection. I think
I have the connection GC covered, but there's also the
GC of the connection manager itself. Based on some
comments in the code, I believe there are two cases:
1. a connection is allocated. Then the TSCCM will not be
GCed, because an entry in REFERENCE_TO_CONNECTION_SOURCE
prevents it. The entry references the ConnectionPool,
which is a non-static nested class of the TSCCM, and
therefore implicitly references the TSCCM.
2. no connection is allocated. Then the TSCCM is GCed,
we have a unit test for this. But how are the open
connections closed in this scenario? I didn't see a
finalizer that would close them.
I am considering to move the TSCCM into a separate
package o.a.h.i.conn.tsccm, so I can factor out some
TSCCM specific classes without cluttering the main
implementation package. There are way too many nested
classes to feel comfortable with. This would also
create a home for some stuff elsewhere which looks
generic but is really tailored for the TSCCM, such
as the current selection of parameters.
Roland,
There are only two areas in HttpClient 3.x I never touched and hence
unable to help with: NTLM stuff and MTHCM. If you get no answer from
Mike, I'll probably have to take a plunge into the MTHCM code
Oleg, I'm glad you asked me to port the unit tests before
starting the refactoring. These things are much easier
to debug one at a time, while I am making the changes.
Oh well. After all I am not THAT nasty, am I?
Oleg
cheers,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
