Package io.servicetalk.traffic.resilience.http

Class TrafficResilienceHttpClientFilter

java.lang.Object
io.servicetalk.traffic.resilience.http.TrafficResilienceHttpClientFilter
All Implemented Interfaces:
HttpExecutionStrategyInfluencer, StreamingHttpClientFilterFactory, ExecutionStrategyInfluencer<HttpExecutionStrategy>
public final class TrafficResilienceHttpClientFilter extends Object implements StreamingHttpClientFilterFactory
A StreamingHttpClientFilterFactory to enforce capacity and circuit-breaking control for a client. Requests that are not able to acquire a capacity ticket or a circuit 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.
  • The traffic control filter should not be offloaded if possible to avoid situations where continuous traffic overflows the offloading subsystem.
  • The traffic control filter should be ordered after a io.servicetalk.http.netty.RetryingHttpRequesterFilter if one is used, to avail the benefit of retrying requests that failed due to (local or remote) capacity issues. RetryableRequestDroppedException are safely retry-able errors, since they occur on the outgoing side before they even touch the network. DelayedRetryRequestDroppedException errors on the other side, are remote rejections, and its up to the application logic to opt-in for them to be retryable, by configuring the relevant predicate of the io.servicetalk.http.netty.RetryingHttpRequesterFilter
  • The traffic control filter should be ordered after a io.servicetalk.http.netty.RetryingHttpRequesterFilter to allow an already acquired permit to be released in case of other errors/timeouts of the operation, before retrying to re-acquire a permit. Otherwise, a permit may be held idle for as long as the operation is awaiting to be re-tried, thus, mis-utilising available resources for other requests through the same client.
  • 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. The default terminal callback for the ticket in that case, is set to dropped 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 TrafficResilienceHttpClientFilter.Builder.onErrorTicketTerminal(BiConsumer).