[jira] [Commented] (LOG4J2-570) Memory Leak

["Matt Sicker (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/LOG4J2-570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13944139#comment-13944139 ] 

Matt Sicker commented on LOG4J2-570:
------------------------------------

Well this is turning out to be a bit more complicated than I originally thought! Spawning off a shutdown hook thread in a web container is a bad idea due to problems like this, so I'm looking at alternative ways to shutdown in a web context. I see that we could use a ServletContextListener to shut down when the ServletContext is destroyed, but we'll need to make sure that's only done for the LoggerContext associated to that ServletContext so that if log4j is a server library, it doesn't shut down everyone. Seems like this could work. I think the JMX class that stays loaded is due to the shutdown thread staying behind which references the LoggerContext linked to the JMX class.

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