[
https://issues.apache.org/jira/browse/LOG4J2-2366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16534064#comment-16534064
]
Luciano Raineri Marchina edited comment on LOG4J2-2366 at 7/6/18 2:06 AM:
--------------------------------------------------------------------------
Hi Ralph!
First of all, thanks for the quick response.
??It is important to note that having Loggers reference the LoggerContext will
not prevent the LoggerContext from being cleaned up, so long as the Loggers are
not referenceable or the object they reside is no longer referenceable.??
The loggers will always be referenceable by the entries in the WeakHashMap i
mentioned which is referenced by the loggerFactory which is always referenced
by the StaticLoggerBinder class.
I'm now attaching a minimal example of the same issue being replicated without
Mule, along with some heap dumps i took to check that the leak was indeed
happening.
[^minimal_example.7z]
was (Author: lucianorm):
Hi Ralph!
First of all, thanks for the quick response.
??It is important to note that having Loggers reference the LoggerContext will
not prevent the LoggerContext from being cleaned up, so long as the Loggers are
not referenceable or the object they reside is no longer referenceable.??
The loggers will always be referenceable by the entries in the WeakHashMap i
mentioned.
I'm now attaching a minimal example of the same issue being replicated without
Mule, along with some heap dumps i took to check that the leak was indeed
happening.
[^minimal_example.7z]
> 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.3#76005)
