[
https://issues.apache.org/jira/browse/LOG4J2-3006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17272331#comment-17272331
]
Matt Sicker commented on LOG4J2-3006:
-------------------------------------
There are thread factories and pools and whatnot for various things in Log4j,
so if any ForkJoinPool can be combined into the other thread management code,
that'd probably help simplify things.
> 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)
