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: log4j-dev-unsubscr...@logging.apache.org > For additional commands, e-mail: log4j-dev-h...@logging.apache.org >
smime.p7s
Description: S/MIME cryptographic signature
