On 11/05/2016 08:18, Alan Bateman wrote: > 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
Sure. Done. Review ID: 9087338 Thanks, Mark
