ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergi Vladykin <sergi.vlady...@gmail.com>
Subject Re: Rework "withAsync" in Apache 2.0
Date Thu, 21 Jul 2016 09:15:52 GMT
+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.
> > > >
> > >
> >
>

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