On 05/02/20 16:51, Daniel Fuchs wrote:
On 05/02/2020 15:31, Peter Levart wrote:
I think this is about allow the InitialContextFactory instance to be
GC'ed when the thread is long lived. It might not be a concern for
the LDAP or the other providers in the JDK.
-Alan
Ah, I see. You mean when the ClassLoader is long lived. So this is a
normal matter of trying to release the InitialContextFactory and
objects held by it when there is a memory pressure and not the matter
of avoiding class loader leaks? In this case it would pay only if
InitialContextFactory holds more memory than SoftReference itself...
Regards, Peter
Hi Peter,
Yes the concern is that the InitialContextFactory would be kept around
until the ClassLoader itself is GC'ed, even if the factory was used once
and not needed anymore. Could that become an issue in case the factory
is loaded e.g. by the System ClassLoader?
But it's a good point that it might not be a concern if the
InitialContextFactory instance in itself doesn't retain much memory.
InitialContextFactory itself is an extremely simple interface with one
method. I've browsed some code bases and could only find a small number
of such Factories implementations with simple logic to return a Context.
Applications will most likely delegate to the same Factory over and over
also (albeit, it's all controlled by HashTable parameters). The new
caching logic should help memory pressure here and not hinder it. I'm
not seeing a major concern with current solution as a result.
regards,
Sean.
best regards,
-- daniel
