ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vladimir Ozerov <voze...@gridgain.com>
Subject Re: Make async API great again
Date Mon, 26 Dec 2016 10:33:28 GMT
Answered.

On Mon, Dec 26, 2016 at 12:51 PM, Yakov Zhdanov <yzhdanov@apache.org> wrote:

> Vladimir, I commented in https://issues.apache.org/jira/browse/IGNITE-4480
> and https://issues.apache.org/jira/browse/IGNITE-4479 and
> https://issues.apache.org/jira/browse/IGNITE-4476
>
> I agree that current approach for async API is not good at all and needs to
> be fixed.
>
> As far as callback semantics, it does not seem to be a solution since user
> may not pass executor parameter and will get the same starvation again. We
> just need to add proper documentation and maybe implement smarter
> starvation checker similar to one in striped pool.
>
>
>
> --Yakov
>
> 2016-12-22 14:09 GMT+03:00 Vladimir Ozerov <vozerov@gridgain.com>:
>
> > And several more improvements to future API:
> > 1) Remove startTime() and duration() methods:
> > https://issues.apache.org/jira/browse/IGNITE-4479
> > 2) Fix broken cancellation semantics:
> > https://issues.apache.org/jira/browse/IGNITE-4480
> >
> > On Thu, Dec 22, 2016 at 1:40 PM, Vladimir Ozerov <vozerov@gridgain.com>
> > wrote:
> >
> > > Gents,
> > >
> > > I created tickets for all proposed improvements:
> > > 1) Nice async API: https://issues.apache.org/jira/browse/IGNITE-4475
> > > 2) Do not process IO messages synchronously for local node:
> > > https://issues.apache.org/jira/browse/IGNITE-4476
> > > 3) Better IgniteFuture API and callback semantics: https://issues.
> > > apache.org/jira/browse/IGNITE-4477
> > >
> > > Please review it and let me know if you have any comments.
> > >
> > > Vladimir.
> > >
> > > On Wed, Dec 21, 2016 at 4:32 AM, Dmitriy Setrakyan <
> > dsetrakyan@apache.org>
> > > wrote:
> > >
> > >> Would be nice if someone would prototype a new cache API and post the
> > >> generated javadoc here. I think we all will benefit from reviewing it.
> > >>
> > >> On Tue, Dec 20, 2016 at 12:17 PM, Vladimir Ozerov <
> vozerov@gridgain.com
> > >
> > >> wrote:
> > >>
> > >> > Async API rework is mechanical addition of ~100 methods through
> > >> copy-paste.
> > >> > Should not take more than a day to implement and more than another
> day
> > >> to
> > >> > rework tests.
> > >> >
> > >> > On Tue, Dec 20, 2016 at 10:00 PM, Dmitriy Setrakyan <
> > >> dsetrakyan@apache.org
> > >> > >
> > >> > wrote:
> > >> >
> > >> > > How difficult is this change? Does not look like it can be done
> > >> > overnight.
> > >> > >
> > >> > > On Tue, Dec 20, 2016 at 10:46 AM, Vladimir Ozerov <
> > >> vozerov@gridgain.com>
> > >> > > wrote:
> > >> > >
> > >> > > > We already discussed this several months ago in other thread.
> > >> > > >
> > >> > > > "Async" methods is the most simple and straight API possible.
> .NET
> > >> > world
> > >> > > > goes this way all over their frameworks and nobody died.
> Hazelcast
> > >> also
> > >> > > > goes this way. Java goes this way (see CompletableFuture).
This
> is
> > >> > common
> > >> > > > and well-known practice. The most impacted part of our API
will
> be
> > >> > cache,
> > >> > > > +33 new methods. Though, I do not see how it can affect
learning
> > >> curve.
> > >> > > >
> > >> > > > Agree that we should deprecate AsyncSupport gradually and
remove
> > it
> > >> no
> > >> > > > earlier than in Apache Ignite 3.0.
> > >> > > >
> > >> > > > On Tue, Dec 20, 2016 at 9:31 PM, Dmitriy Setrakyan <
> > >> > > dsetrakyan@apache.org>
> > >> > > > wrote:
> > >> > > >
> > >> > > > > On Tue, Dec 20, 2016 at 10:28 AM, Sergi Vladykin <
> > >> > > > sergi.vladykin@gmail.com
> > >> > > > > >
> > >> > > > > wrote:
> > >> > > > >
> > >> > > > > > +1 For removing withAsync. It is a broken design.
> > >> > > > > >
> > >> > > > >
> > >> > > > > Sergi, do you also want to add all the async methods
to the
> main
> > >> API
> > >> > or
> > >> > > > do
> > >> > > > > you have some other design in mind?
> > >> > > > >
> > >> > > >
> > >> > >
> > >> >
> > >>
> > >
> > >
> >
>

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