ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrey Kornev <andrewkor...@hotmail.com>
Subject RE: CacheEntryEventFilter with Replicated caches
Date Wed, 09 Mar 2016 23:49:58 GMT
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: dsetrakyan@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 <andrewkornev@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
> >
 		 	   		  
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message