I'm ok with any of these ways. Probably having methods with "Async" suffix
is simpler, having a separate interface for all the async methods is a bit
cleaner. Current IgniteAsyncSupport definitely was a big mistake.
Sergi
On Thu, Jul 21, 2016 at 12:41 PM, Vladimir Ozerov <voze...@gridgain.com>
wrote:
> Moreover, have a look at *CompletableFuture *interface:
>
> handle
> handle*Async*
>
> thenApply
> thenApply*Async*
>
> And so on. One more argument to return methods with "Async" suffix from
> good old GridGain days.
>
> On Thu, Jul 21, 2016 at 12:38 PM, Vladimir Ozerov <voze...@gridgain.com>
> wrote:
>
> > It is a matter of taste. In .NET we have "Async" methods near synchronous
> > methods because it is common practice in .NET world:
> > V Get(K key);
> > Task<V> GetAsync(K key);
> >
> > For Java we can go the same way, or introduce separate interface. It will
> > not be identical to synchronous, because it will have different return
> > types and probably will contain only those methods which support async
> > execution.
> >
> > Personally I like .NET approach. It is simple and straightforward. User
> do
> > not have to bother about whether current instance is sync or async (like
> > now), and will not have to perform additional steps like
> > *IgniteCache.withAsync().get()*. Do you want to call GET asynchronously?
> > No problem, *IgniteCache.getAsync()*. Simple, expressive,
> straightforward.
> >
> > The drawback is that our interfaces will become "heavier". But it is 2016
> > year, we all have IDEs. I do not see any problems if we will have 62 +
> 36 =
> > 98 methods instead of current 62 on cache API.
> >
> > Vladimir.
> >
> >
> > On Thu, Jul 21, 2016 at 12:21 PM, Dmitriy Setrakyan <
> dsetrak...@apache.org
> > > wrote:
> >
> >> 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.
> >> > > > > >
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
> >
> >
>
