[LOG4J2-578] JMX Memory Leak in Servlet Container

• Type: Bug
• Status: Resolved
• Priority: Critical
• Resolution: Fixed
• Affects Version/s: 2.0-rc1
• Fix Version/s: 2.5
• Component/s: Core
• Labels: memory_leak

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

• Assignee: Remko Popma
• Reporter: Scott
• Created: 24/Mar/14 21:04
• Updated: 08/Nov/15 07:30
• Resolved: 08/Nov/15 07:30

Description

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

org.apache.catalina.loader.WebappClassLoader

) has 1 non weak/soft reference which is of type

org.apache.logging.log4j.core.jmx.LoggerContextAdmin

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.

Issue Links

• incorporates: LOG4J2-570 Memory Leak
• is related to: LOG4J2-500 Unloading one webapp unloads JMX MBeans for all webapps
• is related to: LOG4J2-529 Log4j2 does not auto-initialize on webapp deploy or auto-deinitialize on undeploy
• is related to: LOG4J2-1176 Memory leak from first loaded web app when log4j jars are in Tomcat's lib folder
• supercedes: LOG4J2-406 JMX MBeans are not being unregistered when a tomcat web application that uses log4j is undeployed, leading to a permgen memory leak.