[
https://issues.apache.org/jira/browse/LOG4J2-570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Sicker resolved LOG4J2-570.
--------------------------------
Resolution: Fixed
Shutdown thread memory leak fixed in r1592429.
> 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
