Details
-
Bug
-
Status: Resolved
-
Blocker
-
Resolution: Fixed
-
2.0-rc1
-
Ubuntu 12.04
Linux 3.2.0-58-generic x86_64 GNU/Linux
8 GB RAMjava 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
<log4j.version>2.0-rc1</log4j.version>
log4j-api
log4j-core
log4j-jclSpring webmvc 4.0.2.RELEASE application (simple hello world) deployed in tomcat7.0.52 container.
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 <log4j.version>2.0-rc1</log4j.version> log4j-api log4j-core log4j-jcl Spring webmvc 4.0.2.RELEASE application (simple hello world) deployed in tomcat7.0.52 container.
Description
Dynamically loading a JAR that uses log4j2 results in a memory leak when the JAR is unloaded. This can be observed by deploying a web application to tomcat7 and exercising the stop, undeploy, or redeploy actions. 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 (of type org.apache.catalina.loader.WebappClassLoader) has 2 non weak/soft reference which are of type (org.apache.logging.log4j.core.LoggerContext$ShutdownThread) and (org.apache.logging.log4j.core.jmx.LoggerContextAdmin) after the WAR has been stopped or undeployed.
2)Using SLF4J (slf4j-api, jcl-over-slf4j) to logback-classic logging output is equivalent but all memory is gc as expected (the org.apache.catalina.loader.WebappClassLoader which loaded the WAR is no longer referenced by any hard references)
3)Using the SLF4J NOP logger implementation all memory is gc as expected (the org.apache.catalina.loader.WebappClassLoader which loaded the WAR is no longer referenced by any hard references)
This may not be unique to 2.0rc-1 and I have seen similar behavior in previous 2.0 beta releases.
This is reproducible with a very simple spring hello world application. Code and/or heap dumps can be provided upon request.
Attachments
Attachments
Issue Links
- is part of
-
LOG4J2-578 JMX Memory Leak in Servlet Container
- Resolved
- relates to
-
LOG4J2-577 Refactor LoggerContext initialization/destruction code
- Closed