-
Notifications
You must be signed in to change notification settings - Fork 25.2k
Move some paths in SearchService towards futures and promises #124813
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
base: main
Are you sure you want to change the base?
Move some paths in SearchService towards futures and promises #124813
Conversation
Flattening the stacks a little here where we close to never go async and most importantly setting up bigger follow-ups.
Pinging @elastic/es-search-foundations (Team:Search Foundations) |
listener, | ||
request.getChannelVersion(), | ||
clusterService.localNode().getId(), | ||
request.shardId(), | ||
task.getId(), | ||
threadPool | ||
); | ||
final IndexShard shard = getShard(request); | ||
rewriteAndFetchShardRequest(shard, request, listener.delegateFailure((l, rewritten) -> { |
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.
Is it a bug that rewritten
wasn't used in the old code?
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.
Yea but a trivial one funny enough since (for better or for worse ...) we mutate the object in-place. This doesn't change behavior but saves a little GC work by removing needless capturing :)
Flattening the stack a little for rewriting, we almost never go async on a rewrite so we can save some stack depth, unnecessary listener wrapping (and resulting retention of heap objects!) here and maybe subjectively make the code a little nicer to read.
A nice side-effect of this change is that it makes profiling much easier to interpret as far as the cost of query rewriting is concerned.
This should be relatively trivial to review, there's no expected behavior changes in this because I actively stayed away from removing callback-style code for ref-counted objects/
SearchPhaseResult
instances.