Guice + Tomcat potential memory leak

Question

I have just started using Google Guice with my Tomcat webapp, and have noticed the following in the catalina.out file whenever the WAR file is undeployed:

May 16, 2011 5:37:24 PM org.apache.catalina.startup.HostConfig checkResources INFO: Undeploying context [/app]

May 16, 2011 5:37:24 PM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads SEVERE: A web application appears to have started a thread named [com.google.inject.internal.util.$Finalizer] but has failed to stop it. This is very likely to create a memory leak.

May 16, 2011 5:37:24 PM org.apache.catalina.loader.WebappClassLoader clearThreadLocalMap SEVERE: A web application created a ThreadLocal with key of type [null] (value [com.google.inject.internal.InjectorImpl$1@10ace8d]) and a value of type [java.lang.Object[]] (value [[Ljava.lang.Object;@7e9bed]) but failed to remove it when the web application was stopped. To prevent a memory leak, the ThreadLocal has been forcibly removed.

Does anyone know what causes this, or how I can stop it from happening?

I have only followed the instructions from here http://code.google.com/docreader/#p=google-guice&s=google-guice&t=ServletModule

... and haven't done anything fancy with it yet. I just have 2 servlets and a filter.

Thanks!

Answer 1

According to the Guice issue 630 it should be fixed in the next Guice version (as of 11/2011), i.e. when the Guava dependency is upgraded to r10+.

It seems that the fix is still not in, according to Guice issue 288.

Answer 2

If you are getting this when you shutdown the webapp, I wouldn't worry too much. This type of resource leak on app. shutdown is common. They do become a problem when you frequently do hot deploys (i.e. un-deploy many times without killing the JVM), but they won't be problematic when a cold deploy is done (un-deploy/deploy is done while killing the JVM before re-deploy).

A common tactic is that you do hot-deploys during development (as they are typically faster than cold-deploys), and only do a cold deploy when the resource leak starts to affect your performance. Then, in production you do a cold deploy on every deploy. Given the number of code/libraries that has this type of leak, trying to eliminate them would be hard IMO.