A
StreamingHttpServiceFilterFactory to enforce capacity control for a server.
Requests that are not able to acquire a
permit, will fail with a
RequestDroppedException.
Ordering of filters
Ordering of the
capacity-filter is important for various reasons:
- The traffic control filter should be as early as possible in the execution chain to offer a fast-fail
reaction and ideally trigger a natural back-pressure mechanism with the transport. It's recommended to
not offload this filter by using
the
HttpServerBuilder.appendNonOffloadingServiceFilter(StreamingHttpServiceFilterFactory) variant
when appending to the service builder. Therefore, it's expected that any function provided through
the TrafficResilienceHttpServiceFilter.Builder, should not block, to avoid any impact on the I/O threads. since this
filter will not be offloaded.
- The traffic control filter should not be offloaded if possible to avoid situations where
continuous traffic overflows the offloading subsystem.
- If the traffic control filter is ordered after a
timeout-filter then a potential timeout will be
delivered to it in the form of a cancellation, in which case you may want to override the default
terminal event of the ticket, to drop it
to avail for local throttling, since a timeout is a good indicator that a sub-process in the pipeline is not
completing fast enough.
- If the traffic control filter is ordered before a
timeout-filter then a potential timeout will be
delivered to it in the form of a TimeoutException, which is in turn triggers the
drop-event of the ticket by default. Behavior can be overridden through this
callback.