ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrey Kornev <andrewkor...@hotmail.com>
Subject RE: API for asynchronous execution.
Date Sun, 05 Jun 2016 21:06:52 GMT
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.
 		 	   		  
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message