Do I understand correctly that the community is proposing to have 2
identical interfaces, one for sync operations and another for async
operations?
On Thu, Jul 21, 2016 at 12:15 PM, Sergi Vladykin <sergi.vlady...@gmail.com>
wrote:
> +1
>
> Finally it is time to drop this "cool feature" from Ignite!
>
> Sergi
>
> On Thu, Jul 21, 2016 at 11:13 AM, Vladimir Ozerov <voze...@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 <sboi...@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 <yzhda...@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.goncha...@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.
> > > > >
> > > >
> > >
> >
>
