[
https://issues.apache.org/jira/browse/LOG4J2-2158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16379345#comment-16379345
]
Mark Bowman commented on LOG4J2-2158:
-------------------------------------
2.10.1-SNAPSHOT works for me too. I can log from simple threads or executor
threads and the ContextMap is preserved during multiple log events.
We're stuck on 2.6.2 because this is the last release where logging in threads
gets a reliable copy of the ContextMap. Fixing this issue is a major success.
Would it be possible to get 2.10.1 released?
> ThreadContext map is cleared => entries are only available for one log event
> ----------------------------------------------------------------------------
>
> Key: LOG4J2-2158
> URL: https://issues.apache.org/jira/browse/LOG4J2-2158
> Project: Log4j 2
> Issue Type: Bug
> Affects Versions: 2.10.0
> Reporter: Björn Kautler
> Assignee: Remko Popma
> Priority: Critical
> Fix For: 2.11.0
>
>
> In
> {{org.apache.logging.log4j.core.impl.ThreadContextDataInjector.ForCopyOnWriteThreadContextMap.injectContextData}}
> without properties set, the result of
> {{ThreadContext.getThreadContextMap().getReadOnlyContextData()}} is returned
> which was saved in a variable called {{immutableCopy}}.
> {{org.apache.logging.log4j.core.impl.ReusableLogEventFactory.createEvent}}
> calls {{result.clear()}} on that context data when the next log event is
> created.
> Unfortunately the "immutable" copy is not immutable at all, but is cleared on
> the this call and all thread context map entries are lost.
> If I set a {{Property}} on all loggers in the config, then the thread context
> map entries are not cleared, because the internal string map is not given out
> but the entries copied, but that property is also logged then of course.
> If I instead set the system property {{log4j2.garbagefree.threadContextMap}},
> the thread context map entries are also not cleared, as then also the entries
> are copied and not the internal structure given out.
> From what I have seen, I'd say there is a {{immutableCopy.freeze()}} missing
> before the {{immutableCopy}} is returned inside the {{if}}-block.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
