I need a chance to review this. I am uncomfortable with hardwiring this. Sent from my iPad
On Sep 19, 2013, at 5:02 PM, Nick Williams <[email protected]> wrote: > Thanks, Remko. > > Team: should this method Remko added be called automatically from > LoggerContext#stop()? > > N > > On Sep 19, 2013, at 6:51 PM, Remko Popma (JIRA) wrote: > >> >> [ >> 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: [email protected] >> For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
