Skip to content

refactor: manage state associated with a resource in a single spot #1319

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 3 commits into from
Jul 11, 2022

Conversation

metacosm
Copy link
Collaborator

@metacosm metacosm commented Jul 7, 2022

This is a preliminary exploration to address #1314.

Thinking about this some more, this has additional advantages:

  • we could pass the state along once it's initially retrieve to the EventProcessor methods instead of retrieving it all the time from the ResourceID
  • this might allow to remove some synchronisation needs because the full state needed for processing would be passed around
  • if we think it's a good idea, it probably is better to do it now because of the impact it has on the RateLimiter interface

@metacosm metacosm self-assigned this Jul 7, 2022
@metacosm metacosm requested a review from csviri July 7, 2022 10:00
@metacosm metacosm marked this pull request as ready for review July 8, 2022 10:33

public interface RateLimiter {
public interface RateLimiter<S extends RateLimitState> {
interface RateLimitState {
Copy link
Collaborator

Choose a reason for hiding this comment

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

Can't this be just an Object? Do we need an explicit interface for this.
I mean just use RateLimiter<S>

Copy link
Collaborator

Choose a reason for hiding this comment

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

Otherwise LGTM

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Yeah, not sure either… Was thinking that perhaps we needed some some of marker interface to be able to trace where this state is used more easily than tracking Object… Will review.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I think we should keep it this way so that it's more obvious what the associated state is for, even though technically Object would work just as well.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Can't remember where but we had the same situation, where we decided to go with the object and don't use marker interfaces.
So I lean more to remove it, but I'm fine having that if you think it has benefits.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

It also has the advantage of having an interface already in case we need to somehow restrict what can be used…

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

@@ -36,11 +30,12 @@ public PeriodRateLimiter(Duration refreshPeriod, int limitForPeriod) {
}

@Override
public Optional<Duration> acquirePermission(ResourceID resourceID) {
if (limitForPeriod <= 0) {
public Optional<Duration> isLimited(RateLimitState rateLimitState) {
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

This is essentially where having a marker interface helps for documentation purposes as the alternative would be: isLimited(Object state) which wouldn't be as explicit. It's not a big deal but I think it's nicer this way.

@sonarqubecloud
Copy link

Kudos, SonarCloud Quality Gate passed!    Quality Gate passed

Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities
Security Hotspot A 0 Security Hotspots
Code Smell A 73 Code Smells

68.8% 68.8% Coverage
0.3% 0.3% Duplication

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