Resilience4j RateLimiter 似乎忽略了配置

Question

我对 Resilience4j RateLimiter 有疑问

public static void main(final String[] args) throws InterruptedException {
    final ExternalService service = new ExternalService();
    final ExecutorService executorService = Executors.newFixedThreadPool(30);

    final RateLimiterConfig config = RateLimiterConfig.custom()
        .limitRefreshPeriod(Duration.ofSeconds(10))
        .limitForPeriod(3)
        .timeoutDuration(Duration.ofSeconds(12))
        .build();

    final RateLimiter rateLimiter = RateLimiter.of("RateLimiter", config);

    final Callable<Response<String>> callable = RateLimiter.decorateCallable(
        rateLimiter, () -> service.get(200, "OK")
    );

    executorService.submit(callable); //fine in first period
    executorService.submit(callable); //fine in first period
    executorService.submit(callable); //fine in first period
    executorService.submit(callable); //should wait 10 sec and fine in second period
    executorService.submit(callable); //should wait 10 sec and fine in second period
    executorService.submit(callable); //should wait 10 sec and fine in second period
    executorService.submit(callable); //should exit with timeout after 12 seconds
    executorService.submit(callable); //should exit with timeout after 12 seconds
    executorService.submit(callable); //should exit with timeout after 12 seconds


    Thread.sleep(Duration.ofSeconds(40).toMillis());
    executorService.shutdown();
}

在ExternalService 中，我有一些带有localTime 响应的基本日志记录。我认为它应该像我在 cmets 中解释的那样工作，但我的回应是：

> Task :Main.main()
[12:24:53.5] Return standard response
[12:24:53.5] Return standard response
[12:24:53.5] Return standard response
[12:25:03.5] Return standard response
[12:25:03.5] Return standard response
[12:25:03.5] Return standard response
[12:25:03.5] Return standard response
[12:25:03.5] Return standard response

BUILD SUCCESSFUL in 40s

所以看起来第一个循环很好，但是之后，RateLimiter 允许五个下一个线程，并且永远不会调用最后一个线程。

Answer 1

不幸的是，这是一个在 PR #672 中引入的错误，它是 v1.2.0 版本的一部分。 PR 增加了每次调用请求多个许可的可能性。该错误现已修复。