Move can-match thread from transport thread to search coordinator thread #135934
Conversation
elasticsearchmachine
added
needs:triage
chrisparrinello
added
>bug
and removed
needs:triage
elasticsearchmachine
added
the
needs:triage
chrisparrinello
added
Team:Search Foundations
|
Pinging @elastic/es-search-foundations (Team:Search Foundations) |
elasticsearchmachine
removed
the
needs:triage
|
Hi @chrisparrinello, I've created a changelog YAML for you. |
|
Hi @chrisparrinello, I've updated the changelog YAML for you. |
| transportService.registerRequestHandler( | ||
| QUERY_ACTION_NAME, | ||
| EsExecutors.DIRECT_EXECUTOR_SERVICE, | ||
| transportService.getThreadPool().executor(ThreadPool.Names.SEARCH_COORDINATION), |
There was a problem hiding this comment.
I think I see what the intention is here, to move off of the transport thread part of the shard query phase that happens before we fork to search, can you confirm?
The title of the PR refers to can match thread though, while this moves the query action (rather than can match) to search coordination.
There was a problem hiding this comment.
SearchService::executeQueryPhase is an overloaded function. As far as I can tell, the executeQueryPhase referenced here is performing a can-match (if possible) and if the can-match succeeds, then calls the other executeQueryPhase function which is doing the normal query phase.
There was a problem hiding this comment.
Ugh, we really shouldn't have named two different methods doing different things by one name... But there seems to be four executeQueryPhase methods, quite confusing tbh. None of them have any explanation on how they differ from others, sigh.
Fixes #134959