ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vladimir Ozerov <voze...@gridgain.com>
Subject Make async API great again
Date Tue, 20 Dec 2016 08:56:08 GMT

We have complaints about design of our async API, and upcoming Ignite 2.0
release is a good candidate to fix it.


1) API is verbose and error prone:

Ignite asyncCache = cache.withAsync();
IgniteFuture<V> fut = asyncCache.future();

2) Hard to reason which methods support async execution and which are not.
@IgniteAsyncSupported is not user friendly because it forces users to read
JavaDocs thoroughly.

3) No control on where IgniteFuture.listen() and IgniteFuture.chain()
methods are executed. User can easily inadvertently add some code which
will lead to starvation. E.g.:

IgniteFuture<V> fut = asyncCache.future();
fut.listen((fut) -> { cache.put(...); }); // Starvation because callback
might be executed in sys pool.

4) We have incorrect IO optimization: if message is to be send to local
node, it will be executed synchronously. See GridIoManager.send() method.
This is wrong, because it breaks pool semantics. E.g. cache operations must
be executed in sys pool, but can be executed in public pool.

I propose to fix all that problems in Apache Ignite 2.0:

1) Let's have simple and straightforward API:
IgniteFuture<V> fut = cache.getAsync(key);

2) Fix local node "optimization" in GridIoManager - messages should not be
processed synchronously.

3) User continuations must never be executed synchronously, always delegate
them to public pool by default (or may be to Java FJP?).

4) Allow users to specify thread pool for their continuations:
IgniteFuture.listen(Closure, ExecutorService);
IgniteFufure.chain(Closure, ExecutorService);

See Akka "Dispatcher" [1] as example of similar concept.


[1] http://doc.akka.io/docs/akka/current/scala/dispatchers.html


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message