Guava RateLimiter Bursting

Question

I've been playing around with a thottling system and stumbled upon the Guava RateLimiter. From what I can tell the two main ways it handles throttling are either by queueing the overlowing requests (the .acquire(...) methods) or by discarding them (the tryAcquire(...) methods)

I was thinking that there would be an option that would allow requests up to the specified amount and only after reaching said limit queue or discard requests.

For instance:

public static void main( String[] args )
{
    try
    {
        RateLimiter limiter = RateLimiter.create(5.0 );
        //fictive call not saying it should be implemented this way
        limiter.allowBursts(true);
        for( int i = 0; i < 20; i++ )
        {
            Thread.sleep( 100 );
            performOperation( limiter );
        }
    }
    catch( InterruptedException e )
    {
        e.printStackTrace();
    }
}

private static void performOperation( RateLimiter limiter )
{
    if( limiter.tryAcquire() )
    {
        System.out.println( Instant.now() + ": Beep" );
    }
}

This would then print out five beeps, omit the next five and then print five again

Am I the only one thinking this would be a usefull feature to have or am I missing the point?

Test code courtesy of: Throttling method calls using Guava RateLimiter class

Answer 1

This would then print out five beeps, omit the next five and then print five again

Adding a fixed size queue won't really make it work this way.

You are supplying the input beeps at a fixed rate of 10 per second, so adding an input queue of 5 will just amortize an initial 10 beeps, and then it will start skipping every other beep, like that:

1
2
3
4
5
6
7
8
9
10
12
14
16
18
20

and this (apart those first elements) is no different from what a raw RateLimiter will do already:

1
3
5
7
9
11
13
15
17
19

Moreover adding a queue to the RateLimiter would require it to start accepting asynchronous tasks, which does not really sound like a natural RateLimiter responsibility, so it will probably make a bad design.