Memory leak in com.sun.jndi.ldap.pool.PoolCleaner
Alan Bateman
Alan.Bateman at oracle.com
Wed May 11 07:18:18 UTC 2016
On 10/05/2016 23:05, Mark Thomas wrote:
> Hi,
>
> While working my way through Tomcat's memory leak protection / detection
> / fixing code, I have found an issue that remains unresolved in the
> latest JDK 9 source.
>
> The PoolCleaner thread started by the LdapPoolManager when the idle
> timeout is positive does not explicitly set the context class loader so
> it inherits the current context class loader. If the current context
> class loader when this code is triggered happens to be one that is meant
> to be disposable (e.g. a web application class loader) the class loader
> will be pinned in memory until the Thread stops. This prevents the class
> loader from being GC'd when no longer required and triggers a mmeory leak.
>
> The fix looks to be trivial. Something along the lines of the following
> around line 45 of PoolCleaner:
>
> setContextClassLoader(PoolCleaner.class.getClassLoader());
>
> If I can provide any further information or if there is better place /
> way to submit this then please do let me know.
>
This may be a case where it should be using an InnocuousThread but
requires more study as it's very old code.
Can you submit a bug for this?
-Alan
More information about the core-libs-dev
mailing list