RE: API for asynchronous execution.

[Andrey Kornev <an...@hotmail.com>]

Hello,

I'd like to suggest making the point about the callback execution ordering more prominent in the Ignite documentation and/or the javadocs of @IgniteAsyncCallback. I think the documentation should emphasize the fact  that the events for the same keys are guaranteed to be delivered in-order, despite the asynchronous execution of the callback. Without such guarantee, the applicability of the async callback feature would be very limited.

Thanks
Andrey 

> Date: Tue, 29 Mar 2016 19:22:50 +0300
> Subject: Re: API for asynchronous execution.
> From: ntikhonov@gridgain.com
> To: dev@ignite.apache.org
> 
> Vova,
> 
> 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.
> >
> 
> Invocation of filter will be implemented in thread-partition style for
> supporting ordering of 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.
> >
> 
> Main reason async execution to allow users use cache operations in remote
> filter.