[FIXED] Scheduled in-memory cache invalidation based on predicate

Issue

I have List<CompletableFuture> stored in Map

 private final Map<UUID, List<CompletableFuture>> hydrationProcesses = new ConcurrentHashMap<>();

Currently there is a daemon thread which runs every 30 sec and removes all Futures that have alredy been completed.

There are lots of TTL invalidation implementations, I am looking for invalidation based on some predicate. I want to get rid of this daemon thread.

Is there any out of a box solution for scheduled cache invalidation based on some custom logic. Maybe something in Spring/Guava that I missed?

Maybe something similar to Guava's

CacheBuilder.newBuilder()
  .expireAfterAccess(2,TimeUnit.MILLISECONDS)
  .build(loader);

But rather then mark everything as expired after access I need to check if this Future has already been completed and then remove it from cache.

Solution

I doubt there is a solution based on Guava. Since you don't specifically ask for a "Guava-only" solution, I'd like to give an idea how to solve the problem with cache2k.

Here is how the setup could look like:

final long RECHECK_INTERVAL_MILLIS = 30000;
Cache<UUID, CompletableFuture<Void>> cache =
  new Cache2kBuilder<UUID, CompletableFuture<Void>>(){}
    .loader(new AdvancedCacheLoader<UUID, CompletableFuture<Void>>() {
      @Override
      public CompletableFuture<Void> load(UUID key,
                                          long currentTime,
                                          CacheEntry<UUID, CompletableFuture<Void>> currentEntry) {
        return currentEntry != null ? currentEntry.getValue() : null;
      }
    })
    .expiryPolicy(new ExpiryPolicy<UUID, CompletableFuture<Void>>() {
      @Override
      public long calculateExpiryTime(UUID key,
                                      CompletableFuture<Void> value,
                                      long loadTime,
                                      CacheEntry<UUID, CompletableFuture<Void>> oldEntry) {
        return value.isDone() ? NOW : loadTime + RECHECK_INTERVAL_MILLIS;
      }
    })
    .refreshAhead(true)
    .build();

Actually cache2k has similar capabilities then Guava or other caches. However there are tiny extensions that allow more sophisticated setups.

The trick used here, is to configure the cache in read through operation, but make the loader return the current cache value. When an entry expires, the loader is called, because of refreshAhead(true), but the current value is preserved and the expiry policy is evaluated again. The predicate that you like to be checked goes into the expiry policy.

Other caches have read through and custom expiry as well, but lack the concept of a "smarter loader" (AdvancedCacheLoader) that can act more efficiently based on the existing cache value.

We use setups similar to this in production.

There is a downside, too. cache2k uses one timing thread per cache, if custom expiry is used. This means your extra thread will not go away. cache2k will be enhanced in the future to have a global set of threads for timing that are shared among all caches. Update: New versions of cache2k use a common thread pool for timers.

Disclaimer: I am the author of cache2k, so I cannot speak with absolute certainty that there is no possible solution based on Guava.

Answered By - cruftex