Using RetryPolicy/Failsafe with LoadingCache using refreshAfterWrite

[MarkStewartYottaa]

Hello!
I'm hoping to get some expert advice on this topic.

I have a caching implementation that looks like this:

LoadingCache<LocalDate, Map<String,BigDecimal>> cache;
...
cache = Caffeine.newBuilder()
                .expireAfterAccess(1, TimeUnit.DAYS)
                .refreshAfterWrite(effectiveCacheEntryLifetimeMins, TimeUnit.MINUTES)
                .build(dateKey -> fetchAndDecodeCacheEntry(dateKey));

Is it possible/recommended to add a retry mechanism to this setup using the RetryPolicy and Failsafe?
The problem is that a failed fetchAndDecodeCacheEntry() call results in null being cached as the value for the given dateKey until effectiveCacheEntryLifetimeMins expires.

I'm trying to keep the code as simple as possible but I'm guessing it will get rather more complex in order to achieve these goals.

Appreciate any suggestions, thoughts, etc.

Cheers,
Mark

[ben-manes]

There is an example showing the two used together.

The cache does not support storing null values, as it mirrors ConcurrentHashMap and its computeIfAbsent behavior. The caching of a null value can be done using an Optional which is more explicit. If null then the next request will load anew.

Often retry policies have a backoff between attempts, which extends the lock hold times. For a synchronous cache you might want to retry outside of the cache if the locking becomes a problem, which will memoize but could allow multiple threads to interleave their their retries for the same entry. The async cache is friendlier by doing the work in a future, which failsafe nicely handles with its own async support.

[MarkStewartYottaa]

Wow, super fast response. Thanks, Ben.

I did see the example you reference. I guess I was wondering if there was a way of using the RetryPolicy with the LoadingCache with the behavior of the refreshAfterWrite (returning a possibly stale value to the caller immediately and getting a fresh value asynchronously.) I'm guessing there isn't.

As for the caching of null, it seemed like that was the behavior I was seeing. Glad that it isn't; I'll have to look again more closely...

[ben-manes]

Oh refreshAfterWrite does return the stale value to the caller immediately and asynchronously reload. You can override it specifically in the CacheLoader for asyncReload or reload if you want more control over the behavior. So for example you could only retry on the reload.

It sounds like maybe because null in computations means the entry is absent and should be removed, you are accidentally deleted the mapping during the reload? If so, you could instead return the old value (giving it another refresh period) or throw an exception (try on the next read). I think if you define the CacheLoader explicitly the lifecycle will make more sense as you debug.