powered by Jive Software

Tomcat7 error at shutdown: Smack Keep Alive thread can not be stopped

Hi,

We are using Tomcat 7 for our web application, which is connecting to Openfire server using smack API 3.2.0. When we shutdown Tomcat, we are making sure to call disconnect() on the XMPPConnection object. But we are still seeing the following error in the catalina.out.

SEVERE: The web application [/mywebapp] appears to have started a thread named [Smack Keep Alive (32)] but has failed to stop it. This is very likely to create a memory leak.

Apr 12, 2013 8:08:47 PM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads

Actually, we are seeing two SEVERE errors of the above kind. And we have to do a kill -9 on the Tomcat to kill the tomcat process. Any clues on what could be the issue and how we can avoid this? Any helpful information will be greatly appreciated.

Thanks

Yuva

Are you disconnecting all your XMPP connections? You say you call disconnect on the connection, but the 32 in the thread name indicates that you have create 32 connections (not that they are all active, but that many have actually been create). The disconnect will cause the thread to shutdown, but it will only do so after it’s sleep period is over for the next ‘ping’.

They are also daemon threads, so they should not prevent the vm from closing when you shut down Tomcat.

Hi rcollier

Is there any way to terminate the daemon thread started in the PacketReader and PacketWriter?

In the webapp environment (ex: Tomcat), there are permgen memory leak when continously deploy and undeploy the application due to the not terminated daemon thread.

Is there any way to terminate them except restarting the tomcat?

Thanks

The purpose of a daemon thread is that it will get automatically destroyed by the JVM once the last non-daemon exists. Smack relies on this behavior.

Yet, this doesn’t seem to be true for some environments (e.g. Tomcat), where the actual JVM is still active after the last of Smack’s object instances got gc’ed.

Your best bet at the moment is to track the daemon thread associated with a Connection instance and destroy them when this instance got gc’ed. Everything else would need rethinking the way Smack handles daemon threads and likely heavy redesign of the library. And frankly, I don’t see that happening soon.