[jboss-jira] [JBoss JIRA] (JBLOGGING-66) Class org.jboss.logging.JDKLevel causes classloader leaks on undeployment of projects using jboss-logging in their war

[James Perkins (JIRA)]

     [ https://issues.jboss.org/browse/JBLOGGING-66?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James Perkins closed JBLOGGING-66.
----------------------------------


> Class org.jboss.logging.JDKLevel causes classloader leaks on undeployment of projects using jboss-logging in their war
> ----------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBLOGGING-66
>                 URL: https://issues.jboss.org/browse/JBLOGGING-66
>             Project: JBoss Logging
>          Issue Type: Bug
>         Environment: java version "1.6.0_22"
> OpenJDK Runtime Environment (IcedTea6 1.10.2) (fedora-58.1.10.2.fc15-x86_64)
> OpenJDK 64-Bit Server VM (build 20.0-b11, mixed mode)
> x64 Core 2 Duo laptop with 4GB RAM
>            Reporter: Craig Ringer
>            Assignee: David Lloyd
>
> I've been chasing classloader leaks that've been causing my app to fail to redeploy after a few iterations. A bit of digging using jmap and jhat has begun to strongly suggest that JBoss Logging is the problem.
> The issue is exactly the same as the one used as an example in this article on tracing classloader leaks:
>   http://blogs.oracle.com/fkieviet/entry/classloader_leaks_the_dreaded_java
> Specifically, org.jboss.logging.JDKLevel extends java.util.logging.Level . Unfortunately, java.util.logging.Level keeps a static array of all known logging levels. If JBoss Logging was deployed as part of an application war, that means there's a reference kept from an application server class (java.util.logging.Level) to a client application class (org.jboss.logging.JDKLevel). This keeps the whole reference chain intact and stops the application classloader from being destroyed.
> This is a problem on Glassfish 3.1, because JBoss Logging isn't included in the application server so it must be deployed by applications if they want to use things like JBoss Seam.
> It should be possible to add jboss-logging to glassfish/domains/domain1/lib to work around this, by making sure that org.jboss.logging.JDKLevel is loaded by the appserver classloader not the classloader of the deployed application.



--
This message was sent by Atlassian JIRA
(v6.3.8#6338)