[
https://issues.apache.org/jira/browse/LOG4J2-578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13962409#comment-13962409
]
Remko Popma edited comment on LOG4J2-578 at 4/8/14 12:09 AM:
-------------------------------------------------------------
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.
Also, be careful that the version mentioned in {{web.xml}} (Servlet 2.4 or
3.0+) matches the container version. Log4J auto-initialization needs this
version to be correct. (See comments in LOG4J2-529 for details.)
was (Author: rem...@yahoo.com):
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: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
