ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nikolay Tikhonov <ntikho...@gridgain.com>
Subject Re: API for asynchronous execution.
Date Tue, 29 Mar 2016 16:22:50 GMT

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

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