Getting a non-singleton rate limiter in resilience4j

nonSingletonRateLimiterResilience4j.java

// Getting a non-singleton rate limiter in resilience4j
// This effectively creates as many rate limiters as wanted
// For example, rate limiter instance owned by each thread vs a global rate limiter for the whole application 
// can be achieved through the following for a Spring Boot application

Optional<RateLimiterConfig> config = rateLimiterRegistry.getConfiguration("extendLock"); // Configuration retrieved from application.yml in Spring Boot
rateLimiter = RateLimiter.of("uniqueNameDoesNotMatter", config.orElseThrow()); // This calls new AtomicRateLimiter under the hood so name doesn't have to be unique. This bypasses the singleton



// Retry in resilience4j is non singleton because all execution methods create a new Retry.Context object under the hood
// For example, the following:
static Runnable decorateRunnable(Retry retry, Runnable runnable) {
  return () -> {
    Retry.Context context = retry.context();

    while(true) {
      try {
        runnable.run();
        context.onComplete();
        return;
      } catch (RuntimeException var4) {
        context.onRuntimeError(var4);
      }
    }
  };
}