logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Scott (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (LOG4J2-570) Memory Leak
Date Tue, 18 Mar 2014 22:48:43 GMT

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

Scott updated LOG4J2-570:
-------------------------

    Description: 
The tomcat7 stop, undeploy, or redeploy actions on a WAR which utilizes log4j can create a
memory leak.  The memory leak is believed to be 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 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 and I can provide more information if necessary.  I don't see anywhere
to attach a heap dump, but a sequence of these and simple hello world source code can be supplied
upon request.

  was:
The tomcat7 stop, undeploy, or redeploy actions on a WAR which utilizes log4j leaves creates
a memory leak.  The memory leak is believed to be 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 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 and I can provide more information if necessary.  I don't see anywhere
to attach a heap dump, but a sequence of these and simple hello world source code can be supplied
upon request.


> 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
>              Labels: memory_leak
>             Fix For: 2.0-rc2
>
>   Original Estimate: 336h
>  Remaining Estimate: 336h
>
> The tomcat7 stop, undeploy, or redeploy actions on a WAR which utilizes log4j can create
a memory leak.  The memory leak is believed to be 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 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 and I can provide more information if necessary.  I don't see anywhere
to attach a heap dump, but a sequence of these and simple hello world source code can be supplied
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