-
Notifications
You must be signed in to change notification settings - Fork 25.1k
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
Should we have a default timeout? #26308
Comments
+1 to have a default timeout, return a |
206 status code is inappropriate. It's appropriate only if the client sends a range request (as indicated by a |
Okay that makes sense then. Still +1 on the timeout though
|
The thing that bothers me about the default timeout is the timeout reporting. Right now we return a |
Discussed it in FixItFriday, the partial result is a big concern so we decided to explore adding a new setting at the cluster level (or at the index level if needed) that would add an hard timeout to search request. It could be activated by default with a very high value like 5 minutes. The benefit would be to automatize the garbage collection of long running queries. |
/cc @dakrone since he ran the tests, I just played with some spreadsheets to generate the p-values :) |
Pinging @elastic/es-search-aggs |
Should we close this in favour of #26258 ? |
If we close I think it should be in favor of #30897 and we can discuss the need for a default value there ? |
While discussing #26258 @jimczi asked whether we should set a default timeout. This proved a bit controversial: on the one hand it would reduce the impact that insane queries could have on clusters but on the other hand this might be a bit trappy as users might not be checking the
timed_out
field of search responses, which is the way to know that the response is partial due to a timeout. I'm opening this issue to get opinions from a wider audience.The text was updated successfully, but these errors were encountered: