[ https://issues.apache.org/jira/browse/LOG4J2-2366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ralph Goers resolved LOG4J2-2366. --------------------------------- Resolution: Fixed Fix Version/s: 2.12.1 Fix has been applied. Please verify and close. > LoggerContext leak using Log4jLoggerFactory > ------------------------------------------- > > Key: LOG4J2-2366 > URL: https://issues.apache.org/jira/browse/LOG4J2-2366 > Project: Log4j 2 > Issue Type: Bug > Components: SLF4J Bridge > Affects Versions: 2.11.0 > Reporter: Luciano Raineri Marchina > Priority: Major > Fix For: 2.12.1 > > Attachments: minimal_example.7z, patched_after.hprof.7z, > patched_after_waited.hprof.7z, patched_before.hprof.7z > > > Hi all! > We are using log4j2 as the logging framework for our applications. > This is done by using the log4j implementation provided for slf4j. > The problem we are seeing is that after many application redeploys, many > LoggerContexts are still referenced, even after stopping them. > I've taken many heap dumps of our standalone server and found that many of > these references are kept by a WeakHashMap<> instantiated in the > Log4jLoggerFactory. ('registry' attribute of > org.apache.logging.log4j.spi.AbstractLoggerAdapter) > What happens is that, even when the Map is a WeakHashMap (Where the keys > should be weakly referenced), it will never be cleared because it's values > keep references to those same keys. > If you check the heap dumps that i've provided, you can see that most of the > LoggerContexts (org.mule.runtime.module.launcher.log4j2.MuleLoggerContext) > states are: STOPPED and even it's loggers configurations are updated to > NullConfiguration, but the references are kept. > On the other hand, i could remove the references to their contexts for the > loggers ('context' attribute of org.apache.logging.log4j.core.Logger) when > those contexts are stopped but the field is final and private, which makes it > impossible to change for an child class. > For the heapdumps, i took them as follows: > * deployed application > * dumped patched_before.hprof > * redeployed app 10 times > * dumped patched_after.hprof > * waited an hour > * dumped patched_after_waited.hprof > You can see that in _patched_before.hprof_ there are only 4 LoggerContext > instances while in _patched_after.hprof_ and _patched_after_waited.hprof_ > there are around 16, most of them referenced by a logger that is linked to a > value in the WeakHashMap mentioned above. > I think that you should, either provide a way to remove entries from that > 'registry', or check for circular dependencies somehow so that they are > removed by the GC. > Thanks! -- This message was sent by Atlassian JIRA (v7.6.14#76016)