Hello, After reading Mark Thomas's interview at DZone http://java.dzone.com/articles/memory-leak-protection-tomcat and having experimented with classloader leaks issues, I'd like to share my thoughts with you :
1) first of all THANK YOU for providing some solutions to those problems. It's not perfect, but it's very valuable 2) About JreMemoryLeakPreventionListener : Here are other leaks I know of : 2.1) When using JNDI for LDAP access, if you use connection pooling, the JRE spawns a Thread whose context classloader is set to the one of the thread that initializes com.sun.jndi.ldap.LdapPoolManager. If it's a WebAppClassLoader, there's a leak. So, we could the initialization of com.sun.jndi.ldap.LdapPoolManager as an option for JreMemoryLeakPreventionListener. 2.2) Not JRE, but of the same kind : with Oracle JDBC driver 10.2.x, the first time "statement timeouts" are used, a thread is spawned with the same CCL leak. One can force the spawning by initializing oracle.jdbc.driver.OracleTimeoutThreadPerVM before starting webapps. We could provide a new *MemoryLeakPreventionListener for this kind of 3rd-party leak. 3) a couple of months ago I had proposed on this very list a kind of memory leak protection for those leaks caused by threads with incorrect CCL. I called this the ExpendableClassLoader. Please have a look at my post back then : http://mail-archives.apache.org/mod_mbox/tomcat-dev/200903.mbox/%3cb1be8ffd-f13f-4b2b-b25a-83f2f855b...@m4x.org%3e Since I did not get any feedback about this idea at all, neither positive nor negative, I can only assume that my post got lost in the middle of the other ones. I still think that this ExpendableClassLoader would improve the memory leak protection. Actually it would make the JreMemoryLeakPreventionListener useless and developers would not have to think about which option of the JreMemoryLeakPreventionListener is useful to them. 4) Not tomcat specific, but it might interest you anyways : there's definitely a problem with Sun's server VM, even with the latest 6.0_18. Classloaders are not always collected by the GC and this can lead to an OOME in the perm gen. I managed to reproduce this with tomcat 6.0.24 and the petcare.war sample of Spring 3. When using the client VM, the WebAppClassLoader is always correctly GCed. When using the server VM (either 32 or 64 bits, on Windows or MacOS), the classloader is not collected and after a couple of redeployments, the perm gen is full and an OOME is raised. When analyzing the heap dump, I can see several instances of WebAppClassLoaders, and eclipse MAT (www.eclipse.org/mat) shows that there's no strong reference to them :-((( Thank you for your attention, Sylvain --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
