Use named configuration with `@RateLimiter` annotation
See original GitHub issueResilience4j version: 1.2.0 Java version: 11.0.5
Problem description:
There is no way to pragmatically customize rate limiter applied with @RateLimiter
annotation.
I tried:
@Configuration
class RateLimiterConfiguration {
@Bean
public RateLimiterRegistry rateLimiterRegistry() {
RateLimiterConfig defaultConfiguration = RateLimiterConfig.custom()
// set some parameters
.build();
RateLimiterConfig customConfiguration = RateLimiterConfig.custom()
// set some parameters
.build();
RateLimiterRegistry registry = RateLimiterRegistry.of(defaultConfiguration);
registry.addConfiguration("custom", customConfiguration);
// tried...
// registry.replace("custom", RateLimiter.of("custom", customConfiguration));
return registry;
}
}
@Component
class RateLimitedComponent {
@RateLimiter(name = "custom")
public void limitMe() {
}
}
but because of this code: https://github.com/resilience4j/resilience4j/blob/6d2f870e6bcb4a09d346b9888adf25dd8a09b9f8/resilience4j-spring/src/main/java/io/github/resilience4j/ratelimiter/configure/RateLimiterAspect.java#L109-L110
there is no way to customize RateLimiter in code (I know, it is still possible with properties).
What is your opinion on:
- Add parameter to
@RateLimiter
annotation -configurationName
and use it to retrieveRateLimiter
instance or - Use
name
from@RateLimiter
annotation and pass it toRateLimiterRegistry
as configuration name ingetOrCreateRateLimiter
:
rateLimiterRegistry
.rateLimiter(name, name);
Some additional logic is needed because missing configuration will throw: https://github.com/resilience4j/resilience4j/blob/6d2f870e6bcb4a09d346b9888adf25dd8a09b9f8/resilience4j-ratelimiter/src/main/java/io/github/resilience4j/ratelimiter/internal/InMemoryRateLimiterRegistry.java#L200-L204
Issue Analytics
- State:
- Created 4 years ago
- Comments:11 (7 by maintainers)
Top GitHub Comments
@Romeh Thanks for the idea.
According to comment https://github.com/resilience4j/resilience4j/pull/784#issuecomment-571832388
*Customizers
will be used instead so I am closing this issue.@brempusz
Just small question , why we not just do the following which will allow to replace the configuration after spring context is initiated ?