[
https://issues.apache.org/jira/browse/LOG4J2-570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13945725#comment-13945725
]
Matt Sicker commented on LOG4J2-570:
------------------------------------
In regard to the logback version, you can already do the same thing:
{code}
import org.apache.logging.log4j.LogManager;
import org.apache.logging.log4j.core.LoggerContext;
// ...
LoggerContext ctx = (LoggerContext) LogManager.getContext();
ctx.stop();
{code}
It's actually amusing how similar that is. If you use log4j in a servlet
context, there's a ServletContextListener that starts and stops the
LoggerContext on init and destroy respectively for the ServletContext. The
memory leak was caused due to an additional shutdown hook thread being spawned
that won't be called until Tomcat (or whatever server) calls System.exit()
(clearly doesn't happen when an application is undeployed).
Now if the shutdown hook is preventing the LoggerContext from being cleaned up,
I think that could be fixed by using a weak reference in the shutdown thread so
that it doesn't prevent clean up. I'm not so sure about the LoggerContextAdmin
class. I'll take a look to see if I can find anything obvious, but I'm not
experienced with the JMX standard.
> 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 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
> <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
> Labels: memory_leak
> 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
