Huge +1 on this. Current API is very confusing.
On Tue, Dec 20, 2016 at 11:56 AM, Vladimir Ozerov <voze...@gridgain.com>
wrote:
> Igniters,
>
> We have complaints about design of our async API, and upcoming Ignite 2.0
> release is a good candidate to fix it.
>
> Problems:
>
> 1) API is verbose and error prone:
>
> Ignite asyncCache = cache.withAsync();
> asyncCache.get(key);
> 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.
>
> Thoughts?
>
> [1] http://doc.akka.io/docs/akka/current/scala/dispatchers.html
>
> Vladimir.
>
