You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ignite.apache.org by "javastuff.sam@gmail.com" <ja...@gmail.com> on 2016/10/14 22:04:02 UTC

Event Listeners

Hi,

1. Is there a way to create cache event listener only for a particular
cache, so that other cache don't generate events and its overhead?
Currently, able to work with listener handler filtering based on CacheName,
however events are generated for all cache.

public boolean apply(CacheEvent evt) {
if(evt.cacheName().equals("SAMPLE")) {
//do something.
} else {
// ignore
}
return true;
}  

2. Is there a way to ensure that event listener is already created? In other
words how to ensure that we are creating only one listener per node for
event and topic. Currently, able to work with localListener, however
specific case or topology remoteListener needed.

Thanks,
-Sam



--
View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Event-Listeners-tp8306.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Event Listeners

Posted by vkulichenko <va...@gmail.com>.
Sam,

To avoid deserialization you can set CacheConfiguration#copyOnRead to false.

As for clear(), there is no notification for it. Who triggers it? Can the
client that calls clear(), then execute whatever needs to be executed as a
post-action? You can use compute APIs for this, for example.

-Val



--
View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Event-Listeners-tp8306p14511.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Event Listeners

Posted by "javastuff.sam@gmail.com" <ja...@gmail.com>.
No. Near cache is one of the usecase, because of serializing/deserialize can
not use Ignite Near cache, it's a big overhead and negating benefits of near
cache altogether. 

In other usecases we need to notify all changes to cached data. In a
specific scenario, we have to remove all entries and same need to be
notified to all nodes.

Thansk,
-Sam





--
View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Event-Listeners-tp8306p14508.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Event Listeners

Posted by vkulichenko <va...@gmail.com>.
Sam,

It sounds like you can set CacheConfiguration#invalidate property to true.
This will force Ignite to invalidate near cache entry on update rather that
syncing it with a new value. Is this what you're looking for?

-Val



--
View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Event-Listeners-tp8306p14503.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Event Listeners

Posted by "javastuff.sam@gmail.com" <ja...@gmail.com>.
Cached data change notifications are used in multiple use-cases. Here is one
-

We have OFFHEAP distributed Ignite cache fronted by JVM level local copy. It
is similar to what Near cache would work. However, Ignite Near cache (JVM
level local copy) also get serialized/de-serialized. which results in
latency compared to direct object access. So we are not using Ignite Near
cache but simulating same. To invalidate cache we rely on event
notifications. In some case, we need to clear all cached entries and that is
where we use cache.clear().

There are other scenarios where change event notifications are the
preliminary indication of data change, which needs to be notified to all
nodes to keep data and process consistency.  Message passing can be another
approach but it won't be completely consistent and tightly bound to data
change. 

Can I assume cache.clear() does not generate any event notification and need
to move away from it? Can you please help optimizing clear vs remove?

Thanks,
-Sam 

   



--
View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Event-Listeners-tp8306p14437.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Event Listeners

Posted by vkulichenko <va...@gmail.com>.
Sam,

What is the business use case behind this?

-Val



--
View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Event-Listeners-tp8306p14431.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Event Listeners

Posted by "javastuff.sam@gmail.com" <ja...@gmail.com>.
In general what event to look for cache.clear()? I tried remoteListener for
EVT_CACHE_OBJECT_PUT/READ/REMOVED and unable to capture clear() activity.

To use remove() instead of clear() as a workaround, need to do a scan query
and then remove/removeAll. Sounds expensive. I am looking at PARTITIONED
OFF-HEAP cache with 1K to 40K entries with 1-4 nodes in the topology. How
can I optimize this workaround? Will Entryprocessor help? 

Appreciate your help and ideas.

Thanks,
-Sam   



--
View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Event-Listeners-tp8306p14364.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Event Listeners

Posted by vkulichenko <va...@gmail.com>.
Hi Sam,

Continuous queries only work with data update operations like put, remove,
etc. So to get notification you should use remove() method instead of
clear(). If you have a persistence store and you don't want to remove from
there, you can do this as a workaround:

cache.withSkipStore().remove(..);

-Val



--
View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Event-Listeners-tp8306p14362.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Event Listeners

Posted by "javastuff.sam@gmail.com" <ja...@gmail.com>.
onRemoved listener is not called when cache.clear() is used. Can you please
let me know what event I need to listen for clear()?

Thanks,
-Sam



--
View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Event-Listeners-tp8306p14361.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Event Listeners

Posted by vkulichenko <va...@gmail.com>.
Hi,

Cache entry listeners are coming from JCache, while ContinuousQuery is a
part of native Ignite API. Under the hood they basically use the same
implementation.

-Val



--
View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Event-Listeners-tp8306p8332.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Event Listeners

Posted by "javastuff.sam@gmail.com" <ja...@gmail.com>.
I will try out continuous query. In mean time I tried other approach, each
node in cluster registers cache entry listener -

IgniteCache cache = ignite.getOrCreateCache(CACHE_NAME);
cache.registerCacheEntryListener(......);

With this, listeners are being called on each registered node and I am able
to define specific cache and specific kind of events to listen. 
This works without configuring events in configuration (includeEventTypes).

Since event listeners on each node is called this seems simpler to work with
and probably less expensive because of specific cache used for listeners.  

Referring from -
org.apache.ignite.internal.processors.cache.query.continuous.GridCacheContinuousQueryMultiNodesFilteringTest

Could you please comment on this approach? 



--
View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Event-Listeners-tp8306p8331.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Event Listeners

Posted by vkulichenko <va...@gmail.com>.
Hi Sam,

I recommend to take a look at continuous queries [1], it sounds like they
will better fit your use case. This feature is designed to listen for data
updates, provides much better guarantees and also allows to listen only to
specific caches.

[1] https://apacheignite.readme.io/docs/continuous-queries

-Val



--
View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Event-Listeners-tp8306p8311.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.