[
https://issues.apache.org/jira/browse/LOG4J2-578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13963006#comment-13963006
]
Scott commented on LOG4J2-578:
------------------------------
Here is the results from the ServletContext after spring has initialized it (I
picked out anything in the servlet api that related to version). Note that
there was nothing returned by "getInitParameterNames".
Major.Minor: 3.0
Effective Major.Effective Minor: 3.0
Server info: Apache Tomcat/7.0.52
The results of the methods are the same for spring's javaconfig version with
the leak and the web.xml version without the leak. So I don't think this
information represents the whole problem. Is there another interface log4j is
using/depending upon?
Note: The web.xml version with the memory leak had 1 difference in that
"Effective Major.Effective Minor=2.4".
One more problematic difference in these two configurations is with the
incorrect "Effective Major.Effective Minor=2.4" I was able to still use the
logging object returned by the LogManager in a a "contextDestroyed" servlet
listener, but in the correctly set "Effective Major.Effective Minor=3.0" I was
not able to use any logging. Apparently the order in which things are being
cleaned up, or just what is cleaned up at all, is different between the 2
cases. How can an application register a servlet listener to ensure log4j's
initialization is done before the application "contextInitialized" methods are
called and and log4j's destruction is done after the application
"contextDestroyed" is called? The goal is to ensure logging is available for
the application's lifecycle.
> 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]
