Shouldn't this be subtracting the bytes?

My mistake. Will fix it.

Is this available in our settings.gradle file? If not, we should move it there. If so, use that version.

We should probably avoid exposing the constructor and use a builder pattern for this, similar to Caffeine's builder pattern.

These builders seem far too restrictive. Similar to my comment above, we should have a builder and then map those fields to Caffeine versions.

We don't need to support all the fields now. But, the code should be written in such a way that it is trivial to add them. Probably having the builder in a separate file would help.

If it's not a string, then you assume it's an Event. This would throw a cast class exception and be quite unclear.

Maybe this code should also go into a different class to allow for different types.

This code is strongly related to the code above and duplicated. Let's consolidate it.

cache.asMap().containsKey(key)

Caffeine isn't an LRU cache, nor strict in its decision making, so this flag is confusingly named. Perhaps the confusion is that weighted entries consume more space and likely makes it evict a candidate earlier in a unit test with a tiny maximum. The cache internally uses adaptive regions to tune itself based on the observed workload.

@ben-manes Thank you very much for your review. So, there is no way to get LRU behavior where the new key is always inserted by throwing out an existing entry ( preferably LRU, but other may be ok, too)?

A new entry may go in but there are lots of reasons why it might be evicted promptly. A tiny cache for unit tests might see aggressive removal, but a larger cache with activity will be more balanced. The behavior isn’t deterministic though, it’s optimized for hit rates and injects randomness for denial of service protection

Thanks @ben-manes. Is there any way to get more deterministic behavior? We definitely want the new element to be inserted by evicting an existing element on some criteria. It is OK what gets evicted is not deterministic.

@ben-manes Any reason why memcache like LRU behavior is not included in this?

The cache uses two regions, admission and main. It always keeps admission large enough to keep 1 unit of capacity (an entry). When you use weighted entries, the single unit is not enough as your cache entry takes many. In a tiny cache for testing then it might be rejected. In a production sizing then there will be more space. memcached uses three regions and would be given far more space. It’s only that unit tests can be confusing and it’s likely okay

Is this cache called by multiple threads? If so then its racy and you could use cache.asMap().computeIfPresent along with atomics.

cache.asMap().size()?

I am not using cache directly here because cache may not reflect the current state unless cleanup() is called, is my understanding incorrect?

I don’t think there is a difference since you are relying on the cache to decrement this on cleanup in your removal listener, e.g. after expiration.

This would run automatically after a put, but in a non-blocking manner. I'll usually set Caffeine.executor(Runnable::run) in unit tests to disable async so it runs on the caller.

You could also use Caffeine.scheduler(Scheduler.systemScheduler()) if you wanted prompt removal after expiration

fwiw, you can get the weightedSize() from cache.policy().eviction() if isWeighted().

fyi, 3.2.2 is the current release

technically not needed fwiw

Is there another option/mode that Caffeine Cache automatically evict an entry after its first access? This would be useful for the Merge use case where each key only needs to be accessed once and can be removed immediately after to optimize memory usage.

Most likely the cache will detect this and automatically tune itself, as its goal is to maximize the hit ratio. Therefore it wants to evict unused entries aggressively. It will adaptively size a new arrival region (admission window) with a long-term popular region (main), using a frequency filter to guard the promotion.

The workload below has a blockchain trace chained with an analytical loop. The mining is LRU-biased since multiple workers pick up the event, validate it, and its unused thereafter. The analytics is MRU-biased as it scans over rows so it protects the useful contents from being forced out. The stress test switches between traces to show the cache adapts to the changing workload and no tuning parameters are needed. The hope is that it works out-of-the-box, but of course measuring the actual behavior is always good regardless.