-
Notifications
You must be signed in to change notification settings - Fork 40k
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
Allow switching rate limiter inside RateLimitedQueue #28882
Conversation
|
||
// SwapLimiter safely swaps current limiter for this queue with the passed one if capacities or qps's differ. | ||
func (q *RateLimitedTimedQueue) SwapLimiter(limiter flowcontrol.RateLimiter) { | ||
if q.limiter.Capacity() == limiter.Capacity() && q.limiter.QPS() == limiter.QPS() { |
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.
This is accessing q.limitted, so also should be done under lock (potentially a different thread can SwapLimitters at the same time.
newLimiter = flowcontrol.NewTokenBucketRateLimiter(newQPS, evictionRateLimiterBurst) | ||
} | ||
// If we're currently waiting on limiter, we drain the new one - this is best effort approach. | ||
for q.limiter.Saturation() > newLimiter.Saturation() { |
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.
Well, in case of all limitters have Burst=1 it doesn't matter, but I still think that this method of saturation is bad.
Can you please at least add a TODO to consider changing it to be more numer-of-calls-oriented (as I described previously?).
One comment. |
Done. @wojtek-t PTAL |
LGTM |
GCE e2e build/test passed for commit f6b1c31. |
@k8s-bot test this [submit-queue is verifying that this PR is safe to merge] |
GCE e2e build/test passed for commit f6b1c31. |
Automatic merge from submit-queue |
Ref. #28832
cc @davidopp