caffeine: Occasionally Value is not evicted after `expireAfterWrite` setting.
Hi, I’m facing some weird problem recently. My caffeine version is 2.5.6.
My cache setting is like this
Caffeine.newBuilder()
.refreshAfterWrite(300 / 2, TimeUnit.SECONDS)
.expireAfterWrite(300, TimeUnit.SECONDS)
.maximumSize(cacheSize)
.recordStats(...)
.executor(...)
.buildAsync((key, ignored) -> getFromRemote(key))
Sometimes 1 of my servers has stale data in caffeine cache. I have taken the heap dump, but I’m not sure if there is a way to let me find the clue(Maybe the problem is my remote calling code, but not found the problem yet).
stale’s one (writeTime -9189666743569861076), data was updated 2 days before, and as above, I set 5 mins as expire time.
another data from cache in same instance(writeTime 33948135258891076)
And curious about the differences of writeTime too.
I trace the code and it looks like -9189666743569861076 - Long.MAX_VALUE = 33705293284914733
. so it means it doesn't reset on a completion callback
?
(33948247-33705293)/60/60/24 = 2.x days.
so it’s unfinished processing? But Node.value(CompletableFuture).result has data.
Is there any possibility that can make caffeine not to update/evict? (I’m not sure, but if the write time keep -9189666743569861076(far future) make it never expired?)
About this issue
- Original URL
- State: closed
- Created 7 years ago
- Reactions: 1
- Comments: 23 (11 by maintainers)
Commits related to this issue
- JCache 1.1; Automatic-Module-Name; and other potential fixes Now passes the TCK tests that were backwards incompatible with 1.0. The OSGI test is enabled now that jsr107 includes the bindings. Added... — committed to ben-manes/caffeine by ben-manes 7 years ago
- JCache 1.1; Automatic-Module-Name; and other potential fixes Now passes the TCK tests that were backwards incompatible with 1.0. The OSGI test is enabled now that jsr107 includes the bindings. Added... — committed to ben-manes/caffeine by ben-manes 7 years ago
- JCache 1.1; Automatic-Module-Name; and other potential fixes Now passes the TCK tests that were backwards incompatible with 1.0. The OSGI test is enabled now that jsr107 includes the bindings. Added... — committed to ben-manes/caffeine by ben-manes 7 years ago
Released
I tried and let it run 1 day. Compare to previous test(3 instance, 1 day) 2.5.6: All servers have 1~100 entries’ writeTime in far future. 2.6.1-Snapsot: No server has far future writeTime entry. Current nanoTime is around ~34438964688472572L, and there is no < 0 data.
I think the fix solve the issue.
I think that I made the proper changes here. The latest build should be in the snapshot repository shortly. Can you use that and see if we fixed the problem?