Implement thread-local scope for rate limiters and improve spec format #1928
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR implements an optional scope specifier on rate limiters which can control whether a rate limiter is applied across all combined operations of an activity, or alternately, instanced per-thread using ThreadLocal.
Updates to thread-scoped rate limiters are not supported yet, but this can be added by adding event propagation for those configuration events into the component tree's event routing.
Each rate limiter is a full implementation as before, which includes a fully-separate instance of a semaphore and a tasking thread to keep filling the token bucket. As such, many such per-thread rate limiters will consume incrementally more resources, so running thousands of them is not advised.
The session logs below will explain the behavior and formats that need to be documented.
10 threads running at 1 op/s each
(each because of scope
thread
)1 thread running at 10 ops/s
5 threads running at 5 ops/s each
(each because of scope
thread
)5 threads running at 5 ops/s aggregate (default behavior)
(aggregate because of scope
activity
)error message for incorrect rate spec