What are these warnings in catalina.out? [duplicat

Question

This question already has answers here:

Memory leak when redeploying application in Tomcat (5 answers)

Closed 6 years ago.

I have a web application in Tomcat 7.
When I shut down Tomcat I see these warning (but not always)

SEVERE: The web application [/MyApplication] created a ThreadLocal
with key of type
[org.apache.xml.security.algorithms.MessageDigestAlgorithm$1] (value
[org.apache.xml.security.algorithms.MessageDigestAlgorithm$1@2e2c2e2c])
and a value of type [java.util.HashMap] (value
[{http://www.w3.org/2000/09/xmldsig#sha1=MESSAGE DIGEST SHA-1}]) but
failed to remove it when the web application was stopped. Threads are
going to be renewed over time to try and avoid a probable memory leak.
Apr 3, 2012 1:56:19 PM org.apache.catalina.loader.WebappClassLoader
checkThreadLocalMapForLeaks   SEVERE: The web application
[/MyApplication] created a ThreadLocal with key of type
[com.sun.xml.bind.v2.ClassFactory$1] (value
[com.sun.xml.bind.v2.ClassFactory$1@25442544]) and a value of type
[java.util.WeakHashMap] (value [{class
com.classes.internal.ContactType=java.lang.ref.WeakReference@17eb17eb,
class
javax.xml.bind.annotation.adapters.HexBinaryAdapter=java.lang.ref.WeakReference@178a178a,
class
com.classes.internal.xjc.ListType=java.lang.ref.WeakReference@181c181c,
class
com.classes.internal.xjc.MessageType=java.lang.ref.WeakReference@17711771,
class
com.classes.internal.xjc.MessageType=java.lang.ref.WeakReference@17011701}])
but failed to remove it when the web application was stopped. Threads
are going to be renewed over time to try and avoid a probable memory
leak.   Apr 3, 2012 1:56:19 PM
org.apache.catalina.loader.WebappClassLoader
checkThreadLocalMapForLeaks   SEVERE: The web application
[/MyApplication] created a ThreadLocal with key of type
[org.apache.xml.security.utils.UnsyncBufferedOutputStream$1] (value
[org.apache.xml.security.utils.UnsyncBufferedOutputStream$1@4a904a90])
and a value of type [byte[]] (value [[B@67486748]) but failed to
remove it when the web application was stopped. Threads are going to
be renewed over time to try and avoid a probable memory leak.  

What do these warnings mean in catalina.out on shutdown?
I see some of my JAXB classes mentioned, but can't tell what the issue is here.

Any help please?

Answer 1

At least one of the JAXB messages appears to relate to a known bug:

org.apache.catalina.loader.WebappClassLoader checkThreadLocalMapForLeaks SEVERE: The web application [/MyApplication] created a ThreadLocal with key of type [com.sun.xml.bind.v2.ClassFactory$1] (value [com.sun.xml.bind.v2.ClassFactory$1@25442544]) and a value of type [java.util.WeakHashMap]

See JAXB-563 and JAXB-831 (NB - These are on java.net and require a login to even view). The first bug was supposedly fixed but as others have commented this is not fully fixed. The second bug has a suggested workaround which is to force a gc() before letting the context shutdown which does mitigate the problem (though not eliminate it entirely) - you can use a custom ServletContextListener and simply call System.gc() in the contextDestroyed() method.

As for the other errors you need to follow the other answers advice and do some serious debugging.

Answer 2

You have one or more memory leaks in your application. For a full explanation of why these occur, which ones are your fault and what you can do to fix them see this presentation: http://people.apache.org/~markt/presentations/2010-11-04-Memory-Leaks-60mins.pdf

Answer 3

In a nutshell, some ThreadLocals have not been cleaned properly. Most (if not all) J2EE-servers / Application Containers use thread pools for incoming requests and other tasks, to prevent the overhead of starting new threads all the time. The problem is that some libraries (and you yourself, if you don't know better) don't clean up their ThreadLocals after the execution of the task/request ends.

Normally, as the thread dies on end of execution, the objects stored in ThreadLocals are no longer referenced and the garbage collector takes care of removing such objects:

Each thread holds an implicit reference to its copy of a thread-local variable as long as the thread is alive and the ThreadLocal instance is accessible; after a thread goes away, all of its copies of thread-local instances are subject to garbage collection (unless other references to these copies exist).

But when the thread has been fetched from a thread pool, it does not die, but instead is returned to the pool. Since the thread is still alive, so are the referenced ThreadLocals. This manifests both as memory leaks and "leaking" of values from one request to another when the same ThreadLocal is used and the thread handling the request/task was used before.