Expiration Listener not triggering if there are no get requests for the expired keys

[Serban Balamaci]

1. What version of Ehcache you are currently using.
   3.1.2 
2. Paste the configuration for the Cache/CacheManager you have an issue with;
   Bellow
   
   
3. Add any name and version of other library or framework you use Ehcache with (e.g. Hibernate);
   none
4. Providing JDK and OS versions maybe useful as well.
   Java8

Hi,

I have the following cache configuration. 

CacheEventListenerConfigurationBuilder cacheEventListenerConfiguration = CacheEventListenerConfigurationBuilder

                .newEventListenerConfiguration(new MyListener(), EventType.EXPIRED)

                .unordered().asynchronous();

CacheManagerBuilder.newCacheManagerBuilder()

                .with(CacheManagerBuilder.

                        persistence(System.getProperty("java.io.tmpdir") + File.separator + "myCache"))

                .withCache("myCache", CacheConfigurationBuilder

                                            .newCacheConfigurationBuilder(Tuple3.class, Integer.class,

                                                                            ResourcePoolsBuilder.heap(500)

                                                                                        .disk(200, MemoryUnit.MB)

                                            )

                                            .add(cacheEventListenerConfiguration)

                                            .withExpiry(Expirations.timeToIdleExpiration(Duration.of(30, TimeUnit.SECONDS)))

                                            .build()

                )

    private class MyListener implements CacheEventListener<Tuple3<String, String, String>, Integer> {

       

        @Override

        public void onEvent(CacheEvent<Tuple3<String, String, String>, Integer> event) {

            log.info("Expired {}", event.getKey());

        }

    }

I imagined there is a background thread that is notifying for expired items in the cache. However the listener seems to trigger only in case I issue a get for the expired element. 

Is there a way to make the notification trigger even without getting the element?

[Alex Snaps]

Serban,

Y, there is no background thread proactively expiring entries in the cache. That does indeed mean an expired entry has to either be accessed for it to be removed or, if the cache is at its max capacity, it will eventually be evicted. 

I'd twist the question around though, why are you interested in being notified when an entry expires (and I mean _when_ i.e. as it expires)? What is your listener's doing when that happens?

Alex

--
You received this message because you are subscribed to the Google Groups "ehcache-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ehcache-user...@googlegroups.com.
To post to this group, send email to ehcach...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ehcache-users/0699174f-0599-4ce7-a0be-ae21ae336102%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Alex Snaps

Twitter: @alexsnaps

[Serban Balamaci]

Hi Alex,

It's a basic QoS rate implementation. I'm sending SMSes and there is a possibility to receive a callback from the SMS provider when the provider knows the user received the SMS. However the callback might even come delayed by a few hours or not at all and I'd like to consider not received callbacks in X minutes as failed delivery. 

My implementation was that I add all the send sms-es ids to the cache and when the callback comes and the element is still in the cache +1 success submission counter. I wanted the expired elements(which would mean a failed delivery) that I +1 the failure counter. I went to ehcache as the simple spool to disk would also save me from a potential huge map in memory.

[Alex Snaps]

So you're sizing your cache to _never_ evict? Plus the expiry value is the actual threshold for a message to be considered failure, y? So, I guess on callback invocation you do `.get(K) != null` (or .remove(K, V): bool) => success, otherwise failure.

i.e. if you get the callback invoked some 2 days after sending the message, but the expiry is say 1 day, it's considered failure, is that right? Want to make sure I understand this right.

In any case, this doesn't look like a caching use case to be honest. If I get you right you are relying on exact expiry (and callback, which you already miss here), which Ehcache will not guarantee. It could well be the entry gets removed from the cache based on other reasons (e.g. deployment topologies, contention, ...).

That being said, you could have a background thread iterate over the cache's content (at some rate) to get what you want, that wouldn't be optimized in any way, but would work. Again, all very dependent on your expected expiry behaviors... Feels like you want unbounded storage, with highly optimized expiry (in order to still minimize storage usage). The fact that you want unbounded storage is what makes me believe this isn't caching... If you can put a size limit on your storage, then you could listen for eviction of (expired) entries...

To view this discussion on the web visit https://groups.google.com/d/msgid/ehcache-users/5773e5cd-088c-4a43-9cce-3749a2c9048e%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Serban Balamaci]

Hi Alex,

Yeap, the sizing of the cache would I think make it very unlikely that the eviction happens because of limited storage but because the expiration timeout. You understood the problem.

I'd not worried about the eviction reasons others than time expiration. It's just a local cache(the QoS is done from the log streaming which only one process is processing) so no topology impact I guess. I wanted to stay away from the background thread because of what you said and also that I sort of need idleTime expiration which would be refresh items it each time it checked.

Anyway I'll think of something else, I just though I'm missing some config param and I could not find the documentation for it. On the 2.x version I found someone on StackOverflow mentioning a change in the eviction thread run period so I though I'm missing the config for it.
Thank you for the clarification.

[Alex Snaps]

Not sure what that SO post was about, but I don't know of any background thread doing expiry in any version of Ehcache. 

(Maybe someone was talking about some very specific topology, like clustered with Terracotta, where certain things do happen in the background on both client & server)

To view this discussion on the web visit https://groups.google.com/d/msgid/ehcache-users/219bfb9a-202c-4be9-a0c0-623002cfb4bb%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.