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

Feature: Zero Warmup Guava RateLimiter #1950

Merged
merged 8 commits into from
Nov 2, 2021

Conversation

kevin-yu-0602
Copy link
Contributor

@kevin-yu-0602 kevin-yu-0602 commented Nov 2, 2021

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?

@policy-bot policy-bot bot requested a review from xRuiAlves November 2, 2021 16:51
README.md Outdated Show resolved Hide resolved
Co-authored-by: Carter Kozak <ckozak@ckozak.net>
Copy link
Contributor

@carterkozak carterkozak left a 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!

@bulldozer-bot bulldozer-bot bot merged commit 3219b6c into develop Nov 2, 2021
@bulldozer-bot bulldozer-bot bot deleted the keviny/zero-warm-up-rate-limiter branch November 2, 2021 17:19
@svc-autorelease
Copy link
Collaborator

Released 4.32.0

bulldozer-bot bot pushed a commit to palantir/witchcraft-api that referenced this pull request Nov 2, 2021
###### _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.
@pkoenig10
Copy link
Member

This PR introduced a behavior change. After this change, we have unit tests that began failing.
https://c.p.b/gh/foundry/multipass/321545

I don't think it's reasonable to assume that everyone wants this behavior.

@carterkozak
Copy link
Contributor

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.

@pkoenig10
Copy link
Member

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();
}

@carterkozak
Copy link
Contributor

Ouch, good catch.

carterkozak added a commit that referenced this pull request Nov 4, 2021
This reverts commit 3219b6c.
Warmup of zero results in no rate limiting.
bulldozer-bot bot pushed a commit that referenced this pull request Nov 4, 2021
Revert "Feature: Zero Warmup Guava RateLimiter (#1950)"
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants