[
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)
