logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gary Gregory (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (LOG4J2-570) Memory Leak
Date Sun, 23 Mar 2014 17:39:44 GMT

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

Gary Gregory commented on LOG4J2-570:
-------------------------------------

so add a big red warning in the docs?

> 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


Mime
View raw message