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.
