-
Notifications
You must be signed in to change notification settings - Fork 321
Expose configured backlog timeout in LifoBlockingLimiter #223
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
base: main
Are you sure you want to change the base?
Conversation
| */ | ||
| public Builder<ContextT> backlogTimeoutMillis(long timeout) { | ||
| this.maxBacklogTimeoutMillis = context -> timeout; | ||
| this.configuredBacklogTimeoutMillis = timeout; |
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.
If a function is set through backlogTimeout, should we clear the configuredBacklogTimeoutMillis?
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.
That’s a great suggestion. For cleanup purposes, we probably should. If we switch to a dynamic function, there’s no single fixed timeout anymore, so configuredBacklogTimeoutMillis could be cleared. I’m going to make configuredBacklogTimeoutMillis a boxed value so we can clear it by assigning null.
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.
Fixed
| private final Limiter<ContextT> delegate; | ||
| private int maxBacklogSize = 100; | ||
| private Function<ContextT, Long> maxBacklogTimeoutMillis = context -> 1_000L; | ||
| private long configuredBacklogTimeoutMillis = 1_000L; |
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.
Nit: is the goal to track the configured timeout or to quickly identify the value of any fixed timeout? If the latter, fixedBacklogTimeoutMillis would be a better name.
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.
The goal is to expose the value only when a fixed timeout is configured, not to track historical configuration. fixedBacklogTimeoutMillis is indeed a more accurate name. I’ll update the field and getter accordingly.
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.
Fixed
| public long getConfiguredBacklogTimeoutMillis() { | ||
| return this.configuredBacklogTimeoutMillis; | ||
| } | ||
|
|
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 believe that we also need to add a similar accessor to BlockingLimiter.
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.
Should we? I dont think we use BlockingLimiter internally and it feels to it is a different kind of limiter(pls correct me if I am wrong). maxBacklogSize is not exposed into BlockingLimiter either.
I feel like my change is solving a very specific problem: expose configured backlog timeout in LifoBlockingLimiter
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.
Fixed
fff42fb to
5a198dc
Compare
5a198dc to
09a3971
Compare
Adds a simple getter,
getFixedBacklogTimeoutMillis(), toLifoBlockingLimiterso the fixed backlog timeout configured via the builder can be inspected and serialized.This does not change limiter behavior; it only exposes existing configuration for introspection and tooling.