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.
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.
I recommend to take a look at continuous queries , 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.
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 -
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:
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?
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?
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?
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.