Thank you for your help! I "think" this is working.
*One thing I did notice in my test environment is that the events can be
raised in drastically different times? *
It is not a huge deal since getting the item (providing the near cache has
expired it) will trigger the expiration on Ignite which will in turn raise
the events but I was just curious why such the delay especially in a local
test environment...
What is really odd to me is that no matter what I do, what order I put items
in, what order the cache gets initially created, anything in "cache1" always
seems to raise the event in a timely manner and both caches have the exact
same configuration. My test case, which uses sleep() to simulate the
expiration, seems to show more consistent results with the events being
raised more timely.
*For example:*
1) Spin up a single Ignite node (embedded / server / partitioned /
EVT_CACHE_OBJECT_EXPIRED )
a) cache1 defined via configuration (eager TTL = true)
b) cache2 defined via configuration (eager TTL = true)
I assign a node attribute to each cache (cache = true) and then use a
predicate to filter only those specific nodes in the listener.
2) Using a dummy REST resource (in same instance) put entries into the
near-cache (caffeine) which writes through to the far-cache (ignite).
Caffeine expires in 30s / Ignite expires in 60s
On the first call to caffeine (which would be per Ignite node as well), if I
have not initialized the ignite side, attach the listener (so, this happens
just once on the node). Idea is to listen on any "expired" events and raise
the action to the local near-cache.
Then...
a) put k1/aaa into cache1
b) put k2/bbb into cache2
c) put k3/ccc into cache2
/Output looks something like (9:35):/
[DEBUG] CaffeineConfigurableCacheManager : Created cache cache1
[ WARN] CaffeineConfigurableCacheManager : Initialized....
[DEBUG] IgniteCacheBuilder : Writing aaa to cache1
[DEBUG] CaffeineConfigurableCacheManager : Created cache cache2
[DEBUG] IgniteCacheBuilder : Writing bbb to cache2
[DEBUG] IgniteCacheBuilder : Writing ccc to cache2
3) Sit and wait (just looking at the events only, not if I get the record
which forces the expiry on expired items)...
/Within the ~"60s" expiration policy on Ignite I see (9:36):/
[DEBUG] IgniteCacheBuilder : Received remote event cache1
CACHE_OBJECT_EXPIRED aaa
[DEBUG] IgniteCacheBuilder : Eviction callback cache1 CACHE_OBJECT_EXPIRED
aaa
/Much later I see (9:52):/
[DEBUG] IgniteCacheBuilder : Received remote event cache2
CACHE_OBJECT_EXPIRED bbb
[DEBUG] IgniteCacheBuilder : Eviction callback cache2 CACHE_OBJECT_EXPIRED
bbb
[DEBUG] IgniteCacheBuilder : Received remote event cache2
CACHE_OBJECT_EXPIRED ccc
[DEBUG] IgniteCacheBuilder : Eviction callback cache2 CACHE_OBJECT_EXPIRED
ccc
*My current code looks something like this:*
ignite.events(ignite.cluster().forPredicate(new
AttributeNodeFilter<>(CACHE_NODE_ATTRIBUTE_KEY, true)))
.remoteListen(
null,
new IgnitePredicate<CacheEvent>()
{
@IgniteInstanceResource
private transient Ignite ignite;
@SpringResource(resourceClass = CacheManager.class)
private transient CacheManager cacheManager;
@Override
public boolean apply(final CacheEvent event)
{
log.debug("Received remote event {} {} {} / {} {} ",
event.cacheName(),
event.name(),
event.key(),
event.node().id(),
event.eventNode().id());
//Broadcase the callback
ignite.compute().broadcastAsync((IgniteCallable)() -> {
try
{
log.debug("Eviction callback {} {} {} / {} {} ",
event.cacheName(),
event.name(),
event.key(),
event.node().id(),
event.eventNode().id());
//Evict item from cache
cacheManager
.getCache(event.cacheName())
.evict(event.key());
}
catch (Exception x)
{
log.error("Callback error: {}", x.getMessage(), x);
}
//Return the event
return true;
});
return true;
}
},
EVT_CACHE_ENTRY_EVICTED,
EVT_CACHE_OBJECT_EXPIRED);
-----
KJQ
--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/
