You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@ignite.apache.org by "Vladimir Ozerov (JIRA)" <ji...@apache.org> on 2016/12/22 10:37:58 UTC
[jira] [Created] (IGNITE-4477) Fix IgniteFuture.listen() and
IgniteFuture.chain() semantics
Vladimir Ozerov created IGNITE-4477:
---------------------------------------
Summary: 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
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.4#6332)