You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by "Scott (JIRA)" <ji...@apache.org> on 2014/07/11 17:06:05 UTC
[jira] [Comment Edited] (LOG4J2-578) JMX Memory Leak in Servlet
Container
[ https://issues.apache.org/jira/browse/LOG4J2-578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14058860#comment-14058860 ]
Scott edited comment on LOG4J2-578 at 7/11/14 3:04 PM:
-------------------------------------------------------
Results have not changed with rc2 (and tomcat 7.0.54):
# Good - Memory leak is *not* present if servlet version is correctly set in web.xml.
# Bad - "contextDestroyed" method logging still does *not* work.
Test case:
# Configure tomcat
* enable auto deploy in server.xml
* configure tomcat-users.xml to enable a manager-gui user role
# Start tomcat (run startup.sh)
# Build the smem-0.1.war application (source code attached to this issue, built by maven)
# cp target/smem-0.1.war <tomcat-root>/webapps/smem.war
# tail -f <tomcat-root>/logs/catalina.out
# Go to http://localhost:8080/manager/html to control webapps.
# Click 'Start' button for '/smem' Path.
# Observe log file contains "-----in contextInitialized" (done by System.out.println) followed by the servlet version information. (done by Logger.log) (See ContextFinalizer.java in smem code)
# Click 'Stop' button for '/smem' Path.
# Observe log file contains "-----in contextDestroyed" (done by System.out.println). This is the issue where the logging context is destroyed prematurely an no log statements in "contextDestroyed" make it to the output file.
An interesting thing I noticed is that if Tomcat and the WAR are run by maven using 'mvn tomcat7:run' and the Tomcat application is terminated with a kill signal 'CTRL+C' then the "contextDestroyed" method is able to log to the console. I hope this gives a hint if things are destructed differently w.r.t to log4j in these 2 use cases.
I did not test the case with no web.xml and instead using spring java configuration because I am assuming this is a Spring (or likely my annotation configuration of Spring) issue of not setting the servlet version correctly? You said that {quote}Log4J auto-initialization needs this version to be correct. (See comments in LOG4J2-529 for details.){quote}
Can you provide more details as to how log4j is accessing this information? For example from my above comments/testing is appears log4j may be using the {code}getEffectiveMajorVersion{code} and {code}getEffectiveMinorVersion{code} on the {code}ServletContext{code} servlet instance.
was (Author: smitchel):
Results have not changed with rc2 (and tomcat 7.0.54):
# Good - Memory leak is *not* present if servlet version is correctly set in web.xml.
# Bad - "contextDestroyed" method logging still does *not* work.
Test case:
# Configure tomcat
* enable auto deploy in server.xml
* configure tomcat-users.xml to enable a manager-gui user role
# Start tomcat (run startup.sh)
# Build the smem-0.1.war application (source code attached to this issue, built by maven)
# cp target/smem-0.1.war <tomcat-root>/webapps/smem.war
# tail -f <tomcat-root>/logs/catalina.out
# Go to http://localhost:8080/manager/html to control webapps.
# Click 'Start' button for '/smem' Path.
# Observe log file contains "-----in contextInitialized" (done by System.out.println) followed by the servlet version information. (done by Logger.log) (See ContextFinalizer.java in smem code)
# Click 'Stop' button for '/smem' Path.
# Observe log file contains "-----in contextDestroyed" (done by System.out.println). This is the issue where the logging context is destroyed prematurely an no log statements in "contextDestroyed" make it to the output file.
An interesting thing I noticed is that if Tomcat and the WAR are run by maven using 'mvn tomcat7:run' and the Tomcat application is terminated with a kill signal 'CTRL+C' then the "contextDestroyed" method is able to log to the console. I hope this gives a hint if things are destructed differently w.r.t to log4j in these 2 use cases.
I did not test the case with no web.xml and instead using spring java configuration because I am assuming this is a Spring issue of not setting the servlet version correctly? You said that {quote}Log4J auto-initialization needs this version to be correct. (See comments in LOG4J2-529 for details.){quote}
Can you provide more details as to how log4j is accessing this information? For example from my above comments/testing is appears log4j may be using the {code}getEffectiveMajorVersion{code} and {code}getEffectiveMinorVersion{code} on the {code}ServletContext{code} servlet instance.
> 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
> Assignee: Remko Popma
> Priority: Critical
> Labels: memory_leak
> Attachments: smem.tar.gz
>
>
> 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