[
https://issues.apache.org/jira/browse/LOG4J2-2506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16732154#comment-16732154
]
Gary Gregory commented on LOG4J2-2506:
--------------------------------------
It sounds like we need a better set of unit tests to give us the confidence
that (1) the code works as we intend and (2) that we can make changes without
introducing regressions.
> MutableLogEvent references to other objects are cleared after each use
> ----------------------------------------------------------------------
>
> Key: LOG4J2-2506
> URL: https://issues.apache.org/jira/browse/LOG4J2-2506
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
> Affects Versions: 2.11.1
> Reporter: Daniel Brugger
> Priority: Major
>
> The changes made in Log4J 2.11.1 / LOG4J2-2269 cause serious problems on our
> side: external references on {{MutableLogEvent}} object, like the
> {{ContextMap}} or even Strings, are cleared on existing LogEvent objects when
> a new LogEvent gets logged. We put additional information into the
> {{ContextMap}} of the {{MutableLogEvent}}, and we cache these objects for a
> while before we output them.
> You might ask why we need to cache LogEvents. We often process large amount
> of data in our framework and this might produce thousands of identical log
> messages. So we wrote an {{Appender}} which caches distinct messages in order
> to eliminate duplicates. At the end of a batch the {{Appender}} gets flushed
> and the unique messages along with their counter are forwarded to another
> {{Appender}}. The counter is maintained in the {{ContextMap}} of the cached
> event, and this counter is later used in the message {{Layout}}. So we cannot
> simply "put it somewhere else", since the missing counter is not the only
> thing, after calling the {{clear()}} method all information is lost.
> As a workaround (hack?) we subclassed {{MutableLogEvent}} and overwrote the
> {{clear()}} method. Works for this time, but we'd prefer a cleaner solution.
> So we ask to turn back the wheel and reestablish the solution how it was in
> 2.11.0 (and at least since ten years). Or provide a backward compatible
> solution. As an idea, one might implement a flag like
> {{MutableLogEvent.clearReferencesAfterLogging}} and only if it's {{true}} the
> {{clear()}} method gets called. By default - and in order to stay backward
> compatible - this flag could be {{false}}.
> Thanks.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
