[jira] [Comment Edited] (IGNITE-4477) Fix IgniteFuture.listen() and IgniteFuture.chain() semantics
[
https://issues.apache.org/jira/browse/IGNITE-4477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16026161#comment-16026161
]
Dmitry Karachentsev edited comment on IGNITE-4477 at 5/26/17 11:27 AM:
---
[~vozerov],
Thanks for the review!
1) Fixed (missed when removed default pool support).
2) It was made only for less relying on `IgniteInternalFuture`, but for sure,
it's easier to use existing method. Shall I fix this as well?
was (Author: dkarachentsev):
[~vozerov],
Thanks for the review!
1) Fixed (missed when removed default pool support).
2) It was made only for not relying on `IgniteInternalFuture`, but for sure,
it's easier to use existing method. Shall I fix this as well?
> Fix IgniteFuture.listen() and IgniteFuture.chain() semantics
>
>
> Key: IGNITE-4477
> URL: https://issues.apache.org/jira/browse/IGNITE-4477
> Project: Ignite
> Issue Type: Task
> Components: general
>Affects Versions: 1.8
>Reporter: Vladimir Ozerov
>Assignee: Dmitry Karachentsev
> Labels: important
> Fix For: 2.1
>
>
> *Problem*
> We allow users to pass continuations to {{IgniteFuture}} which will be
> executed on future completion. This can be done through {{listen}} or
> {{chain}} methods.
> However, continuation semantics is broken intrinsically:
> 1) If future is already completed, user code executed in the same thread;
> 2) If future is not completed yet, it will be executed in completion thread.
> Neither of this options are valid because it easily leads to starvation. E.g.:
> {code}
> IgniteFuture fut = cache.getAsync(key2);
> fut.listen(fut0 -> {
> cache.put(key2, val2); // Possible deadlock, because invoked in sys pool;
> });
> {code}
> *Solution*
> 1) By default callbacks must be executed asynchronously in some common pool
> (public pool? new "callback pool"? FJP?)
> 2) It should be possible to specify where to execute a callback explicitly:
> {code}
> IgniteFuture.listen(IgniteClosure, ExecutorService);
> {code}
> 3) We may want to expose our public pool on API for convenience.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (IGNITE-4477) Fix IgniteFuture.listen() and IgniteFuture.chain() semantics
[
https://issues.apache.org/jira/browse/IGNITE-4477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15953095#comment-15953095
]
Dmitry Karachentsev edited comment on IGNITE-4477 at 4/4/17 8:21 AM:
-
Vladimir, please review the fix: [PR
1721|https://github.com/apache/ignite/pull/1721]
Instead of two async methods for listen and chain I've added one with nullable
Executor. I don't think we need to duplicate methods just without last argument.
Here is a link to upsource:
[IGNT-CR-156|http://reviews.ignite.apache.org/ignite/review/IGNT-CR-156]
was (Author: dkarachentsev):
Vladimir, please review the fix: [PR
1710|https://github.com/apache/ignite/pull/1710]
Instead of two async methods for listen and chain I've added one with nullable
Executor. I don't think we need to duplicate methods just without last argument.
Here is a link to upsource:
[IGNT-CR-151|http://reviews.ignite.apache.org/ignite/review/IGNT-CR-151]
> Fix IgniteFuture.listen() and IgniteFuture.chain() semantics
>
>
> Key: IGNITE-4477
> URL: https://issues.apache.org/jira/browse/IGNITE-4477
> Project: Ignite
> Issue Type: Task
> Components: general
>Affects Versions: 1.8
>Reporter: Vladimir Ozerov
>Assignee: Dmitry Karachentsev
> Fix For: 2.0
>
>
> *Problem*
> We allow users to pass continuations to {{IgniteFuture}} which will be
> executed on future completion. This can be done through {{listen}} or
> {{chain}} methods.
> However, continuation semantics is broken intrinsically:
> 1) If future is already completed, user code executed in the same thread;
> 2) If future is not completed yet, it will be executed in completion thread.
> Neither of this options are valid because it easily leads to starvation. E.g.:
> {code}
> IgniteFuture fut = cache.getAsync(key2);
> fut.listen(fut0 -> {
> cache.put(key2, val2); // Possible deadlock, because invoked in sys pool;
> });
> {code}
> *Solution*
> 1) By default callbacks must be executed asynchronously in some common pool
> (public pool? new "callback pool"? FJP?)
> 2) It should be possible to specify where to execute a callback explicitly:
> {code}
> IgniteFuture.listen(IgniteClosure, ExecutorService);
> {code}
> 3) We may want to expose our public pool on API for convenience.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (IGNITE-4477) Fix IgniteFuture.listen() and IgniteFuture.chain() semantics
[
https://issues.apache.org/jira/browse/IGNITE-4477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15953095#comment-15953095
]
Dmitry Karachentsev edited comment on IGNITE-4477 at 4/3/17 7:48 AM:
-
Vladimir, please review the fix: [PR
1710|https://github.com/apache/ignite/pull/1710]
Instead of two async methods for listen and chain I've added one with nullable
Executor. I don't think we need to duplicate methods just without last argument.
Here is a link to upsource:
[IGNT-CR-151|http://reviews.ignite.apache.org/ignite/review/IGNT-CR-151]
was (Author: dkarachentsev):
Vladimir, please review the fix: [PR
1710|https://github.com/apache/ignite/pull/1710]
Instead of two async methods for listen and chain I've added one with nullable
Executor. I don't think we need to duplicate methods just without last argument.
> Fix IgniteFuture.listen() and IgniteFuture.chain() semantics
>
>
> Key: IGNITE-4477
> URL: https://issues.apache.org/jira/browse/IGNITE-4477
> Project: Ignite
> Issue Type: Task
> Components: general
>Affects Versions: 1.8
>Reporter: Vladimir Ozerov
>Assignee: Dmitry Karachentsev
> Fix For: 2.0
>
>
> *Problem*
> We allow users to pass continuations to {{IgniteFuture}} which will be
> executed on future completion. This can be done through {{listen}} or
> {{chain}} methods.
> However, continuation semantics is broken intrinsically:
> 1) If future is already completed, user code executed in the same thread;
> 2) If future is not completed yet, it will be executed in completion thread.
> Neither of this options are valid because it easily leads to starvation. E.g.:
> {code}
> IgniteFuture fut = cache.getAsync(key2);
> fut.listen(fut0 -> {
> cache.put(key2, val2); // Possible deadlock, because invoked in sys pool;
> });
> {code}
> *Solution*
> 1) By default callbacks must be executed asynchronously in some common pool
> (public pool? new "callback pool"? FJP?)
> 2) It should be possible to specify where to execute a callback explicitly:
> {code}
> IgniteFuture.listen(IgniteClosure, ExecutorService);
> {code}
> 3) We may want to expose our public pool on API for convenience.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
