Scott created LOG4J2-578:
----------------------------
Summary: JMX Memory Leak in Servlet Container
Key: LOG4J2-578
URL: https://issues.apache.org/jira/browse/LOG4J2-578
Project: Log4j 2
Issue Type: Bug
Components: Core
Affects Versions: 2.0-rc1
Environment: Ubuntu 12.04
Linux 3.2.0-58-generic x86_64 GNU/Linux
8 GB RAM
java version "1.7.0_51"
Java(TM) SE Runtime Environment (build 1.7.0_51-b13)
Java HotSpot(TM) 64-Bit Server VM (build 24.51-b03, mixed mode)
JAVA_OPTS=-Xmx1024m -Dsun.net.inetaddr.ttl=60
-Dsun.net.inetaddr.negative.ttl=60 -Djava.net.preferIPv4Stack=true
-XX:PermSize=128m -XX:MaxPermSize=256m -XX:+UseConcMarkSweepGC
-XX:+CMSClassUnloadingEnabled
Reporter: Scott
If JMX is enabled in Log4j2 (it is by default) and a web application is
unloaded then Log4j2 creates a memory leak. This can be observed by deploying a
web application to tomcat7 and exercising the stop, undeploy, or redeploy
actions. The "unloaded" terminology is meant to be generic across servlet
containers in that any action which is designed to make the web application
classes eligible for GC. The memory leak is believed to be caused by log4j for
the following reasons:
1)Heap Dump reveals the classloader instance responsible for the WAR plugin
(for tomcat7 is of type
{code}org.apache.catalina.loader.WebappClassLoader{code}) has 1 non weak/soft
reference which is of type
{code}org.apache.logging.log4j.core.jmx.LoggerContextAdmin{code} after the WAR
has been stopped or undeployed.
2) Disabling JMX in Log4j2 (see
[http://logging.apache.org/log4j/2.x/manual/jmx.html]) results in no memory
leaks and all resources are GC as expected.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
