-
|
Hi, I tested this very simple parameters of the cache: var cache = Caffeine.newBuilder()
.maximumSize(1000)
.expireAfterAccess(15, TimeUnit.SECONDS)
.build();
// Adding objects: E1, E2, E3, ..., E1000 should fit into cache
// Adding E1001 should lead to eviction of E1. Or it can remove, say, any element just not the "latest ones" (by some metric).For my particular use case, I would love elements the newly added elements to stay in the cache longer than elements added previously. Is there a way to do it please? Or should I migrate back to Guava as Caffeine uses a different eviction policy? Thank you! |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment
-
|
You should probably revert back to Guava if your business logic depends on LRU eviction order. Caffeine's policy is adaptive to maximize the hit rate and initially starts in an LFU configuration and will find the optimal LRU-LFU setting at runtime. We don't want to make promises on eviction order and only allow constraints on the overall behavior to fit your size/time/etc settings. How we do that is implementation details that could change. Typically if required by business logic then this should be very explicit, or else it is often mistaken preferences that don't fit the actual data. If this is just a nice to have then you should rely on our adaption to tune itself. The closest knob we support is entry pinning to opt out of eviction. That's probably irrelevant but just fyi if your actual goal. |
Beta Was this translation helpful? Give feedback.
You should probably revert back to Guava if your business logic depends on LRU eviction order. Caffeine's policy is adaptive to maximize the hit rate and initially starts in an LFU configuration and will find the optimal LRU-LFU setting at runtime. We don't want to make promises on eviction order and only allow constraints on the overall behavior to fit your size/time/etc settings. How we do that is implementation details that could change. Typically if required by business logic then this should be very explicit, or else it is often mistaken preferences that don't fit the actual data. If this is just a nice to have then you should rely on our adaption to tune itself.
The closest knob we …