Handle cancellations before requests #742
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
With previous implementation, if worker was busy talking to scheduler, we didn't push the cancellation, keeping that query running. When cancelling a query, all its subqueries are cancelled at the same time, so this was most likely happening all the time (first subquery scheduled on this worker was canceled, the rest were not because worker was busy cancelling the first one). Also removed the `<-ctx.Done()` escape point when waiting for the enqueueing ACK and modified the enqueueing method to ensure that it always responds something. Fixes: #740 Inspired by: grafana/loki#5113 Signed-off-by: Oleg Zaytsev <mail@olegzaytsev.com>
Signed-off-by: Oleg Zaytsev <mail@olegzaytsev.com>
When scheduler worker is handling requests, if there's certain pressure on the loop, we can keep enqueueing requests instead of handling the cancellations. However, when there's that pressure on the loop, it's more important than never to properly cancel the requests. This checks the cancellations channel first, and then checks the requests channel too. Related to #741 Signed-off-by: Oleg Zaytsev <mail@olegzaytsev.com>
|
While implementing #741 I thought about this. WDYT @cyriltovena ? |
|
I think the problem is that if goroutine isn't waiting for cancellation at the exact moment when sender tries to send the cancellation, sender just gives up. I think we could instead add some buffer to cancellation channel or make it wait a bit longer. I'm not sure changing receiving part is the way to go, because if receiver (worker goroutine) is busy (eg. forwarding some request), sender will not send the cancellation request. |
|
@pstibrany, yes, I already did that in #741. PTAL This is just an extra I wanted to discuss. Also not sure about it, that's why it's draft and not included there. |
Base automatically changed from
increase-frontend-scheduler-worker-cancellation-channel-capacity
to
main
January 14, 2022 08:34
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What this PR does:
When scheduler worker is handling requests, if there's certain pressure on the loop, we can keep enqueueing requests instead of handling the cancellations. However, when there's that pressure on the loop, it's more important than never to properly cancel the requests.
This checks the cancellations channel first, and then checks the requests channel too.
Related to #741
Which issue(s) this PR fixes:
None, relates to #740
Checklist
CHANGELOG.mdupdated - the order of entries should be[CHANGE],[FEATURE],[ENHANCEMENT],[BUGFIX]