Hi! I can confirm that @Schedule is not stopped anymore after redeploying. That's great.
Now, regarding the leak problem, I've managed to semi-reproduce the error with a sample project. https://github.com/zmirc/tomee-memory-bug <https://github.com/zmirc/tomee-memory-bug> Steps for reproducing: 1. Open/import the maven project in an IDE (NetBeans in my case) 2. Start a clean Tomee 2013.09.27 3. Run/deploy project 4. Let it run for 20 seconds. 5. Rerun/redeploy project 6. Let it again run for 20 seconds. (By repeating 3&4 / 5&6 more times, you may get more leak messages in the end) 7. Stop/restart Tomee and look for logs containing: Sep 28, 2013 8:56:25 AM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads SEVERE: The web application [/manager] appears to have started a thread named [StatelessPool.worker.1] but has failed to stop it. This is very likely to create a memory leak. Sep 28, 2013 8:56:25 AM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads SEVERE: The web application [/manager] appears to have started a thread named [StatelessPool.worker.2] but has failed to stop it. This is very likely to create a memory leak. Sep 28, 2013 8:56:25 AM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads SEVERE: The web application [/manager] appears to have started a thread named [StatelessPool.worker.3] but has failed to stop it. This is very likely to create a memory leak. This sample project doesn't seem to also reproduce the scheduler error, but at least it can catch the one with /manager application. You know that I mentioned that Tomee leak logs appeared both for /manager and for @Schedule. Maybe the problem is similar/the same, thus fixing one will catch both. I hope this helps. -- View this message in context: http://openejb.979440.n4.nabble.com/Memory-leak-by-openejb-pool-scheduler-tp4665263p4665336.html Sent from the OpenEJB User mailing list archive at Nabble.com.
