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 <ntikho...@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 <voze...@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 < > ntikho...@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? > > > > > >
