I don't think that increased method number in the API is an issue.
Modern IDEs have sophisticated auto-complete features that make it easy to
find the right one.
As an API user, I would prefer sync and async methods side by side in the
same interface:
Use types 'cache.get(' and the IDE would show both sync and sync methods.
* Easy to discover async APIs even if you are not aware of them yet
* Easy to tell which methods have async counterparts
With a separate interface this is more verbose and complicated from the
user POV.
PS Link to prior discussion for Ignite.NET:
http://apache-ignite-developers.2346864.n4.nabble.com/Net-separate-methods-for-async-operations-td3901.html
Pavel
On Tue, Dec 20, 2016 at 7:57 PM, Dmitriy Setrakyan <dsetrak...@apache.org>
wrote:
> 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.
> >
>
