[
https://issues.apache.org/jira/browse/LOG4J2-406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13772489#comment-13772489
]
Remko Popma commented on LOG4J2-406:
------------------------------------
Nick, I did't have much time to work on this but I've added a way to unregister
all MBeans associated with a LoggerContext.
{{org.apache.logging.log4j.core.jmx.Server#unregisterContext(String
loggerContextName)}}
Next step would be calling this method when a web application is undeployed.
> 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: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
