[
https://issues.apache.org/jira/browse/LOG4J2-3006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17280628#comment-17280628
]
ASF subversion and git services commented on LOG4J2-3006:
---------------------------------------------------------
Commit 3482450de877a9e0c1093c45728249a86ff1c7bb in logging-log4j2's branch
refs/heads/master from Ralph Goers
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=3482450 ]
LOG4J2-3006 - Directly create a thread instead of using the common ForkJoin
pool when initializing ThreadContextDataInjector
> ForkJoinPool common pool is initialized, no option to supply another executor
> -----------------------------------------------------------------------------
>
> Key: LOG4J2-3006
> URL: https://issues.apache.org/jira/browse/LOG4J2-3006
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
> Affects Versions: 2.14.0
> Reporter: Jared Wiltshire
> Priority: Major
>
> After upgrading our application to use Log4J 2.14 we discovered that our
> thread factory for the ForkJoinPool common pool was not being used.
> After debugging I discovered that this was because we initialize Log4J before
> we configure the ForkJoinPool. Log4J 2.14 now initializes the ForkJoinPool
> common pool via this line in the constructor:
> {{CompletableFuture.runAsync(ThreadContextDataInjector::initServiceProviders);}}
> This was introduced by LOG4J2-2867. I am not familiar with what
> initServiceProviders is doing but please consider reverting to the previous
> behavior by default and providing an option to supply an executor if desired.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
