-
Notifications
You must be signed in to change notification settings - Fork 564
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
[v23.3.x] CORE-2752 - Fix Kafka quota throttling delay enforcement #18575
Merged
pgellert
merged 5 commits into
redpanda-data:v23.3.x
from
pgellert:vbotbuildovich/backport-18218-v23.3.x-467
May 21, 2024
Merged
[v23.3.x] CORE-2752 - Fix Kafka quota throttling delay enforcement #18575
pgellert
merged 5 commits into
redpanda-data:v23.3.x
from
pgellert:vbotbuildovich/backport-18218-v23.3.x-467
May 21, 2024
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
While exempt clients are already excluded from their traffic being recorded, they are still being throttled if the token bucket is in a negative state because of other clients. To avoid this, exempt clients should have a 0 throttling delay to be excluded from throttling altogether. (cherry picked from commit cea3a29)
Quota enforcement is currently done in a complicated and not-Kafka-compatible way in Redpanda, and this commit intends to fix that. In Kafka >=2.0, client throttling is implemented in a simple way. Brokers are meant to return how long the client is supposed to be throttled when there is a quota violation. Then, the Kafka client is supposed to wait until this throttling time passed, or else the broker applies the throttle on its side. However, currently in Redpanda the delay is enforced differently. For produce, we enforce the throttle we would send in the response if there was a throttle in the last response (regardless of whether the client obeyed that throttle or not). For fetch, we always enforce the current throttle. For ingress/egress quotas we correctly track how long the client was supposed to be throttled, but we only do that for ingress/egress throttling. This commit fixes the throttling behaviour by tracking how long the client is supposed to have waited and applying that throttle on the next request if the client did not. (cherry picked from commit aec585d)
(cherry picked from commit 286aaa7)
(cherry picked from commit fd18208)
(cherry picked from commit b540b74)
The only reason I had to cherry-pick this manually was that git thought there was a conflict on the |
BenPope
approved these changes
May 20, 2024
oleiman
approved these changes
May 21, 2024
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.
Backport of PR #18218
Fixes #18569
Fixes https://redpandadata.atlassian.net/browse/CORE-3019