The ThreadPool for ConfigurationScheduler is tied to the Configuration. So it 
isn’t created until after plugins are loaded (its name should make that 
obvious). Also, the number of threads it configures the thread pool for is 
determined based on what it finds in the configuration. It is quite possible 
that the ConfigurationScheduler might not even create an ExecutorService if it 
determines there are no scheduled items configured.

Ralph

> On Mar 8, 2021, at 2:46 PM, Gary Gregory <[email protected]> wrote:
> 
> We do have a thread pool factory that decorates thread names with
> "log4j" IIRC...
> 
> On Mon, Mar 8, 2021 at 4:29 PM Volkan Yazıcı <[email protected]> wrote:
>> 
>> Do we have a Log4j-specific ExecutorService somewhere we can hook into
>> PluginManager?
>> 
>> On Mon, Mar 8, 2021 at 10:24 PM Carter Kozak <[email protected]> wrote:
>> 
>>> Please don't use stream.parallel! It executes tasks on the ForkJoin pool
>>> which implements work-stealing, and can result in expensive long-running
>>> operations from other components in the system that we don't expect
>>> blocking our call (anything using the fork-join pool, all stream.parallel
>>> callers). This is a good read:
>>> https://stackoverflow.com/a/54581148/7182570
>>> 
>>> On Mon, Mar 8, 2021, at 16:06, Volkan Yazıcı wrote:
>>>> PluginManager#collectPlugins() performs quite some package scanning
>>>> sequentially. I have the impression that this operation can simply be
>>>> parallelized as follows:
>>>> 
>>>> Stream
>>>>        .of(inputs)
>>>>        .flatMap(input -> Stream
>>>>            .of(ops)
>>>>            .map(op -> new Object[]{op, input}))
>>>>        .parallel()
>>>>        .map(opAndInput -> {
>>>>            final Function<Input, Output> op = opAndInput[0];
>>>>            final Input input = opAndInput[1];
>>>>            return op.accept(input);
>>>>        })
>>>>        .reduce(this::merge);
>>>> 
>>>> Here input denotes the packages and ops denote the independent sequential
>>>> steps performed in collectPlugins(). I don't know about the overhead of
>>>> this call, but the above simple effort might be worth a shot. What do you
>>>> think?
>>>> 
>>> 
> 


Reply via email to