[JBoss JIRA] Created: (JBLOGGING-66) Class org.jboss.logging.JDKLevel causes classloader leaks on undeployment of projects using jboss-logging in their war
8:06 a.m.
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
Security Level: Public (Everyone can see)
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 is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
8:16 a.m.
New subject: [JBoss JIRA] Commented: (JBLOGGING-66) Class org.jboss.logging.JDKLevel causes classloader leaks on undeployment of projects using jboss-logging in their war
[
https://issues.jboss.org/browse/JBLOGGING-66?page=com.atlassian.jira.plug...
]
Craig Ringer commented on JBLOGGING-66:
---------------------------------------
BTW, I encountered this issue without knowingly using JBoss Logging at all.
org/jboss/logging/JDKLogger.class is bundled in Seam Solder 3.0.0.Final inside
seam-solder-3.0.0.Final.jar and seam-solder-api-3.0.0.Final.jar. This makes it harder to
separate out and include in the app server - I have to drop the entirety of Seam Solder
into lib/ .
That's rather undesirable because Solder will activate servlet filters on all deployed
apps, not just the ones that use Solder.
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
Security Level: Public(Everyone can see)
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 is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
9:24 a.m.
New subject: [JBoss JIRA] Resolved: (JBLOGGING-66) Class org.jboss.logging.JDKLevel causes classloader leaks on undeployment of projects using jboss-logging in their war
[
https://issues.jboss.org/browse/JBLOGGING-66?page=com.atlassian.jira.plug...
]
David Lloyd resolved JBLOGGING-66.
----------------------------------
Resolution: Won't Fix
It's really more "Can't Fix" than "Won't Fix". In the
JBoss Application Server, aside from having only one instance of JBoss Logging (of
course), we replace the JDK LogManager implementation and take measures to prevent the JUL
Level class from recording level subclasses. Thus even if a deployment registers its own
levels (outside of any logging framework), they won't actually cause a class loader
leak. This is the responsibility of the application server environment. I recommend that
you register an issue with the Glassfish team and let them know that it is the application
server's responsibility to avoid leaks like this, even when it is caused by a poor JDK
design choice (perhaps especially then).
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
Security Level: Public(Everyone can see)
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 is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
9:55 p.m.
New subject: [JBoss JIRA] Commented: (JBLOGGING-66) Class org.jboss.logging.JDKLevel causes classloader leaks on undeployment of projects using jboss-logging in their war
[
https://issues.jboss.org/browse/JBLOGGING-66?page=com.atlassian.jira.plug...
]
Craig Ringer commented on JBLOGGING-66:
---------------------------------------
Thanks for looking into it. I'll chase it up with the Glassfish folks and see if they
can apply a similar override to fix the JDK logging issues as they're exposed there.
As it happens I've moved to JBoss AS 7 in the mean time, and I'm rather happy to
see it all works smoothly there.
This is one of the times I really wish for a backward-incompatible Java release to fix all
the horrid messy little corners of the API. Get rid of old-style enumerations, unify
logging, drop Java EE 2, generify all classes, etc. Alas, I fear it'll never happen.
Thanks again.
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
Security Level: Public(Everyone can see)
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 is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
4660
days inactive
4698
days old
3 comments
2 participants
participants (2)
-
Craig Ringer (JIRA) -
David Lloyd (JIRA)