Mailing-List: contact dev-help@ignite.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@ignite.apache.org
MIME-Version: 1.0
In-Reply-To: <CAGt6o8=CWr8GsVaAcwYRfx0HeAJBH8fftdEEKf8PGtBYUFJDjw@mail.gmail.com>
References: <CAGt6o8k7kMZXCpvNw0u5NokyrayLJMaL1XjT7R4NqbDAzYGCsA@mail.gmail.com>
 <CABDss3hEzfV1LJhuvtC=1c4tF-VBRiTvQ=fXmw106ERjLjrwxw@mail.gmail.com>
 <CAGcMBHg5bA=W82FHTifjgdqt6XMC6ROqeiXiMsUfSiAbyYhMTQ@mail.gmail.com>
 <CAFx+i-aqc5cosxOY5h73CrWgcr9HRPVgx5NRkZOvjHO1Cig4hA@mail.gmail.com> <CAGt6o8=CWr8GsVaAcwYRfx0HeAJBH8fftdEEKf8PGtBYUFJDjw@mail.gmail.com>
From: Sergi Vladykin <sergi.vladykin@gmail.com>
Date: Thu, 21 Jul 2016 12:15:52 +0300
Message-ID: <CA+eZwrGeOR+v__HCZ2gXSge3+=mXt=4t80bfaM3a=OrHOFp-sQ@mail.gmail.com>
Subject: Re: Rework "withAsync" in Apache 2.0
To: dev@ignite.apache.org
Content-Type: multipart/alternative; boundary=94eb2c07be80192e85053821c6e3
archived-at: Thu, 21 Jul 2016 09:16:38 -0000

--94eb2c07be80192e85053821c6e3
Content-Type: text/plain; charset=UTF-8

+1

Finally it is time to drop this "cool feature" from Ignite!

Sergi

On Thu, Jul 21, 2016 at 11:13 AM, Vladimir Ozerov <vozerov@gridgain.com>
wrote:

> Alex.
>
> Of course, some distributed operations will involve some kind of asynchrony
> even in synchronous mode. My point is that we should not blindly do things
> like that:
>
> V get(K key) {
>     return getAsync(key),get();
> }
>
> Instead, get() has it's own path, getAsync() another path. But of course
> they could share some common places. E.g. I remember we already fixed some
> cache operations in this regard when users hit async semaphore limit when
> calling synchronous gets.
>
> Another point is that async instances may possibly accept user-provided
> Executor.
>
> Vladimir,
>
> On Thu, Jul 21, 2016 at 11:04 AM, Semyon Boikov <sboikov@gridgain.com>
> wrote:
>
> > Another issue which usually confuses users is Ignite 'implementation
> > details' of asynchronous execution: it operation is local it can be
> > executed from calling thread (for example, if 'async put' is executed in
> > atomic cache from primary node then cache store will be updated from
> > calling thread). Does it make sense to fix this as well?
> >
> >
> > On Thu, Jul 21, 2016 at 10:55 AM, Yakov Zhdanov <yzhdanov@apache.org>
> > wrote:
> >
> > > Agree with Alex. Vova, please go on with issues taking Alex's comments
> > into
> > > consideration.
> > >
> > > Thanks!
> > >
> > > --Yakov
> > >
> > > 2016-07-21 10:43 GMT+03:00 Alexey Goncharuk <
> alexey.goncharuk@gmail.com
> > >:
> > >
> > > > Big +1 on this in general.
> > > >
> > > > I would also relax our guarantees on operations submitted from the
> same
> > > > thread. Currently we guarantee that sequential invocations of async
> > > > operations happen in the same order. I think that if a user wants
> such
> > > > guarantees, he must define these dependencies explicitly by calling
> > > chain()
> > > > on returning futures.
> > > >
> > > > This change will significantly improve cache operations performance
> in
> > > > async mode.
> > > >
> > > > 3) Sync operations normally* should not* be implemented through
> async.
> > > This
> > > > > is a long story - if we delegate to async, then we have to bother
> > with
> > > > > additional threads, associated back-pressure control and all that
> > crap.
> > > > > Sync call must be sync unless there is a very strong reason to go
> > > through
> > > > > async path.
> > > > >
> > > > Not sure about this, though. In most cases a cache operation implies
> > > > request/response over the network, so I think we should have explicit
> > > > synchronous counterparts only for methods that are guaranteed to be
> > > local.
> > > >
> > >
> >
>

--94eb2c07be80192e85053821c6e3--