Alexey,
Thank you for the explanation!
But why any of that matters in this case? I'm talking about the REPLICATED
cache -- all data changes get applied to all nodes in the same order on all
nodes. And I'm talking about a cache event listener that is instantiated on one
of thise nodes. It can be a primary or back up node, why does it matter? If the
node is gone, that the listener is gone. Nobody's listening anymore. Time to
forget the listener, clean up and move on. There is no way on a different node
to pick from where the crushed node has left off (at least not thru JCache
API). And it's doubtful one would want to do that even if it was possible.
In the use case I'm describing, the whole filtering/listening thing could be
entirely local making things a lot more efficient. I don't care about
exactly-once delivery semantics that Ignite seems to be trying to guarantee,
and I really hate to pay for things I don't need (the overhead of deploying
filters to remote nodes, gratuitous evaluation of remote filters, the internal
data structures and logic employed by Ignite to maintain the backup queues,
etc, etc). I just want a lightweight all-local cache event listener.
How can I do it? Please advise.
Thanks
Andrey
> Date: Wed, 9 Mar 2016 16:21:19 -0800
> Subject: Re: CacheEntryEventFilter with Replicated caches
> From: alexey.goncha...@gmail.com
> To: dev@ignite.apache.org
>
> Dmitriy is right, currently REPLICATED cache works the same way as
> PARTITIONED does, and in PARTITIONED cache filters should be evaluated on
> backups in order to maintain a backup queue in case a primary node fails.
>
> For the case when query is executed on an affinity node of a REPLICATED
> cache _and_ auto-unsubscribe is true, I believe we can change the behavior,
> however it will be inconsistent with all other modes.
>
> It can be easily overridden in Ignite API by setting local flag on a
> continuous query. I think we can provide a way to set the local flag for a
> JCache event listener, but I am not sure how it will look API-wise.
