Alexander, > it is not expected that a user may want to specify their own custom executor
That would be nice, but I'm not sure if this fits into Ignite 3 configuration approach. I'd like to hear more opinions on this. On Fri, Aug 20, 2021 at 8:10 AM Courtney Robinson <courtney.robin...@hypi.io> wrote: > Pavel I would really welcome this - when we first started with Ignite we > were constantly getting the Ignite threads blocked because we'd perform > other work on it. > > I don't know about the configuration part however because this isn't a > static thing I'd argue. > Is Ignite 3 still using its own types or is it switching to > CompletableFuture > < > https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/CompletableFuture.html > > > ? > The key APIs in CompletableFuture (acceptEitherAsync,applyToEitherAsync, > handleAsync, thenAcceptASync, thenComposeAsync, whenCompleteAsync) all > already accept an Executor argument so returning CompletableFuture solves > the problem, it'd just need documentation. > > If Ignite 3 still uses its own types then I'd suggest what's needed is an > argument to accept a custom Executor. > We have dedicated pools configured now with custom UncaughtExceptionHandler > and ThreadFactory > < > https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/ThreadFactory.html > > > that > we have various metrics and customisations around. If the only option is > the default ForkJoinPool#commonPool we'd lose this when eventually moving > to 3. > > Regards, > Courtney Robinson > Founder and CEO, Hypi > Tel: ++44 208 123 2413 (GMT+0) <https://hypi.io> > > <https://hypi.io> > https://hypi.io > > > On Thu, Aug 19, 2021 at 5:08 PM Alexander Polovtcev < > alexpolovt...@gmail.com> > wrote: > > > Pavel, thanks for the response. Do I understand correctly that it is not > > expected that a user may want to specify their own custom executor? > > > > On Thu, Aug 19, 2021 at 6:55 PM Pavel Tupitsyn <ptupit...@apache.org> > > wrote: > > > > > Hi Alexander, > > > > > > To be honest, I'm not sure yet - just getting to know this new > > > configuration mechanism and format. > > > > > > Since we can't use a property of type Executor, we'll have to provide > > > predefined values. > > > It can either be "bool executeAsyncContinuationsDirectly": false > > (default) > > > => commonPool, true => Runnable::run, > > > or "String asyncContinuationExecutor" which allows two values "direct" > > and > > > "commonPool". > > > > > > I'm leaning towards the latter: > > > > > > { > > > "node": { > > > "metastorageNodes": [ "node-0" ], > > > "asyncContinuationExecutor": "commonPool" > > > }, > > > "network": { ... } > > > } > > > > > > > > > > > > On Thu, Aug 19, 2021 at 6:29 PM Alexander Polovtcev < > > > alexpolovt...@gmail.com> > > > wrote: > > > > > > > Hi, Pavel! > > > > > > > > Can you please provide an example (e.g. HOCON snippet) of how this > > > > configuration is going to look like in Ignite 3? Or how is this > > property > > > > going to be set? > > > > > > > > > > > > On Thu, Aug 19, 2021 at 6:00 PM Pavel Tupitsyn <ptupit...@apache.org > > > > > > wrote: > > > > > > > > > Igniters, > > > > > > > > > > I propose to add a configurable async continuation executor for > > public > > > > APIs > > > > > to Ignite 3 > > > > > like we have in Ignite 2.x [1] > > > > > > > > > > In short, currently, async APIs return a future to the user code. > > > > > Continuations like "myCode" in "table.getAsync().thenApply(myCode)" > > > will > > > > be > > > > > executed by the same thread that completes the future, which will > be > > a > > > > > Netty thread or some other Ignite thread. > > > > > > > > > > This is dangerous because user code can be blocking or > long-running, > > > and > > > > > system threads become unavailable. > > > > > > > > > > Proposal: > > > > > 1. Add asyncContinuationExecutor configuration property, defaults > to > > > > > ForkJoinPool#commonPool - both for server and thin client > > > > > 2. Use this executor to complete all public API futures > > > > > > > > > > This means safe default behavior and a possibility to enable unsafe > > but > > > > > faster behavior with Runnable::run executor. > > > > > > > > > > Thoughts? > > > > > > > > > > > > > > > [1] > > > > > > > > > > > > > > > > > > > > https://cwiki.apache.org/confluence/display/IGNITE/IEP-70%3A+Async+Continuation+Executor > > > > > > > > > > > > > > > > > -- > > > > With regards, > > > > Aleksandr Polovtcev > > > > > > > > > > > > > -- > > With regards, > > Aleksandr Polovtcev > > >
