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 >
