You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ignite.apache.org by Pavel Tupitsyn <pt...@apache.org> on 2021/08/19 14:59:53 UTC
Ignite 3 async continuation executor
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
Re: Ignite 3 async continuation executor
Posted by Pavel Tupitsyn <pt...@apache.org>.
Courtney,
Ignite 3 uses CompletableFuture.
Yes, it has thenApplyAsync and other methods which accept an Executor,
but we can't force user code to use those methods and not thenApply.
Thanks for describing your use case with custom thread pools,
we'll figure out how to support that in 3.x
On Fri, Aug 20, 2021 at 9:31 AM Pavel Tupitsyn <pt...@apache.org> wrote:
> 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.robinson@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 <
>> alexpolovtcev@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 <pt...@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 <
>> > > alexpolovtcev@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 <
>> ptupitsyn@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
>> >
>>
>
Re: Ignite 3 async continuation executor
Posted by Pavel Tupitsyn <pt...@apache.org>.
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 <co...@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 <
> alexpolovtcev@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 <pt...@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 <
> > > alexpolovtcev@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 <ptupitsyn@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
> >
>
Re: Ignite 3 async continuation executor
Posted by Courtney Robinson <co...@hypi.io>.
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 <al...@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 <pt...@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 <
> > alexpolovtcev@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 <pt...@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
>
Re: Ignite 3 async continuation executor
Posted by Alexander Polovtcev <al...@gmail.com>.
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 <pt...@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 <
> alexpolovtcev@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 <pt...@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
Re: Ignite 3 async continuation executor
Posted by Pavel Tupitsyn <pt...@apache.org>.
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 <al...@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 <pt...@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
>
Re: Ignite 3 async continuation executor
Posted by Alexander Polovtcev <al...@gmail.com>.
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 <pt...@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