[
https://issues.apache.org/jira/browse/LOG4J2-578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13962409#comment-13962409
]
Remko Popma commented on LOG4J2-578:
------------------------------------
Which version of Tomcat are you using when you see the memory leak?
The logic to have MBeans register/unregister for each LoggerContext (more
fine-grained than the stopgap solution of LOG4J2-500) was implemented in
LOG4J2-529, and tested with Tomcat 7.0.40, Tomcat 7.0.50, and Tomcat 8.0.1.
Special steps are necessary for Tomcat 7.0.40 because of a bug in Tomcat.
> 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
> Priority: Critical
> Labels: memory_leak
>
> 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]
