You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@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)