[
https://issues.apache.org/jira/browse/LOG4J2-406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13772132#comment-13772132
]
Kerrigan Joseph edited comment on LOG4J2-406 at 9/19/13 6:15 PM:
-----------------------------------------------------------------
A sample netbeans project illustrating the issue. If this project is deployed
and undeployed, an examination of a jmap dump of the tomcat process using jhat
should indicate that it is still loaded. The web.xml file has some commented
out sections that demonstrate one of the workarounds.
was (Author: karjaneth):
A sample netbeans project illustrating the issue
> JMX MBeans are not being unregistered when a tomcat web application that uses
> log4j is undeployed, leading to a permgen memory leak.
> ------------------------------------------------------------------------------------------------------------------------------------
>
> Key: LOG4J2-406
> URL: https://issues.apache.org/jira/browse/LOG4J2-406
> Project: Log4j 2
> Issue Type: Bug
> Components: Core, JMX
> Affects Versions: 2.0-beta9
> Environment: Java 1.7.0_17-b02, tomcat 7.0.34.0, NetBeans 7.3,
> Windows 7 (64 bit)
> Reporter: Kerrigan Joseph
> Attachments: PermGen.zip
>
>
> When the log4j2 library is being used with a tomcat web application (included
> in the web application's libraries, not in the container's libraries), tomcat
> correctly discovers and initializes the Log4jServletContainerInitializer and
> adds the Log4JServletContextListener as described in the
> [manual|http://logging.apache.org/log4j/2.x/manual/webapp.html] (after
> removing "log4j*.jar" from the jarsToSkip property as described on that
> page). However, two MBeans that log4j registers (ContextSelector and
> StatusLogger) are never unregistered when the web application is undeployed.
> This prevents the entire web application from being garbage collected and
> leads to a permgen memory leak and causes an OutOfMemoryError after a few
> undeploy/redeploy cycles*.
> We could work around this by taking the following steps:
> # Added a context parameter to the web.xml file specifying a value for the
> log4jContextName parameter. This seems to prevent
> java.lang.ApplicationShutdownHooks from keeping a refernce to the log4j
> LoggerContext, which was part of why the memory leak was occuring**.
> # In addition, took one of the following measures:
> #* Added the log4j2 libraries to tomcat's classpath. Regardless of whether or
> not the libraries were in the web application's classpath, this seemed to
> circumvent the entire issue.
> #* Disabled jmx entirely, by adding -Dlog4j.disable.jmx=true to the JVM
> options for tomcat.
> #* Added a custom ServletContextListener which manually unregisters all log4j
> MBeans upon the destruction of the context.
> Any of the steps from 2 worked equally well, but none of them worked unless
> we also took step 1.
> \* We used jmap and jhat to confirm that the application was not being
> unloaded from memory after being undeployed, and were able to narrow the
> cause down to those MBeans by tracing a reference path from the
> StandardClassloader through them to the WebappClassLoader.
> \** We're unsure of what role ApplicationShutdownHooks plays in this
> scenario, but we observed in jhat that the reference path between log4j and
> ApplicationShutdownHooks disappeared after adding the log4jContextName
> parameter, and that this was necessary to stop the permgen memory leak.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
