https://issues.apache.org/jira/browse/IGNITE-2784
I agree that the case with JCache entry listener in REPLICATED can be
narrowed to a local-only listener. It should be a very simple change in the
code, I will create a ticket for this.
For now you can use Ignite continuous query instead of JCache event
listener and set it's 'local' flag to true.
ight 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 REPL
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_
Alexey,
I'm talking about JCache's CacheEntry listener (which I think is implemented on
top of the continuous query feature).
Andrey
> Date: Wed, 9 Mar 2016 15:52:48 -0800
> Subject: Re: CacheEntryEventFilter with Replicated caches
> From: alexey.goncha...@gmail.com
> To:
Andrey,
Are you talking about a continuous query or a distributed event listener?
bject: Re: CacheEntryEventFilter with Replicated caches
> To: dev@ignite.apache.org
>
> Hi Andrey.
>
> The replicated cache is just a partitioned cache with more backups. I think
> the filter is deployed on all nodes, but is only invoked on the primary
> node (correct me if I am
Hi Andrey.
The replicated cache is just a partitioned cache with more backups. I think
the filter is deployed on all nodes, but is only invoked on the primary
node (correct me if I am wrong). In that case, it will be impossible to
deploy it only on the node that registered it.
D.
On Wed, Mar 9,
