When class com.sun.jndi.ldap.LdapPoolManager is initialized, if if the system property com.sun.jndi.ldap.connect.pool.timeout is set to a value greater than 0, a PoolCleaner thread is spawned, without fixing a specific context class loader. If the initialization of the class is triggered by a web application, its class loader will be used by the PoolCleaner thread. If that web app is stopped, its class loader will leak. We can improve JreMemoryLeakPreventionListener to prevent that leak.
What are our opportunities to initialize this class before webapp code gets involved? Is this something that is safe to initialize during Tomcat startup, or will cause negative effects for the webapp(s) using LDAP services?
the JreMemoryLeakPreventionListener is there to initialize such leaking classes. And yes, it is safe to initialize com.sun.jndi.ldap.LdapPoolManager during tomcat startup.
(In reply to comment #2) > the JreMemoryLeakPreventionListener is there to initialize such leaking > classes. Yup, I've worked on it. > And yes, it is safe to initialize com.sun.jndi.ldap.LdapPoolManager during > tomcat startup. Excellent: just initialize the class inside of the CTTL push/pop that's already in there and you should be okay. I guess you'd only have to do it if com.sun.jndi.ldap.connect.pool.timeout > 0, though system properties can be changed at runtime, so it might be a good idea to temporarily set it to 1 if it's currently 0, init the class, then set it back.
>I guess you'd only have to do it if com.sun.jndi.ldap.connect.pool.timeout > 0, though system properties can be changed at runtime, so it might be a good idea to temporarily set it to 1 if it's currently 0, init the class, then set it back. I don't think this is a good idea. This would force the leaking thread to be spawned even in cases where it is never spawned (if com.sun.jndi.ldap.connect.pool.timeout=0). This property is supposed to be set on the command line, so that it does not change at runtime. I committed the fix on trunk, will be ready for 7.0.6
proposed backport on Tomcat 6, moving this BZ issue to tomcat 6.
Implemented in 6.0 with r1056851 and will be in 6.0.30.