Tomcat 6.0.26 has permgen memory leak detection: JreMemoryLeakPreventionListener

[kjkoster]

Dear All,

I just installed Tomcat 6.0.26 for one of my test machines. Boy, is that a nice release. I believe this is a must-have upgrade.

Reviewing the server.xml reveals this little gem:

<!-- Prevent memory leaks due to use of particular java/javax APIs-->
<Listener className="org.apache.catalina.core.JreMemoryLeakPreventionLi stener" />


This is a listener that helps developers to close their Java API resources properly. Essentially this helps you track down and squash perigean leaks and bizarre redeployment behavior.

Here is what I found in my logs, the first time I started my application in the new, instrumented Tomcat:
Apr 8, 2010 7:24:22 PM org.apache.catalina.loader.WebappClassLoader clearReferencesStopTimerThread
SEVERE: A web application appears to have started a TimerThread named [Timer-0] via the java.util.Timer API but has failed to stop it. To prevent a memory leak, the timer (and hence the associated thread) has been forcibly cancelled.
Apr 8, 2010 7:24:22 PM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads
SEVERE: A web application appears to have started a thread named [sample saver] but has failed to stop it. This is very likely to create a memory leak.
Apr 8, 2010 7:24:22 PM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads
SEVERE: A web application appears to have started a thread named [dead host notifier] but has failed to stop it. This is very likely to create a memory leak.
Apr 8, 2010 7:24:22 PM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads
SEVERE: A web application appears to have started a thread named [returned host notifier] but has failed to stop it. This is very likely to create a memory leak.
Apr 8, 2010 7:24:22 PM org.apache.catalina.loader.WebappClassLoader clearReferencesStopTimerThread
SEVERE: A web application appears to have started a TimerThread named [ActiveMQ Scheduler] via the java.util.Timer API but has failed to stop it. To prevent a memory leak, the timer (and hence the associated thread) has been forcibly cancelled.
Apr 8, 2010 7:24:22 PM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads
SEVERE: A web application appears to have started a thread named [TcpSocketClose: java.util.concurrent.ThreadPoolExecutor$Worker@54e b840f] but has failed to stop it. This is very likely to create a memory leak.
Apr 8, 2010 7:24:22 PM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads
SEVERE: A web application appears to have started a thread named [ActiveMQ Connection Worker: tcp://localhost/127.0.0.1:61616] but has failed to stop it. This is very likely to create a memory leak.
Apr 8, 2010 7:24:22 PM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads
SEVERE: A web application appears to have started a thread named [Persistence Adaptor Task] but has failed to stop it. This is very likely to create a memory leak.


Wow, and I thought I was pretty good at closing all of my resources. This basically tells me that I forget to clean up most of what I used. Hat off to the Tomcat team for adding this feature. Good work guys.

I am off to track down the source of these warnings. Looks like I have some cleaning up to do.

Kees Jan

[olafos]

Hi Kees,

Just wondering - have you succeeded in closing ActiveMQ gracefully? I have the same warnings upon reloading/closing my application although I explicitly close/shutdown connection, session and borker service.

Thanks,
Olaf Tomczak

[kjkoster]

Dear Olaf,

I have been trying to close ActiveMQ properly, but I have failed so far. :-/ Here is (roughly) what I do right now to close it.


session.close();
connection.close();
broker.stop();


This reduces the number of warnings that Tomcat gives me, but does not resolve all of them. Here is what I am left with:


SEVERE: A web application appears to have started a TimerThread named [Timer-0] via the java.util.Timer API but has failed to stop it. To prevent a memory leak, the timer (and hence the associated thread) has been forcibly cancelled.
Apr 25, 2010 8:15:43 PM org.apache.catalina.loader.WebappClassLoader clearReferencesStopTimerThread
SEVERE: A web application appears to have started a TimerThread named [ActiveMQ Scheduler] via the java.util.Timer API but has failed to stop it. To prevent a memory leak, the timer (and hence the associated thread) has been forcibly ca
ncelled.
Apr 25, 2010 8:15:43 PM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads
SEVERE: A web application appears to have started a thread named [BrokerService] but has failed to stop it. This is very likely to create a memory leak.
Apr 25, 2010 8:15:43 PM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads
SEVERE: A web application appears to have started a thread named [Persistence Adaptor Task] but has failed to stop it. This is very likely to create a memory leak.
Apr 25, 2010 8:15:43 PM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads
SEVERE: A web application appears to have started a thread named [InactivityMonitor Async Task: java.util.concurrent.ThreadPoolExecutor$Worker@66d 7a9c9] but has failed to stop it. This is very likely to create a memory leak.
Apr 25, 2010 8:15:43 PM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads
SEVERE: A web application appears to have started a thread named [TcpSocketClose: java.util.concurrent.ThreadPoolExecutor$Worker@fe1 4de0] but has failed to stop it. This is very likely to create a memory leak.
Apr 25, 2010 8:15:43 PM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads
SEVERE: A web application appears to have started a thread named [TcpSocketClose: java.util.concurrent.ThreadPoolExecutor$Worker@1a1 5cd9a] but has failed to stop it. This is very likely to create a memory leak.


Could it be that we have to use some ActiveMQ-specific close methods?

I tried adding sleeps in between these close() calls, but that does not seem to make any difference. I don't think it is a timing issue.

Kees Jan

[olafos]

Thanks Kees,

I guess I'm doing the same thing:

session.close();
connection.close();
broker.stop();


I also call:

broker.waitUntilStopped()


I experimented a little bit and tried to close some other services manually:

broker.getTaskRunnerFactory().shutdown();
broker.getPersistenceTaskRunnerFactory().shutdown( );
Scheduler.getInstance().shutdown();


It removed some additional warnings but caused problems when restarting ActiveMQ services so I gave up. I guess it's just because of the way some things are implemented (e.g. using a static singleton Scheduler instance).

Anyways.. Thanks for your comments.

Cheers,
Olaf Tomczak