[
https://issues.apache.org/jira/browse/LOG4J2-570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13945108#comment-13945108
]
Scott edited comment on LOG4J2-570 at 3/24/14 2:08 PM:
-------------------------------------------------------
Thank you for looking into this Matt. I had a feeling the solution to this
issue may be constrained due to existing design and hooks w.r.t to servlet
containers. It is unfortunate detection can not be done prior to adding the
hook as Remko suggested. Are there usage statistics on log4j/log4j2 to know
whether webapp/servlet deployment is a common enough use case to avoid a
"no-fix" resolution? If the the proposed workaround (*see followup) does not
work then I believe application developers are forced to use logback for this
use-case (need to stop/redeploy/undeploy webapp). The difficult part for
application developers is that the leak will likely go undetected until
disaster strikes (PermGen exhausted), and may be difficult to diagnose for some
developers in the webapp/servlet use-case.
Given the current state of affairs it may be beneficial to reference the
logback code base. They provide an accessor to the LoggerContext for which the
stop method can be invoked
(http://logback.qos.ch/manual/configuration.html#stopContext) to explicitly
cleanup. More importantly they have figured out a way to either not start
certain aspects of the infrastructure or clean up without explicit
configuration or even explicitly closing the LoggerContext as described in
their documentation (see code attached which uses logback-classic but does not
close LoggerContext).
*Can you clarify the proposed workaround? Is the workaround to add an
attribute to the "log4j2.xml" <Configuration> element which is
'shutdownHook="disable"'? Is there anything else that needs to be done as I am
still seeing a memory leak but with 1 layer of referencing removed. To clarify
an instance of "org.apache.logging.log4j.core.jmx.LoggerContextAdmin"
classloader is now the only class which still has hard references that remain
(to "org.apache.catalina.loader.WebappClassLoader") and is preventing GC from
cleaning up resources.
was (Author: smitchel):
Thank you for looking into this Matt. I had a feeling the solution to this
issue may be constrained due to existing design and hooks w.r.t to servlet
containers. It is unfortunate detection can not be done prior to adding the
hook as Remko suggested. Are there usage statistics on log4j/log4j2 to know
whether webapp/servlet deployment is a common enough use case to avoid a
"no-fix" resolution? If the the proposed workaround (*see followup) does not
work then I believe application developers are forced to use logback for this
use-case (need to stop/redeploy/undeploy webapp). The difficult part for
application developers is that the leak will likely go undetected until
disaster strikes (PermGen exhausted), and may be difficult to diagnose for some
developers in the webapp/servlet use-case.
Given the current state of affairs it may be beneficial to reference the
logback code base. They provide an accessor to the LoggerContext for which the
stop method can be invoked
(http://logback.qos.ch/manual/configuration.html#stopContext) to explicitly
cleanup. More importantly they have figured out a way to either not start
certain aspects of the infrastructure or clean up without explicit
configuration or even explicitly closing the LoggerContext as described in
their documentation (see code attached which uses logback-classic but does not
close LoggerContext).
*Can you clarify the proposed workaround? Is the workaround to add an
attribute to the "log4j2.xml" <Configuration> element which is
'shutdownHook="disable"'? Is there anything else that needs to be done as I am
still seeing a memory leak but with 1 layer of referencing removed. To clarify
the an instance of "org.apache.logging.log4j.core.jmx.LoggerContextAdmin"
classloader is now the only class which still has hard references that remain
(to "org.apache.catalina.loader.WebappClassLoader") and is preventing GC from
cleaning up resources.
> Memory Leak
> -----------
>
> Key: LOG4J2-570
> URL: https://issues.apache.org/jira/browse/LOG4J2-570
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
> Affects Versions: 2.0-rc1
> Environment: Ubuntu 12.04
> Linux bos-lpuv7 3.2.0-58-generic #88-Ubuntu SMP Tue Dec 3 17:37:58 UTC 2013
> x86_64 x86_64 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
> <log4j.version>2.0-rc1</log4j.version>
> log4j-api
> log4j-core
> log4j-jcl
> Spring webmvc 4.0.2.RELEASE application (simple hello world) deployed in
> tomcat7.0.52 container.
> Reporter: Scott
> Assignee: Matt Sicker
> Priority: Blocker
> Fix For: 2.0-rc2
>
> Attachments: spring_log4j2_memory_leak.tbz2
>
>
> Dynamically loading a JAR that uses log4j2 results in a memory leak when the
> JAR is unloaded. This can be observed by deploying a web application to
> tomcat7 and exercising the stop, undeploy, or redeploy actions. 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
> (of type org.apache.catalina.loader.WebappClassLoader) has 2 non weak/soft
> reference which are of type
> (org.apache.logging.log4j.core.LoggerContext$ShutdownThread) and
> (org.apache.logging.log4j.core.jmx.LoggerContextAdmin) after the WAR has been
> stopped or undeployed.
> 2)Using SLF4J (slf4j-api, jcl-over-slf4j) to logback-classic logging output
> is equivalent but all memory is gc as expected (the
> org.apache.catalina.loader.WebappClassLoader which loaded the WAR is no
> longer referenced by any hard references)
> 3)Using the SLF4J NOP logger implementation all memory is gc as expected (the
> org.apache.catalina.loader.WebappClassLoader which loaded the WAR is no
> longer referenced by any hard references)
> This may not be unique to 2.0rc-1 and I have seen similar behavior in
> previous 2.0 beta releases.
> This is reproducible with a very simple spring hello world application. Code
> and/or heap dumps can be provided upon request.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
