-
Notifications
You must be signed in to change notification settings - Fork 28
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
Rate control primitives? #120
Comments
Thanks! Definitely, rate control is something that will be great to include, and very much in-line with the scope of the project, in the "resiliency" part. |
Just as Ox has Rate limiting itself should be possible in a stateful way, e.g. given a As to the rate limiting configuration options, the algorithm mentioned in the original description should be available. Moreover, resilience4j might provide more inspiration. |
/bounty $500 |
💎 $500 bounty • SoftwareMillSteps to solve:
Thank you for contributing to softwaremill/ox! Add a bounty • Share on socials
|
/attempt #120
|
/attempt #120 Options |
💡 @pablf submitted a pull request that claims the bounty. You can visit your bounty board to reward. |
/attempt #120 Options |
As we are getting first PRs for the bounties, I've published our "How to prepare a good PR" guide. I should have probably done this right away, sorry! :) |
Hi! At first, thank you for great async library! I tried examples and played exercises using documentation. It was full of fun!
My suggestion is providing rate control primitives (e.g. simple rate limit, smart (leaky bucket / token bucket) algorithm).
Sometimes I want rate control in production concurrent programming (e.g. batch processing along HTTP API).
Of course, we can implement simple control using
par()
andSource.tick()
. But in production use, I think out-of-the-box rate control primitives is preferred.The text was updated successfully, but these errors were encountered: