I am not sure if spawning up and tearing down a new thread pool for each call would be a good idea.
On Mon, Mar 8, 2021 at 10:46 PM Gary Gregory <garydgreg...@gmail.com> 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ı <volkan.yaz...@gmail.com> > 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 <cko...@ckozak.net> 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? > > > > > > > >
