Memory leak in com.sun.xml.bind.v2.ClassFactory

[Tomas-Kraus]

I get the following error message from Tomcat on redeploying my webapp:

02.05.2011 18:26:13 org.apache.catalina.loader.WebappClassLoader clearThreadLocalMap
SCHWERWIEGEND: The web application [/foo] created a ThreadLocal with key of type [com.sun.xml.bind.v2.ClassFactory$1] (value [com.sun.xml.bind.v2.ClassFactory$1@54b8cdc]) and a value of type [java.util.WeakHashMap] (value [

{class javax.xml.bind.annotation.W3CDomHandler=java.lang.ref.WeakReference@5af92541}

]) but failed to remove it when the web application was stopped. This is very likely to create a memory leak.

I.e. Tomcat tries to clean up after the applications deployed on it, but the problem is really in the application and not in Tomcat. My application creates a JAXBContext on startup. JAXBContext has no destroy() method, so I'd expect is to do its own cleanup.

This is really a duplicate of #563, but I do not have the permission to reopen that bug.

Reviewing the source code of com.sun.xml.bind.v2.ClassFactory, it is easy to see that this class creates a static private ThreadLocal storage and never calls remove() on the ThreadLocal, so this is clearly the root cause of the problem.

Affected Versions

[2.2.2]

[Tomas-Kraus]

@glassfishrobot Commented
Reported by hwellmann

[Tomas-Kraus]

@glassfishrobot Commented
Was assigned to snajper

[Tomas-Kraus]

@glassfishrobot Commented
snajper said:
Hi, thanks for report. Do you have any kind of test for this (besides Tomcat)?

[Tomas-Kraus]

@glassfishrobot Commented
mattbishop said:
This occurs in Tomcat 6.0.32 as well as Tomcat 7.

[Tomas-Kraus]

@glassfishrobot Commented
snajper said:
Hmm, is that because the Constructor holds reference to the Class itself? Otherwise I don't see a problem in the code we have. Attempted a fix in trunk, since I don't have testcase let's hope I fixed the issue. Will merge the fix to 2.2 branch if it passes testsuites.

[Tomas-Kraus]

@glassfishrobot Commented
Marked as fixed on Monday, May 30th 2011, 2:26:06 am

[Tomas-Kraus]

@glassfishrobot Commented
snajper said:
a

[Tomas-Kraus]

@glassfishrobot Commented
veithen said:
I don't think that there is really a class loader leak here. The ThreadLocal stores a WeakHashMap containing WeakReferences, and that should not create a class loader leak. The problem is that Tomcat doesn't force a garbage collection before running its leak detection. I checked with JAXB 2.2.1.1, and the class loader is indeed garbage collected after some time.

[Tomas-Kraus]

@glassfishrobot Commented
snajper said:
Good, thanks for the clarification.

[Tomas-Kraus]

@glassfishrobot Commented
melihcelik said:
This issue seems to be resolved but is it completed, is it in the product and if so, on which version is it fixed? Because I do have the same problem with 2.2.1.1 version of jaxb-impl.

[Tomas-Kraus]

@glassfishrobot Commented
pand said:
It still happen with jaxb-impl 2.2.6 which is a direct dependency jaxws-rt 2.2.7
Any chance to solve this?

[Tomas-Kraus]

@glassfishrobot Commented
yaroska said:
Hi, all,

If it's possible to reproduce this - please create some testCase and we'll try to fix it.

[Tomas-Kraus]

@glassfishrobot Commented
zakath said:
It seems to be pretty consistent if you have an application using JaxB deployed in a Tomcat environment. For us it's web service proxy clients using Apache CXF, so I'm not quite sure how to go about writing a minimal testcase for it.

The problem is compounded in a Tomcat environment because you have no idea which thread will run your request, and you also get one instance of the cache for every thread which happens to use JaxB. It is possible to clean up after use by calling ClassFactory.clearCache(), either after you're done unmarshalling the XML or in a ServletRequestListener after your servlet is done. The problem is of course that this reduces the advantage of having a cache in the first place.

One fix might be to just change it to a static map instead of a ThreadLocal map, class definitions aren't exactly likely to change depending on the executing thread.

[Tomas-Kraus]

@glassfishrobot Commented
nameless said:
Faced this issue with JAXB 2.2.3, added explicit Maven dependency to 2.2.5. War contains library with fix, but issue still reproduces:

30-Apr-2013 15:25:01.677 SEVERE [tomcat-http--3] org.apache.catalina.loader.WebappClassLoader.checkThreadLocalMapForLeaks The web application created a ThreadLocal with key of type [com.sun.xml.bind.v2.ClassFactory$1] (value [com.sun.xml.bind.v2.ClassFactory$1@13c27c22]) and a value of type [java.util.WeakHashMap] (value [

{class javax.xml.bind.annotation.W3CDomHandler=java.lang.ref.WeakReference@4563a650}

]) 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.

Any advice is appreciated.

[Tomas-Kraus]

@glassfishrobot Commented
This issue was imported from java.net JIRA JAXB-831

[Tomas-Kraus]

• Issue Imported From: Memory leak in com.sun.xml.bind.v2.ClassFactory javaee/jaxb-v2#831
• Original Issue Raised By:@glassfishrobot
• Original Issue Assigned To: @glassfishrobot
• Original Issue Closed By:@glassfishrobot