-
Notifications
You must be signed in to change notification settings - Fork 220
Investigate if all state associated with a given resource could be managed in a single spot #1314
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
Comments
Now this would help probably just with the cleanup. Also in the background we won't use 3 HashMaps just 1.
Yes, this would mean rate limiter needs a spefic api for execution state, separated, what is not nice, since this does not fit well to the rate limiter API. Something similar would hold for event marker. That is not exposed, so would not be such an issue. |
Candidate states to be unified: retry, event marker, rate limiting…
The most likely spot would be
EventProcessor
.Pros:
EventProcessor
knows when the state needs to be modified / cleaned-upCons:
The text was updated successfully, but these errors were encountered: