-
Notifications
You must be signed in to change notification settings - Fork 25.6k
[ES|QL] Ensure Inference Service answer using only SEARCH and SEARCH_COORDINATION thread pools. #135071
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
[ES|QL] Ensure Inference Service answer using only SEARCH and SEARCH_COORDINATION thread pools. #135071
Conversation
|
Pinging @elastic/es-analytical-engine (Team:Analytics) |
| }, listener::onFailure)); | ||
| final CountDownActionListener countdownListener = new CountDownActionListener( | ||
| inferenceIds.size(), | ||
| ActionListener.wrap(_r -> listener.onResponse(inferenceResolutionBuilder.build()), listener::onFailure) |
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.
NIT: could be simplified with
| ActionListener.wrap(_r -> listener.onResponse(inferenceResolutionBuilder.build()), listener::onFailure) | |
| listener.delegateFailureAndWrap((l, v) -> l.onResponse(inferenceResolutionBuilder.build())) |
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.
Thank you for the advice.
I end up using delegateFailureIgnoreResponseAndWrap instead of delegateFailureIgnoreResponseAndWrap
76a089c to
5ac62cc
Compare
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
#132324 introduced some check during query planning to make it sure that it is executed in one of the following thread pool:
ThreadPool.Names.SEARCH,ThreadPool.Names.SEARCH_COORDINATIONThreadPool.Names.SYSTEM_READ.#134777 fixed a bug caused by the
InferenceResolverthat were using an inference threadpool to ruturn its response (implicitly because using the client listener).This PR:
InferenceResolverInferenceRunnerwill not be affected if used during the query planning (which will be the case)