ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vladimir Ozerov <voze...@gridgain.com>
Subject Re: API for asynchronous execution.
Date Tue, 29 Mar 2016 14:16:55 GMT
Nick,

I hardly can image why user would like to have async entry processor
provided that we already have IgniteCache.withAsync(). Moreover, usually
this method is invoked while holding lock on entry, so it doesn't seem to
be a valid use case (plus remember about unwrap() method). Though, may be I
do not see other sensible use cases.

As per remote filter, things also not very good:
1) As far as I remember, we enforce ordering of updates for the same key,
right? If yes, then stalled filter invoke for update #1 will stall all
further updates.
2) Listener notification is final stage of update. To the contrast remote
filter is intermediate stage. It means that you will have to maintain some
kind of beckpressure control for it's async invocations. If there are too
much concurrent invokes, you will eventually block system pool waiting for
some invokes to finish. Ultimately it means that user cannot execute any
other cache operations inside the filter irrespecitve of whether it is
synchronous or async.
Having these limitations in place - what is the reason to have async remote
filter?

>From my point of view, neither remote filter, nor invoke are valid use
cases for async execution.

Thoughts?

Vladimir.

On Tue, Mar 29, 2016 at 4:40 PM, Nikolay Tikhonov <ntikhonov@gridgain.com>
wrote:

> This approach works for cases when callback will be invoked on local node
> (cache future, local listener and etc), but how user set a thread pool when
> callback executed on remote nodes (remote filter, entry processor and etc)?
>
> On Tue, Mar 29, 2016 at 2:57 PM, Vladimir Ozerov <vozerov@gridgain.com>
> wrote:
>
> > We already had discussion about it several months ago. Normal practice is
> > to allow user specify thread pool where he would like to execute the
> > callback. This is how things work in JDK CompletableFutures and Hazelcast
> > futures, and this is the most flexible approach.
> >
> > On Tue, Mar 29, 2016 at 2:23 PM, Nikolay Tikhonov <
> ntikhonov@gridgain.com>
> > wrote:
> >
> > > Hello Igniters,
> > >
> > > Lately I'm working on a ticket
> > > https://issues.apache.org/jira/browse/IGNITE-2004. As part of the
> ticket
> > > need to add API which will provide an ability to execute operation
> > > asynchronously. The ability might be useful not only for continuous
> query
> > > filter but also for cache and discovery events, cache futures (listen
> and
> > > chain), messages and etc. I see the following options :
> > > * Marker interface: IgniteAsyncCallback
> > > * Annotation: @IgniteAsyncCallback
> > >
> > > I prefer the latest approach. Any thoughts on this?
> > >
> >
>

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