Skip to content
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

[Feat] allow optional searcher.terminationGracePeriodSeconds #127

Merged
merged 7 commits into from
Feb 3, 2025

Conversation

katlim-br
Copy link
Contributor

@katlim-br katlim-br commented Jan 31, 2025

I propose to add this optional terminationGracePeriodSeconds to the searcher (similar to the indexer).

In our use case, our customers directly use the QW instances. Therefore, we want to wait the longest possible so most queries return without breaking the UX.

Probable values to use: 60s, 90s.

@katlim-br
Copy link
Contributor Author

This will wait for this other more urgent PR to be merged first (#128).

That is why I'm setting here to version 0.7.14.

@katlim-br katlim-br changed the title allow optional searcher.terminationGracePeriodSeconds [Feat] allow optional searcher.terminationGracePeriodSeconds Feb 1, 2025
@guilload
Copy link
Member

guilload commented Feb 3, 2025

I'm sorry, I don't understand the use case. Indexers are stateful and we want to wait for the data in-flight to be indexed before shutting down the pods. On the hand, searchers are stateless.

@katlim-br
Copy link
Contributor Author

I'm sorry, I don't understand the use case. Indexers are stateful and we want to wait for the data in-flight to be indexed before shutting down the pods. On the hand, searchers are stateless.

Sure. We want to minimize the search queries getting cut off if a deploy is triggered.
Some of our queries take more than 30 seconds, so we want to tune this.

I agree that the solution is to handle the error and retry from the client, but we want to minimize the need to do it.

In our use case, our customers run the queríes for themselves, so we want to be less disruptive as possible.

As mentioned, our target will probably be 60s.

@guilload
Copy link
Member

guilload commented Feb 3, 2025

Ok that makes sense. However, I'm not entirely sure Quickwit searchers do the right thing when receiving a shutdown signal: i.e. they should stop accepting new requests and wait for the in-flight requests to be drained, but I don't know if currently this is implemented correctly.

@katlim-br
Copy link
Contributor Author

katlim-br commented Feb 3, 2025

Ok that makes sense. However, I'm not entirely sure Quickwit searchers do the right thing when receiving a shutdown signal: i.e. they should stop accepting new requests and wait for the in-flight requests to be drained, but I don't know if currently this is implemented correctly.

I can make a compromise on that. At least this will allow us to tune it for now.

If this is accepted, please merge this other PR first, so the versions are upgraded in order.

@guilload
Copy link
Member

guilload commented Feb 3, 2025

You must rebase first.

@katlim-br
Copy link
Contributor Author

You must rebase first.

done

@guilload guilload merged commit 9a01d48 into quickwit-oss:main Feb 3, 2025
1 check passed
@katlim-br katlim-br deleted the add_graceful_searcher branch February 3, 2025 19:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants