RE: CacheEntryEventFilter with Replicated caches
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.
Re: CacheEntryEventFilter with Replicated caches
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.
RE: CacheEntryEventFilter with Replicated caches
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: dev@ignite.apache.org > > Andrey, > > Are you talking about a continuous query or a distributed event listener?
Re: CacheEntryEventFilter with Replicated caches
Andrey, Are you talking about a continuous query or a distributed event listener?
RE: CacheEntryEventFilter with Replicated caches
Dmitriy, The reason for my posting was exactly that: the filter is both deployed and invoked on all nodes where the REPLICATED cache is started. My point is that the filter should only be deployed and invoked on the node where its corresponding listener is, namely the local node (the node that registered the listener by calling IgniteCache.registerCacheEntryListener). Executing filter on remote nodes in case of a REPLICATED cache is a waste of resources that can and should be avoided. Thanks Andrey > From: dsetrak...@apache.org > Date: Wed, 9 Mar 2016 15:09:20 -0800 > Subject: 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 wrong). In that case, it will be impossible to > deploy it only on the node that registered it. > > D. > > On Wed, Mar 9, 2016 at 1:44 PM, Andrey Kornev <andrewkor...@hotmail.com> > wrote: > > > Hello, > > > > It's come to my attention, when registering the cache event listener, the > > filters get deployed on all the nodes of the cache, despite the fact that > > the cache is configured as REPLICATED. This seems redundant since it's > > sufficient to have the filter deployed only on the node that has the local > > cache listener (in other words, the same node that registers the listener). > > Since the filter may execute some non-trivial computationally intensive > > logic and it doesn't make sense to waste CPU on the nodes that are not > > going to call back the listener. Not deploying filters to remote nodes > > would also reduce the registration/unregistration overhead since only the > > local node needs to be involved. > > > > The only case that would require special attention would be the case when > > a listener is registered from a node which doesn't have the cache started. > > > > Please advise. > > Andrey > >
Re: CacheEntryEventFilter with Replicated caches
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, 2016 at 1:44 PM, Andrey Kornevwrote: > Hello, > > It's come to my attention, when registering the cache event listener, the > filters get deployed on all the nodes of the cache, despite the fact that > the cache is configured as REPLICATED. This seems redundant since it's > sufficient to have the filter deployed only on the node that has the local > cache listener (in other words, the same node that registers the listener). > Since the filter may execute some non-trivial computationally intensive > logic and it doesn't make sense to waste CPU on the nodes that are not > going to call back the listener. Not deploying filters to remote nodes > would also reduce the registration/unregistration overhead since only the > local node needs to be involved. > > The only case that would require special attention would be the case when > a listener is registered from a node which doesn't have the cache started. > > Please advise. > Andrey >