-
Notifications
You must be signed in to change notification settings - Fork 135
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
Feature: Zero Warmup Guava RateLimiter #1950
Conversation
…r/gradle-baseline into keviny/zero-warm-up-rate-limiter
Co-authored-by: Carter Kozak <ckozak@ckozak.net>
...line-error-prone/src/test/java/com/palantir/baseline/errorprone/NoWarmupRateLimiterTest.java
Outdated
Show resolved
Hide resolved
...line-error-prone/src/test/java/com/palantir/baseline/errorprone/NoWarmupRateLimiterTest.java
Outdated
Show resolved
Hide resolved
baseline-error-prone/src/main/java/com/palantir/baseline/errorprone/NoWarmupRateLimiter.java
Show resolved
Hide resolved
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.
Great stuff, thanks for the contribution!
Released 4.32.0 |
###### _excavator_ is a bot for automating changes across repositories. Changes produced by the roomba/latest-baseline-oss check. # Release Notes ## 4.32.0 | Type | Description | Link | | ---- | ----------- | ---- | | Feature | Zero Warmup Guava RateLimiter | palantir/gradle-baseline#1950 | To enable or disable this check, please contact the maintainers of Excavator.
This PR introduced a behavior change. After this change, we have unit tests that began failing. I don't think it's reasonable to assume that everyone wants this behavior. |
Right, it requires human intervention to merge. Many consumers do want this behavior, the idea is that a duration should always be provided to explicitly acknowledge the behavior either way. We suggest the value we think most folks want. |
I think there's something else going on here. For example, this test will pass: @ParameterizedTest
@ValueSource(ints = {1, 10, 100, 1000})
void testRateLimiter(int permitsPerSecond) {
RateLimiter rateLimiterZero = RateLimiter.create(permitsPerSecond, Duration.ZERO);
assertThat(Stream.generate(rateLimiterZero::tryAcquire)
.limit(10 * permitsPerSecond)
.allMatch(v -> v))
.isTrue();
} |
Ouch, good catch. |
This reverts commit 3219b6c. Warmup of zero results in no rate limiting.
Before this PR
This addresses #1946
After this PR
==COMMIT_MSG==
Adds a new rule NoWarmupRateLimiter that catches
RateLimite.create
calls with no explicit warmup arguments.==COMMIT_MSG==
Possible downsides?