Possible memory leak in com.sun.xml.bind.v2.ClassFactory

[glassfishrobot]

Hi,

We have a JAX-WS 2.0 based web service endpoint deployed on a Java EE
Application server. This web service endpoint is packaged in a .war file and
deployed. After few deployment and undeployment cycles we see that the
application classloader doesn't get garbage collected.

After profiling the application we figured out that JAXB 2.0's
com.sun.xml.bind.v2.ClassFactory has a threadlocal which keeps a WeakHashMap
with Class object as the key and its Constructor as the value. Since the
Constructor has an implicit reference to Class object, the key(Class object)
would never get GC'ed and hence the Application Classloader.

Since, in an Application server the Web worker threads are pooled, threadlocal
entries would remain throughout the run resulting in a leak.

Environment

Operating System: All
Platform: All

Affected Versions

[2.0.5]

[glassfishrobot]

Reported by rajbirb

[glassfishrobot]

Was assigned to jaxb-issues

[glassfishrobot]

snajper said:
This issue was fixed in 2.1.9 already.

[glassfishrobot]

snajper said:
setting tm

[glassfishrobot]

Marked as fixed on Monday, November 3rd 2008, 6:47:18 pm

[glassfishrobot]

jonseymour said:
I don't believe the issue reported in this report was actually fixed in 2.1.9.

There was an issue - #538 - regarding ThreadLocal use in a different class, but the source code for ClassFactory has not changed between 2.1.7 and 2.2.3 and so the issues relating to the ThreadLocal in ClassFactory would appear to remain.

The basic problem is that unless ThreadLocal.remove() is called there is no guarantee that the values in a java.lang.ThreadLocal.ThreadLocalMap will be expunged. As a result, an application's classloader can be pinned across each restart, resulting in significant memory loss and therefore a degradation of the availability of any J2EE application container hosting applications that contain an implementation of jaxb-impl.jar and need to be restarted frequently.

I will try to produce a test case that demonstrates the issue and submit a new report (or append it to this one if it is re-opened).

jon.

[glassfishrobot]

snajper said:
Thanks, feel free to reopen this one with testcase.

[glassfishrobot]

a_gallardo said:
I don't understand why this has been closed. It looks a lot like #1000, which is marked as "won't fix". It took me quite a while to realize that this, in fact, has not been fixed.

I'm currently seeing this issue in a relatively complex application, using jaxb as a 3rd-transitive-grade dependency.

[glassfishrobot]

This issue was imported from java.net JIRA JAXB-563