[
https://issues.apache.org/jira/browse/LOG4J2-2366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16894622#comment-16894622
]
Ralph Goers commented on LOG4J2-2366:
-------------------------------------
This may just be repeating what you said, but in a form that is clearer to me.
In looking at the code it seems an org.apache.logging.log4j.core.Logger is
going to be created and wrapped in an SLF4J Logger. This will then be stored
into the ConcurrentMap that is the value of the Map entry. This strong
reference will prevent the WeakHashMap entry from being removed.
I will look into how to fix this.
> 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
> 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)
