logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Remko Popma (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (LOG4J2-578) JMX Memory Leak in Servlet Container
Date Mon, 07 Apr 2014 23:56:17 GMT

    [ 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: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org


Mime
View raw message