My opinion is that if we do away with current “withAsync()” paradigm, then
we should simply add the *async* methods directly to the original
interface. At least this way it will be easier to tell which methods
support async execution, and which don’t.
I don’t think it makes sense to have 2 separate interfaces, one for sync
and another for async.
D.
On Thu, Jul 21, 2016 at 1:01 PM, Sergi Vladykin <sergi.vlady...@gmail.com>
wrote:
> 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.
> > >> > > > > >
> > >> > > > >
> > >> > > >
> > >> > >
> > >> >
> > >>
> > >
> > >
> >
>
