Replies: 1 comment
-
Hello @ShadyD45
You are right, blocking bucket behaves in this way. Additionally, bucket proactively decrements amount of tokens in order to protect tokens from to be stolen by parallel threads while current thread is parked. I call this process as reservation. It also need to keep in mind that reservation can temporary make available tokens less than zero.
To estimate correctness of this workaround I need to have actual numbers:
|
Beta Was this translation helpful? Give feedback.
-
Hello @vladimir-bukhtoyarov, Great work on the library! I've some questions about BlockingBucket, Reading the docs I see what it does is it predicts if tokens are going to be available after the specified time, if yes it'll be put in waiting. But if not the request is rejected immediately and I believe this prediction is done based on the refill rate of bucket, please correct me if I'm wrong.
I've one scenario where I've put a very long refill on bucket but it is rejecting all requests after tokens are exhausted without putting them in waiting and i think my above understanding is the reason. Can you suggest if we can bypass this prediction And just put the request in waiting for given time and then trying to consume then reject if not available?
One workaround I think can work is to have a reasonable refill period and use that refill period to calculate waiting period for each request that comes in after token exhaustion to create an illusion for the prediction logic that tokens will be refilled so that it'll put request in waiting. Can that work?
Thankyou in advance!
Beta Was this translation helpful? Give feedback.
All reactions