On 03/03/2010 21:12, Sylvain Laurent wrote: > 1) first of all THANK YOU for providing some solutions to those problems. > It's not perfect, but it's very valuable Glad you are finding it useful.
> 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. I'll add those to my todo list. > 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. I suspect the lack of full source code (the Tomcat lists drop attachments) had something to do with it. The concept sounds promising and would be better than continually adding to the JreLeakPreventionListener. > 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 :-((( That sounds like http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6916498 Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
