Chore: Extracted interface Cache from 'LRUCache' #130964
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…nder the old name to allow other implementations to be tested. - Found and fixed minor bug where we tested max weight against count() instead of weight - Found and fixed minor issue with possible long overflow. - Adjusted tests but made explicit the ones who rely on the `LRUCache` implementation to test if settings are applied correctly. While CacheBuilder#build() returns a `Cache` it still always returns the `LRUCache` implementation
elasticsearchmachine
added
v9.2.0
external-contributor
Updated Javadoc to clarify method behaviors, guarantees, and expectations for implementers of the Cache interface. Introduced default `refresh` method and improved descriptions for traversal methods, weights, and removal notifications for consistency.
…f preventing, very unlikely, overflow
- Refactored CacheTests to LRUCacheTests - Added new CacheTests that test for Cache contract - Added toString() to RemovalNotification
elasticsearchmachine
added
the
needs:triage
|
Not sure about the context of this change. The code is owned by @elastic/es-core-infra, so I took myself off the reviewers. |
elasticsearchmachine
added
Team:Core/Infra
|
Pinging @elastic/es-core-infra (Team:Core/Infra) |
elasticsearchmachine
added
the
serverless-linked
…vant classes and tests as it's pulled out into elastic#131784
…vant classes and tests as it's pulled out into elastic#131784
mjmbischoff
removed
the
serverless-linked
# Conflicts: # server/src/main/java/org/elasticsearch/common/cache/Cache.java
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Chore: Extracting a Cache interface to allow exploring alternative implementations. Alternative implementations are outside the scope of this PR.
I know indirection is bad for performance, but the
Cache/LRUCachealready lists trade-offs, I expect things to get inlined quickly enough during runtime, so everything considered, I don't think this will 'do us in'.Along the way found some minor bugs and issues
LRUCacheimplementation to test if settings are applied correctly. (While CacheBuilder#build() returns aCacheit still always returns theLRUCacheimplementation)Cache.CacheStats/Cache.Statsa record. Getters we're kept for now, should perhaps inline access in the future.RemovalListenerand how the interface doesn't mandate how, how many, and what the effects are if registered listener is swapped or if multiple listeners can be registered and what happens when they are added or removed.Context
The Cache/LRUCache is the only implementation of a cache within the ES code base, the implementation dates from 2015 when different priorities were being juggled. Being the only implementation part of the codebase, it's usage has grown over the years, for example: Enrich, Interference, Searchable snapshots. While the choices at the time were sound, as the external factors have changed, it makes sense to revisit these. As a first step PR which looks to extract an Interface and formalize the contract between implementation and consumer.
Somewhat complete list of use cases that use the cache:
NOTES (ramblings of the author, for context, can be ignored):
The wording of javadoc of the old
Cache/LRUCachemight have sounded 'overly scary/dangerous' leading to some interesting usage/interactionAs already pointed out in comments org.elasticsearch.xpack.core.security.support.CacheIteratorHelper, it's a little wonk. I'm also unsure if the extra protection is needed. Regardless the design of that class to leak the locks and not pull up interaction and fully decorate a cache a la Collections.unmodifiableXXX(XXX) is... 'not (personally) preferred'. But this would be a separate PR.
A computed weight is being tracked as long, which can overflow. Always calculating it on the fly or calculating it on the fly after detecting overflow is an option. Also wondering about thread safety as we're incrementing and something like an AtomicLong is needed. 'Best-effort' :-) Changing the LRUCache impl is out of scope of this PR, so left alone.
For the reviewer:
old
Cachewas refactored toLRUCache, please diff these, there shouldn't be any changes beyond the name and pulling the shared inner classes out. Github shows a diff between the oldCacheand the interface that is now created at the old coordinate. It seems that context was lost which makes it appear like a much bigger PR than it is.Similar with CacheTests and LRUCacheTests. (CacheTests is completely new)