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