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? > > > > >
