logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Remko Popma (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (LOG4J2-1176) Memory leak from first loaded web app when log4j jars are in Tomcat's lib folder
Date Sun, 08 Nov 2015 06:43:10 GMT

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

Remko Popma edited comment on LOG4J2-1176 at 11/8/15 6:42 AM:
--------------------------------------------------------------

I finally found the remaining underlying cause: {{org.apache.logging.log4j.spi.Provider}}
has a strong reference to the web app ClassLoader that was used to find {{log4j-provider.properties}}.
{{ProviderUtil}} keeps a static reference to a set of all loaded Providers, so the web app's
classloader can not be garbage collected.

The solution is to wrap the reference to the classloader in Provider in a WeakReference.

Fixed in commits 83c22472, a02d50b9 and 60dd2265.



was (Author: remkop@yahoo.com):
I finally found the underlying cause: {{org.apache.logging.log4j.spi.Provider}} has a strong
reference to the web app ClassLoader that was used to find {{log4j-provider.properties}}.
{{ProviderUtil}} keeps a static reference to a set of all loaded Providers, so the web app's
classloader can not be garbage collected.

The solution is to wrap the reference to the classloader in Provider in a WeakReference.

Fixed in commits 83c22472, a02d50b9 and 60dd2265.


> Memory leak from first loaded web app when log4j jars are in Tomcat's lib folder
> --------------------------------------------------------------------------------
>
>                 Key: LOG4J2-1176
>                 URL: https://issues.apache.org/jira/browse/LOG4J2-1176
>             Project: Log4j 2
>          Issue Type: Bug
>          Components: Configurators, Web/Servlet
>    Affects Versions: 2.4.1, 2.5
>         Environment: Tomcat 7.0.50 or Tomcat 7.0.65, jdk1.8.0_51, Win 10
>            Reporter: Remko Popma
>            Assignee: Remko Popma
>             Fix For: 2.5
>
>         Attachments: webapp.war
>
>
> When the log4j2 jar files are in $catalina.home/lib, the first web application that is
loaded will be reported by Tomcat as having a memory leak from loaded classes. 
> *1. Steps to reproduce*
> # Install Tomcat 7.0.65 afresh
> # Copy log4j-api-2.5-SNAPSHOT.jar, log4j-core-2.5-SNAPSHOT.jar, log4j-web-2.5-SNAPSHOT.jar
into $catalina.home/lib.
> # (Optional) place a log4j2.xml config file with status="true" in $catalina.home/lib.
This helps to confirm that the web app which is loaded first causes the warning.
> # Edit $catalina.home/conf/catalina.properties: add {{log4j2.disable.jmx=true}} (eliminate
JMX as the culprit)
> # Edit $catalina.home/conf/tomcat-users.xml to give yourself permission to access the
Tomcat Web App Manager
> # Start Tomcat
> # Open the [Manager App|http://localhost:8080/manager/html]
> # Reload the Tomcat Documentation (/docs) web app
> # Click the "Find Leaks" button under Diagnostics at the bottom of the Manager App page
> The following warning is displayed:
> {quote}
> The following web applications were stopped (reloaded, undeployed), but their classes
from previous runs are still loaded in memory, thus causing a memory leak (use a profiler
to confirm):
> /docs
> {quote}
> *2. Use custom web app to prove the web app loaded first always has this issue*
> Use the attached web app to test the order of deployment.
> # Restart Tomcat
> # Deploy web app (containing its own log4j2.xml)
> # Restart Tomcat again (note that the custom web app is loaded first)
> # Reload /docs app: no memory leak
> # Reload /webapp: gives memory leak warning
> Different order:
> # Undeploy custom web app
> # Restart Tomcat ( /docs web app is loaded first)
> # Deploy custom web app
> # Reload /docs app: gives memory leak warning
> # Reload /webapp: no memory leak
> I have tried to use [Eclipse Memory Analyzer|https://eclipse.org/mat/] to find out where
the leak is, but without success. 
> (Note that the problem also happens with the default configuration (when no log4j2.xml
config is found), this may narrow things down a little... Perhaps this has something to do
with the StatusLogger?)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
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