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

["Remko Popma (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/LOG4J2-570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Remko Popma reopened LOG4J2-570:
--------------------------------


Reopened. (We haven't found a solution yet, but that's not a good reason to close the issue.) 

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