RE: Event listeners on servers only
Thank you, both solutions verified! -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/
RE: Event listeners on servers only
The options I see
1. Register a local listener on each node; you can call localListen() from a
broadcast() job or when the node starts.
2. Deploy a cluster-singleton service that calls remoteListen() in its
initialize().
I guess the first one will perform better.
Stan
From: maros.urbanec
Sent: 26 марта 2019 г. 15:59
To: user@ignite.apache.org
Subject: Event listeners on servers only
Hi all,
we're faced with the following requirement - when a cache entry expires
and is about to get removed from the cache, listen to the event, alter an
attribute on the entry and write it to some other cache.
It can be implemented as a client-side event listener, but that ceases to
function as soon as the client leave the topology.
/UUID listenerId = ignite.events().remoteListen(
(e, uuid) -> {
System.out.println("Expired event - executed on the
client");
return true;
},
e -> {
System.out.println("Expired event - executed on one of the
servers");
return true;
},
EventType.EVT_CACHE_OBJECT_EXPIRED
);/
Calling /ignite.events(ignite.cluster().forServers()).remoteListen / instead
makes no difference as long as I can tell.
Is there any way to run an event listener on the server without a
corresponding client? Is there any way for the listener to outlive its
client?
--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/
Event listeners on servers only
Hi all,
we're faced with the following requirement - when a cache entry expires
and is about to get removed from the cache, listen to the event, alter an
attribute on the entry and write it to some other cache.
It can be implemented as a client-side event listener, but that ceases to
function as soon as the client leave the topology.
/UUID listenerId = ignite.events().remoteListen(
(e, uuid) -> {
System.out.println("Expired event - executed on the
client");
return true;
},
e -> {
System.out.println("Expired event - executed on one of the
servers");
return true;
},
EventType.EVT_CACHE_OBJECT_EXPIRED
);/
Calling /ignite.events(ignite.cluster().forServers()).remoteListen / instead
makes no difference as long as I can tell.
Is there any way to run an event listener on the server without a
corresponding client? Is there any way for the listener to outlive its
client?
--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/
Re: Event Listeners
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
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
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
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
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
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
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
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
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
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
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.
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.
