-
Notifications
You must be signed in to change notification settings - Fork 1.1k
INT-4497: Add RateLimiterRequestHandlerAdvice #2781
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A couple of issues only.
@Override | ||
protected Object doInvoke(ExecutionCallback callback, Object target, Message<?> message) throws Exception { | ||
CheckedFunction0<Object> restrictedCall = | ||
RateLimiter.decorateCheckedSupplier(this.rateLimiter, callback::execute); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if we could refactor the ARHA to to avoid creating this object on every call?
We could provide the subclass with an alternative method, something like...
@Override
Object doInvoke(Invocation invocation) {
myInvoke(invocation);
}
And then only decorate myInvoke()
once during initialization,.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought about that, but then it looks like we can use the same advice instance for different endpoints, so, the target
and callback
are going to be fully different from context to context.
Need to sleep with this more, since an internal logic of the advice is shared as well...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm. Looks like we fully depend on the invocation.proceed()
which is context-based against a method and actual arguments to call. So, there is no way to decorate only once during initialization. The real call must be decorated any way.
I might miss something, so feel free to share more your thoughts!
|
||
private final RateLimiter rateLimiter; | ||
|
||
private ApplicationEventPublisher applicationEventPublisher; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unused field.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah... I was thought to propagate RateLimiter
event to Spring events, but then I realized that their API allows only to have one event consumer, so it is going to be some kind of abuse to mutate externally provided RateLimiter
.
Om the other hand their even doesn't bring too much info to be propagated with our own events.
On the other hand we are good to live without them with just call we have here.
Plus that's not too hard to propagate those events by yourself configuring RateLimiter
externally as a bean.
JIRA: https://jira.spring.io/browse/INT-4497