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] [Commented] (LOG4J2-1176) Memory leak from first loaded web app when log4j jars are in Tomcat's lib folder
Date Sun, 01 Nov 2015 12:31:27 GMT

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

Remko Popma commented on LOG4J2-1176:

Yourkit is indeed a fine project. We should get an [open source license|https://www.yourkit.com/purchase/#licenses]
for it. I finally made some progress on this.

# One leak was caused by the StatusLogger. Objects were retained in the ParameterizedMessage
objects kept in the StatusLogger's bounded queue of StatusData objects. I introduced a special
MessageFactory for StatusLogger that does not keep a reference to the parameter objects. (in
master in commit abc0f948)
# Another leak is caused by the design of OutputStreamManager: it has a reference to the layout
of the first Appender it was created for. The leak occurs as follows: DefaultConfiguration
creates a ConsoleAppender with a PatternLayout. PatternLayout has a reference to its Configuration.
As a result, the OutputStreamManager retained in AbstractManager.MAP keeps a reference to
the first DefaultConfiguration (whether this config is STOPPED or not). 

Still thinking on how to fix #2.

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

To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org

View raw message