ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dmitriy Setrakyan <dsetrak...@apache.org>
Subject Re: Make async API great again
Date Tue, 20 Dec 2016 17:38:44 GMT
On Tue, Dec 20, 2016 at 9:13 AM, Pavel Tupitsyn <ptupitsyn@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 <dsetrakyan@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 <vozerov@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.
> > >
> >
>

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