RE: CacheEntryEventFilter with Replicated caches

2016-03-09 Thread Andrey Kornev
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

2016-03-09 Thread Alexey Goncharuk
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

2016-03-09 Thread Andrey Kornev
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

2016-03-09 Thread Alexey Goncharuk
Andrey,

Are you talking about a continuous query or a distributed event listener?


RE: CacheEntryEventFilter with Replicated caches

2016-03-09 Thread Andrey Kornev
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

2016-03-09 Thread Dmitriy Setrakyan
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 
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
>