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: ntikho...@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.
