[
https://issues.apache.org/jira/browse/LOG4J2-479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13861649#comment-13861649
]
Ralph Goers commented on LOG4J2-479:
------------------------------------
Log4j 1.x used an InheritableThreadLocal for the MDC and a Hashtable with the
current thread as the key for the NDC. Since the NDC is a Stack it doesn't
make any sense for multiple threads to manipulate it. I believe Logback used
to use an InheritableThreadLocal but does something different now that has the
same effect (it copies the data from the parent thread). Our implementation is
the same is these for compatibility. This means you will get the same behavior
when you are using the SLF4J API. However, this issue has been raised a couple
of times on the Logback and there are open Jira issues for it. The most
logical proposal is one to allow a system property to control whether the child
inherits from its parent.
> Use of InheritableThreadLocal in Map ThreadContext is dangerous and unhelpful
> -----------------------------------------------------------------------------
>
> Key: LOG4J2-479
> URL: https://issues.apache.org/jira/browse/LOG4J2-479
> Project: Log4j 2
> Issue Type: Bug
> Reporter: MK
>
> Described here http://logging.apache.org/log4j/2.x/manual/thread-context.html
> The use of InheritableThreadLocal creates subtle and hard to track bugs while
> not really adding much useful. It is counterintuitive -- I don't see why
> would anyone expect logging context to be inherited. But it breaks down
> completely when used with Thread Executors.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
