[
https://issues.apache.org/jira/browse/LOG4J2-479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13861703#comment-13861703
]
Nick Williams commented on LOG4J2-479:
--------------------------------------
In my opinion, we need to take one of two paths:
#Remove uses of {{InheritableThreadLocal}} completely.
#Make a system option to enable use of {{InheritableThreadLocal}}, but *disable
it by default* so that values are not inherited unless specifically enabled.
In applications that use thread pools to spin off long-running processes (and
this is a lot of applications), an {{InheritableThreadLocal}} is *dangerous*.
Before the thread pool is used for the first time, it is initially empty. It
hasn't yet created any threads. If a thread sets the value in an
{{InheritableThreadLocal}} and then borrows a thread from that pool, the pool
will create a thread with the same {{InheritableThreadLocal}} values. That
thread will then always have that value, even after the application returns it
to the pool. Even worse, in a web application multiple applications could share
a single thread pool, resulting in information leaking from one application to
another.
> 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
