[
https://issues.apache.org/jira/browse/LOG4J2-3006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17273124#comment-17273124
]
Ralph Goers commented on LOG4J2-3006:
-------------------------------------
I don't think this should be combined with the thread pool used for the
configuration scheduler. In this case we just want to start a thread to
initialize the service providers asynchronously. It is simply a performance
optimization. Just kicking off a thread would work. I had thought using a
preallocated thread would be less expensive but if that causes other problems
then we don't need to use the common pool.
> 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)
