[
https://issues.apache.org/jira/browse/LOG4J2-578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13962943#comment-13962943
]
Scott commented on LOG4J2-578:
------------------------------
Tomcat 7.0.52. The servlet version was at 2.4 as you indicated. I verified
that ensuring the servlet version matches the container version does seem to
mitigate this memory issue.
The interesting thing is with spring's java configuration there is no explicit
web.xml. Apparently spring javacofig is not setting the servlet-api version
correctly because the memory leak persists in this case. What is the interface
that log4j is using to get the servlet-api version that is causing the problem?
I will look into how this is configured with spring java config.
> 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]
