[
https://issues.apache.org/jira/browse/LOG4J2-570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13945108#comment-13945108
]
Scott commented on LOG4J2-570:
------------------------------
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. I believe the servlet container is a common enough
use case for java applications to mark the issue as a no-fix, but at least
there is a proposed workaround (*see followup). The unfortunate part is that
leak will likely go undetected until disaster strikes (PermGen exhausted), and
may be difficult to diagnose for some developers in the 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: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
