-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Race condition in computing write timestamp #1623
Comments
Looks like this is the part that ensures "that in-flight async computation cannot expire." caffeine/caffeine/src/main/java/com/github/benmanes/caffeine/cache/BoundedLocalCache.java Lines 1930 to 1940 in 5d453e9
Why can't it be done synchronously at the same time as when the |
I wanted to investigate removing that (#1478 (comment)). I think that other changes meant this wasn't needed, and maybe an artifact of old logic or bug workarounds. Offhand I don't recall of the details, but it did seem like some of this should be changed to be simpler and more correct. At insertion time the AsyncExpiry sets the value for a variable expired entry. For fixed expiration it might have seemed easier to do it here than at all of the other write paths. Ideally it would done at insertion time, but |
The
expireAfterWrite
timestamp for an async load should be computed when theCompletableFuture
iscomplete
and not when it is put into the cache, right? It looks like there's an after-write maintenance task to make incompleteCompletableFuture
s unevictable after theCompletableFuture
is first put into the cache, but if theCompletableFuture
iscomplete
d before that maintenance task runs, then the write timestamp would be incorrect.Here's a failing test case of the issue:
The text was updated successfully, but these errors were encountered: