-
Notifications
You must be signed in to change notification settings - Fork 25.4k
Fix the request cache keys to not hold references to the SearchContext. #21284
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
Fix the request cache keys to not hold references to the SearchContext. #21284
Conversation
Currently the request cache adds a `CacheEntity` object. It looks quite innocent but in practice it has a reference to a lambda that knows how to create a value. The issue is that this lambda has implicit references to the SearchContext object, which can be quite heavy since it holds a structured representation of aggregations for instance. This pull request splits the `CacheEntity` object from the object that generates cache values.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
left a couple of comments, looks great!
try { | ||
context.queryResult().writeToNoId(out); | ||
} catch (IOException e) { | ||
throw new IllegalStateException("Could not serialize response", e); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maybe make this even an AssertionError?
IndexShardCacheEntity cacheEntity = new IndexShardCacheEntity(shard, loader); | ||
return indicesRequestCache.getOrCompute(cacheEntity, reader, cacheKey); | ||
IndexShardCacheEntity cacheEntity = new IndexShardCacheEntity(shard); | ||
boolean[] loadedFromCache = new boolean[] { true }; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
do we need to return this, I think we can rely on that the loader is called when we load the result again so the caller can use this to obtain that boolean...?
queryPhase.execute(context); | ||
context.queryResult().writeToNoId(out); | ||
try { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we just use a boolean here that we set to false when this loader is executed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
…t. (#21284) Currently the request cache adds a `CacheEntity` object. It looks quite innocent but in practice it has a reference to a lambda that knows how to create a value. The issue is that this lambda has implicit references to the SearchContext object, which can be quite heavy since it holds a structured representation of aggregations for instance. This pull request splits the `CacheEntity` object from the object that generates cache values.
…t. (#21284) Currently the request cache adds a `CacheEntity` object. It looks quite innocent but in practice it has a reference to a lambda that knows how to create a value. The issue is that this lambda has implicit references to the SearchContext object, which can be quite heavy since it holds a structured representation of aggregations for instance. This pull request splits the `CacheEntity` object from the object that generates cache values.
Currently the request cache adds a
CacheEntity
object. It looks quite innocentbut in practice it has a reference to a lambda that knows how to create a value.
The issue is that this lambda has implicit references to the SearchContext
object, which can be quite heavy since it holds a structured representation of
aggregations for instance.
This pull request splits the
CacheEntity
object from the object that generatescache values.