[
https://issues.apache.org/jira/browse/LOG4J2-2366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16533003#comment-16533003
]
Ralph Goers edited comment on LOG4J2-2366 at 7/4/18 6:41 PM:
-------------------------------------------------------------
Can this be duplicated without Mule? Mule has its own MuleLoggerContext and
also apparently has a LoggerContextCache. It is unclear how those may, or may
not, play into what you are seeing.
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. For
example, If I have a situation where A references B which references C, C will
be cleaned up so long as B is the only thing referencing it, A is the only
thing referencing B and nothing references A.
was (Author: [email protected]):
Can this be duplicated without Mule? Mule has its own MuleLoggerContext and
also apparently has a LoggerContextCache. It is unclear how those may, or may
not, play into what you are seeing.
It is important to note that having Loggers reference the LoggerContext will
not cause the LoggerContext from being cleaned up, so long as the Loggers are
not referenceable or the object they reside is no longer referenceable. For
example, If I have a situation where A references B which references C, C will
be cleaned up so long as B is the only thing referencing it, A is the only
thing referencing B and nothing references A.
> 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: 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)
