Bucket4J for client-side rate limiting

[aritzbastida]

Hi, sorry, I'm quite new to the concept of rate-limiting in general, and to the leaky-token algorithm in particular.

I'm trying to use Bucket4J for client-side rate-limiting. Looking at the "basic examples", Bucket4J seems like a good fit, just using it as scheduler: bucket.asScheduler().consume(1);

However, I don't want to block the thread, but "program" it for the future, setting up a delayed task, be it using a java.util.concurrent.DelayQueue, Quartz or JMS 2.0 "deliveryDelay"feature. The problem is I don't find the way to calculate the corresponding (accumulative) delay for each request.

Ideally, the asScheduler() feature should allow plugging in any scheduling system. For that, it would suffice to calculate the estimated delay, as in the folllowing example:

Suppose we have 2 permits and a refill rate of 1 per second. If a burst of 5 messages arrive at approx. the same time:

• Message 1: Delay 0
• Message 2: Delay 0
• Message 3: Delay 1s
• Message 4: Delay 2s
• Message 5: Delay 3s

That is, the time the messages would wait in bucket.asScheduler().consume(1).

[vladimir-bukhtoyarov]

Hello @aritzbastida

To avoid thread blocking you need to use asAsyncScheduler(instead of asScheduler) and pass your custom implementation of ScheduledExecutorService as a parameter to any method of interface AsyncScheduledBucket. You really need to implement only one method of ScheduledExecutorService:

public ScheduledFuture<?> schedule(Runnable command, long delay, TimeUnit unit);

Other methods of ScheduledExecutorService are unused by Bucket4j. Inside the implementation of schedule, you are able to delegate postponed processing to anywhere you want. ScheduledFuture that returned also not used by Bucket4j, so do not spend efforts to provide correctly result.

[aritzbastida]

Thank you very much! It's exactly what I need for my scenario. Just tested it and works like a charm.
It would be good to add it to the "examples" case, as I think it can be a useful for other people as well. :)

[vladimir-bukhtoyarov]

Eventually, I am going rewrite all reference documentation in scope of #69 but currently, have no time to do so.