+1 For removing withAsync. It is a broken design.
Sergi
2016-12-20 20:38 GMT+03:00 Dmitriy Setrakyan <dsetrak...@apache.org>:
> On Tue, Dec 20, 2016 at 9:13 AM, Pavel Tupitsyn <ptupit...@apache.org>
> wrote:
>
> > 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.
> >
>
> It is not an issue of IDE support. It is an issue of API complexity and
> learning curve for new users.
>
> By the way, do we have many examples of users complaining about the current
> async approach in Ignite? I personally do not see any harm of leaving the
> async API unchanged.
>
>
>
> >
> > 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.
> > > >
> > >
> >
>
