Sharing Knowledge: RateLimiter from Guava library

To get an understanding of Guava library's RateLimiter, I was going through this article https://guava.dev/releases/22.0/api/docs/index.html?com/google/common/util/concurrent/RateLimiter.html

After looking at the above piece of code, I had a doubt of how the acquire method works as I was wondering what will happen if the packet length is more than 5k. I wrote this program.

The output is this:

2020-02-19T10:43:40.249Z - Time before our actual logic gets executed

2020-02-19T10:43:40.446Z - Time after first acquire(5)

2020-02-19T10:43:45.448Z - Time after acquire(3)

2020-02-19T10:43:46.946Z - Time after acquire(1)

2020-02-19T10:43:47.447Z - Time after 2nd acquire(1)

2020-02-19T10:43:47.946Z - Time after 3rd acquire(1)

As mentioned in the https://guava.dev/releases/22.0/api/docs/index.html?com/google/common/util/concurrent/RateLimiter.html, if an expensive task arrives at an idle RateLimiter, it will be granted immediately, but it is the next request that will experience extra throttling thus paying for the cost of the expensive task.

There is no waiting at the acquire(10). But the next acquire had to wait for 5 seconds. The reason for 5 seconds is because we have created the RateLimiter with "2 permits per second". So, 5 seconds is required to generate 10 permits. After 5 seconds are done, the next acquire(3) is served immediately. But the next acquire had to wait for 1.5 seconds.

After waiting for 1.5 seconds as mentioned above, the next acquire(1) is executed immediately. But subsequent each acquire(1) has to wait for 0.5 seconds because RateLimiter ensures 2 permits per second which mean 1 permit per 0.5 seconds.

Coming back to the initial example mentioned in the guava official link, if the packet length is 10k, the first call will return immediately but guava library will maintain a clock which will ensure that the next acquire waits for 2 seconds (10k / 5k permits per second = 2 seconds)

(Copied from official doc: It is important to note that the number of permits requested never affects the throttling of the request itself (an invocation to acquire(1) and an invocation to acquire(1000) will result in exactly the same throttling, if any), but it affects the throttling of the next request. I.e., if an expensive task arrives at an idle RateLimiter, it will be granted immediately, but it is the next request that will experience extra throttling, thus paying for the cost of the expensive task.)

RateLimiter uses Token Bucket algorithm which is explained in https://dzone.com/articles/detailed-explanation-of-guava-ratelimiters-throttl