[jira] [Resolved] (LOG4J2-2366) LoggerContext leak using Log4jLoggerFactory

["Ralph Goers (JIRA)" <ji...@apache.org>]

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