Configure that requests are to be treated as idempotent.
Configure that requests are to be treated as idempotent. Because requests can be safely
retried, BackupRequestFilter is configured with the params maxExtraLoad
and
sendInterrupts
to decrease tail latency by sending an additional fraction of requests.
If you are using TwitterServer, a good starting point for determining a value for
maxExtraLoad
is looking at the details of the PDF histogram for request latency,
at /admin/histograms. If you choose a maxExtraLoad
of 1.percent, for example, you can expect
your p999/p9999 latencies to (roughly) now be that of your p99 latency. For 5.percent, those
latencies would shift to your p95 latency. You should also ensure that your backend can
tolerate the increased load.
How much extra load, as a Tunable fraction, we are willing to send to the server. Must be between 0.0 and 1.0.
Whether or not to interrupt the original or backup request when a response is returned and the result of the outstanding request is superseded. For protocols without a control plane, where the connection is cut on interrupts, this should be "false" to avoid connection churn.
ResponseClassifier (combined (via ResponseClassifier.orElse) with any existing classifier in the stack params), used for determining whether or not requests have succeeded and should be retried. These determinations are also reflected in stats, and used by FailureAccrualFactory.
Configure that requests are to be treated as idempotent.
Configure that requests are to be treated as idempotent. Because requests can be safely
retried, BackupRequestFilter is configured with the params maxExtraLoad
and
sendInterrupts
to decrease tail latency by sending an additional fraction of requests.
How much extra load, as a fraction, we are willing to send to the server. Must be between 0.0 and 1.0.
Whether or not to interrupt the original or backup request when a response is returned and the result of the outstanding request is superseded. For protocols without a control plane, where the connection is cut on interrupts, this should be "false" to avoid connection churn.
ResponseClassifier (combined (via ResponseClassifier.orElse) with any existing classifier in the stack params), used for determining whether or not requests have succeeded and should be retried. These determinations are also reflected in stats, and used by FailureAccrualFactory.
See idempotent
below for a version that takes a Tunable[Double] for maxExtraLoad
.
Create a Service from the current configuration.
Create a Service from the current configuration.
Create a ServicePerEndpoint from the current configuration.
Create a ServicePerEndpoint from the current configuration.
Configure that requests are to be treated as non-idempotent.
Configure that requests are to be treated as non-idempotent. BackupRequestFilter is disabled, and only those failures that are known to be safe to retry (i.e., write failures, where the request was never sent) are retried via requeue filter; any previously configured retries are removed.
Returns the client stack parameters.
Configure the application-level retry policy.
Configure the application-level retry policy.
Defaults to using the client's com.twitter.finagle.service.ResponseClassifier to retry failures marked as retryable.
The classifier is also used to determine the logical success metrics of the client. Logical here means after any retries are run. For example should a request result in retryable failure on the first attempt, but succeed upon retry, this is exposed through metrics as a success.
Retrying on Exception
responses:
import com.twitter.finagle.client.MethodBuilder import com.twitter.finagle.service.{ReqRep, ResponseClass} import com.twitter.util.Throw val builder: MethodBuilder[Int, Int] = ??? builder.withRetry.forClassifier { case ReqRep(_, Throw(_)) => ResponseClass.RetryableFailure }
MethodBuilderRetry
Configure the timeouts.
Configure the timeouts.
The per-request timeout defaults to using the client's configuration for com.twitter.finagle.service.TimeoutFilter.Param(timeout), which is typically set via com.twitter.finagle.param.CommonParams.withRequestTimeout.
The total timeout defaults to using the client's configuration for com.twitter.finagle.service.TimeoutFilter.TotalTimeout(timeout).
A per-request timeout of 50 milliseconds:
import com.twitter.conversions.DurationOps._ import com.twitter.finagle.client.MethodBuilder val builder: MethodBuilder[Int, Int] = ??? builder.withTimeout.perRequest(50.milliseconds)
A total timeout of 200 milliseconds:
import com.twitter.conversions.DurationOps._ import com.twitter.finagle.client.MethodBuilder val builder: MethodBuilder[Int, Int] = ??? builder.withTimeout.total(200.milliseconds)
MethodBuilderTimeout
Allow customizations for protocol-specific trace initialization.
user guide
methodBuilder
methods on client protocols, such asHttp.Client
orThriftMux.Client
for an entry point.