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

Implement token return for the token bucket rate limiting strategy #769

Open
kas1337 opened this issue Jan 27, 2023 · 3 comments
Open

Implement token return for the token bucket rate limiting strategy #769

kas1337 opened this issue Jan 27, 2023 · 3 comments

Comments

@kas1337
Copy link

kas1337 commented Jan 27, 2023

The current implementation for the token bucket ("smooth") rate limiting strategy does not support token return. The idea is that the bucket is not only filled periodically with a defined amount of token but also that a token is placed back into the bucket when a request is finished.

It would be nice if there is a rate limit option that you can enable or disable.

@Ladicek
Copy link
Contributor

Ladicek commented Jan 27, 2023

Could you please point me to some materials that I can read to learn more about token bucket rate limiting with token return? I admit my rate limiting knowledge is rather limited, but I don't recall seeing token return mentioned in the articles I read.

@mschorsch
Copy link

bucket4j supports this feature (see hier).

@Ladicek
Copy link
Contributor

Ladicek commented Jan 27, 2023

Bucket4j is a much more complete and advanced and feature-full implementation of token bucket than SmallRye Fault Tolerance will likely ever have. If you need that, I see nothing wrong with using Bucket4j.

That said, how would you imagine token return would work in SmallRye Fault Tolerance? Can you show an example or two of code you'd like to write and add a comment about their meaning?

I see there would probably need to be more config options for token bucket than the other algorithms (for example, the initial token count is currently hardcoded). So I'm thinking maybe a 2nd annotation specific to the smooth rate limiter would be in order -- the @RateLimit annotation is pretty overcrowded already.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants