ben-manes / caffeine

95%

master: 100%

LAST BUILD ON BRANCH v2.2.2

branch: v2.2.2

CHANGE BRANCH

x

Reset

• v2.2.2
• 05a040c2478341bab8a58a02b3dc1fe14d626d72
• 2.5.6
• Gil
• adaptive
• async-loader
• ben/issue30
• ben/spacing
• buffer
• cache2k
• clockpro
• codeql
• dependabot/github_actions/JetBrains/qodana-action-2023.1.4
• dependabot/github_actions/JetBrains/qodana-action-61b94e7e3a716dcb9e2030cfd79cd46149d56c26
• dependabot/github_actions/codecov/codecov-action-3.1.3
• dependabot/github_actions/github/codeql-action-2.3.4
• dependabot/gradle/com.gradle.common-custom-user-data-gradle-plugin-1.9
• dependabot/gradle/com.gradle.enterprise-3.14
• dependabot/gradle/de.thetaphi-forbiddenapis-3.6
• dependabot/gradle/pmd-7.0.0-rc4
• expiring_map
• expiry
• gil
• gilga
• gradient
• guava
• jctools
• juherr
• master
• memory
• orm
• penalties
• solr
• testng
• tmp
• travis
• v1.0
• v1.0.1
• v1.1.0
• v1.2.0
• v1.3.0
• v1.3.1
• v1.3.2
• v1.3.3
• v2.0.0
• v2.0.1
• v2.0.2
• v2.0.3
• v2.1.0
• v2.2.0
• v2.2.4
• v2.3.2
• v2.3.4
• v2.5.2
• v2.5.3
• v2.5.4
• v2.5.5
• v2.6.1
• v2.7.0
• v2.8.0
• v2.8.1
• v2.8.2
• v2.8.3
• v2.8.4
• v2.8.5
• v2.dev
• v3.0.5
• v3.0.6
• v3.1.0
• v3.1.1
• v3.1.2
• v3.1.4
• v3.1.5
• v3.1.6
• v3.1.7
• v3.1.8
• v3.dev

Build # 1629

Build Type

push

travis-ci

Committed by ben-manes

Commit Message

Fix async refresh from prematurely replacing the value

When a refresh-after-write is triggered the entry should be reloaded in
the background, the present value available for reads, and atomically
replaced when the new value has been loaded. This operation is atomic
with other writes to that entry and is blocking (rather than clobbering)
if another write is attempted.

This should work the same for synchronous and asynchronous caches, but
unfortunately it wasn't. For an asycn cache a new, incomplete future
was immediately put into the cache and available to be consumed by the
next request. Due to layering, the custom reloadAsync was not called and
the operation delegated to load instead. This was of course wrong and
not the intended (or expected) behavior, so it is now fixed.

Thanks to Etienne Houle @ Stingray for notifying me of this problem.

Run Details

25 of 25 new or added lines in 1 file covered. (100.0%)

5039 of 5308 relevant lines covered (94.93%)

0.95 hits per line