The impact of this change seems quite significant. Also, some of the
issues, like starvation, will not be fixed with introduction of the new
API, as far as I can tell.
I would be against removing the current async support from the API in one
motion. I think we can deprecate it right now, in 2.0, and completely
remove it in 3.0.
As far as the new async API, I would propose something like
IgniteCacheAsync with all the async methods. Otherwise, we face serious
method proliferation on the existing API, essentially doubling it in size.
D.
On Tue, Dec 20, 2016 at 12: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.
>
