Skip to content

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

Merged
merged 2 commits into from
Mar 6, 2019

Conversation

artembilan
Copy link
Member

Copy link
Contributor

@garyrussell garyrussell left a 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);
Copy link
Contributor

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,.

Copy link
Member Author

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...

Copy link
Member Author

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;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unused field.

Copy link
Member Author

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.

@garyrussell garyrussell merged commit e921628 into spring-projects:master Mar 6, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants