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] [Commented] (LOG4J2-570) Memory Leak
Date Mon, 24 Mar 2014 21:54:48 GMT

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

Scott commented on LOG4J2-570:
------------------------------

Sounds promising. Can you explain why 2 shutdown hooks are needed?  Is there some way tomcat
(or servlet containers in general) can be shutdown where the ServletContextListener contextDestroyed
is not called for each listener, but the Tomcat System.exit() event causes the additional
shutdown hook to be called?  In the simple use cases (stopping/unloading/redeploying, using
the tomcat shutdown scripts, and even killing the Tomcat application from Visual VM) the contextDestroyed
methods are called (verified via log4j2 log file output).

Using a weak reference will likely help for this use-case, but is there a potential this will
break other use-cases that are relying on a non-weak pointer?

I created another issue for the JMX memory leak (LOG4J2-578) as per your earlier suggestion.

> 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


Mime
View raw message