Class TrafficResilienceHttpServiceFilter

java.lang.Object
io.servicetalk.traffic.resilience.http.TrafficResilienceHttpServiceFilter
All Implemented Interfaces:
HttpExecutionStrategyInfluencer, StreamingHttpServiceFilterFactory, ExecutionStrategyInfluencer<HttpExecutionStrategy>

public final class TrafficResilienceHttpServiceFilter extends Object implements StreamingHttpServiceFilterFactory
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.