Can onRemoval() happen after the cache is GC eligible?

[chriskessel]

I have no idea if this could happen, so mostly I'm curious how this works.

1. I create a Cache with a timeout and a removal listener
2. I want to change the timeout (e.g. feature flag changes expiration from 5 minutes to 10 minutes)
3. I replace the old cache with a new cache

What happens with the old cache and expiring entries in it now that it's no longer referenced? It's GC eligible, but that might not happen immediately. Could entries in this GC eligible cache age out and cause the onRemoval() event to fire?

[ben-manes]

It should not, but I could imagine some races that could allow a surprise.

The cache does not create any threads itself and by default will only expire entries as a side effect of other read/write operations. If you have a scheduler set, then that thread will use the next expiration time to trigger a maintenance cycle. That scheduled task weakly holds the cache and will no-op if absent. If the reference was not collected then it might allow for a new strong reference and resurrect it (that is a GC implementation detail). In this case if the gc did not collect and the reference was not cleared, then maybe it could happen.

[ben-manes]

I want to change the timeout (e.g. feature flag changes expiration from 5 minutes to 10 minutes)

By the way, you could reconfigure the cache using Cache.policy() to adjust the expiration time.

[chriskessel]

Oh, well that's awesome! So, just to make sure, I'd use cache.policy().expiresAfterWrite().get().setExpiresAfter(newDuration)?

[ben-manes]

yep! Hopefully that side steps your problem entirely 🙂

[chriskessel]

100%, you rock! The best problem is one that is made completely irrelevant :)