service
A com.twitter.finagle.Service that returns a constant result.
A com.twitter.finagle.Filter that rejects requests when their deadline has passed.
A com.twitter.finagle.Filter that rejects requests when their deadline has passed.
The user guide for more details.
A factory that won't satisfy the service future until an underlying service factory is ready.
A factory that won't satisfy the service future until an underlying service factory is ready.
close closes the underlying service factory, which means that it won't be
satisfied until after the underlying future has been satisfied.
Implicitly masks the underlying future from interrupts. Promises are detached on interruption.
A service wrapper that expires the self service after a
certain amount of idle time.
A service wrapper that expires the self service after a
certain amount of idle time. By default, expiring calls
close() on the self channel, but this action is
customizable.
The user guide for more details.
A com.twitter.finagle.Service that fails with a constant Throwable.
A com.twitter.finagle.ServiceFactory that fails to construct services.
Strategy responsible for tracking requests and computing rate per client.
A com.twitter.finagle.Filter that uses an argument function to predicate whether or not to apply the subsequent com.twitter.finagle.Service.
A com.twitter.finagle.Filter that uses an argument function to predicate whether or not to apply the subsequent com.twitter.finagle.Service. In cases where the function returns false, a the filter fails with a com.twitter.finagle.NotServableException.
A com.twitter.finagle.Filter that accepts or refuses requests based on a rate limiting strategy.
Represents a request/response pair.
Represents a request/response pair.
For some protocols, like HTTP, these types are what you'd expect —
com.twitter.finagle.http.Request and com.twitter.finagle.http.Response.
While for other protocols that may not be the case. Please review
the protocol's
"com.twitter.finagle.$protocol.service.$ProtocolResponseClassifier"
for details.
com.twitter.finagle.thriftmux.service.ThriftMuxResponseClassifier
com.twitter.finagle.http.service.HttpResponseClassifier
A classification of the result of a request/response pair.
A classification of the result of a request/response pair.
Used by response classification
to indicate synthetic failures that are not Exceptions.
Used by response classification
to indicate synthetic failures that are not Exceptions.
The FAQ for more details.
A response classifier allows developers to give Finagle the additional application specific knowledge necessary in order to properly classify them.
A response classifier allows developers to give Finagle the additional application specific knowledge necessary in order to properly classify them. Without this, Finagle can only safely make judgements about transport level failures.
As an example take an HTTP client that receives a response with a 500 status code back from a server. To Finagle this is a successful request/response based solely on the transport level. The application developer may want to treat all 500 status codes as failures and can do so via a com.twitter.finagle.service.ResponseClassifier.
It is a PartialFunction from a request/response pair to a ResponseClass and as such multiple classifiers can be composed together via PartialFunction.orElse.
it is a good practice for users of ResponseClassifier.apply to
instead use theClassifier.applyOrElse(input, ResponseClassifier.Default)
in order to ensure that the PartialFunction will be fully covering.
Finagle's default classifier is com.twitter.finagle.service.ResponseClassifier.Default which is a total function fully covering the input domain.
,Java does not understand the type alias and must be used as
PartialFunction in Java.
com.twitter.finagle.http.service.HttpResponseClassifier for some
HTTP classification tools.
Represents a budget for retrying requests.
Represents a budget for retrying requests.
A retry budget is useful for attenuating the amplifying effects of many clients within a process retrying requests multiple times. This acts as a form of coordination between those retries.
Implementations must be thread-safe.
RetryBudget.apply for creating instances.
A com.twitter.finagle.Filter that coordinates retries of subsequent Services.
A com.twitter.finagle.Filter that coordinates retries of subsequent Services. Exceptional responses can can be classified as retryable via the retryPolicy argument com.twitter.finagle.service.RetryPolicy.
consider using a Timer with high resolution so that there is less correlation between retries. For example HighResTimer.Default.
RetryFilter for a version that allows for retries on "successful" responses as well as failures.
A com.twitter.finagle.Filter that coordinates retries of subsequent Services.
A com.twitter.finagle.Filter that coordinates retries of subsequent Services. Successful and exceptional responses can be classified as retryable via the retryPolicy com.twitter.finagle.service.RetryPolicy argument.
consider using a Timer with high resolution so that there is less correlation between retries. For example HighResTimer.Default.
The user guide for more details.
A function defining retry behavior for a given value type A.
A function defining retry behavior for a given value type A.
The Function1 returns None if no more retries should be made
and Some if another retry should happen. The returned Some has
a Duration field for how long to wait for the next retry as well
as the next RetryPolicy to use.
Finagle will handle retryable Throws automatically but you will need to supply a custom ResponseClassifier to inform Finagle which application level exceptions are retryable.
SimpleRetryPolicy for a Java friendly API.
ShardingService takes a Distributor where the handle is a service.
ShardingService takes a Distributor where the handle is a service.
It uses the distributor to distribute requests *only* when the hash function returns Some[Long].
If None is returned, it throws NotShardableException.
If the underlying service for a particular shard is not available, NotServableException is thrown.
Example:
val serviceFactory =
KetamaShardingServiceBuilder()
.nodes(services) // services is of type Seq[(String, Service[Req,Rep])]
.withHash { req => Some(hashCodeOfSomething)}
.buildFactory()
val service = serviceFactory()
service(req) // where req is a Req and may have ShardableRequest mixed in
A retry policy abstract class.
A retry policy abstract class. This is convenient to use for Java programmers. Simply implement
the two abstract methods shouldRetry and backoffAt and you're good to go!
A com.twitter.finagle.ServiceFactory that produces
Services identical to the argument service.
A com.twitter.finagle.ServiceFactory that produces
Services identical to the argument service.
Note that this factory builds new Services,
so the "singleton" service argument is not shared by reference. This
differs from com.twitter.finagle.ServiceFactory#const in that const
proxies all requests to the same service rather than creating new objects.
A StatsFilter reports request statistics including number of requests,
number successful and request latency to the given StatsReceiver.
A StatsFilter reports request statistics including number of requests,
number successful and request latency to the given StatsReceiver.
The innocent bystander may find the semantics with respect to backup requests a bit puzzling; they are entangled in legacy. "requests" counts the total number of requests: subtracting "success" from this produces the failure count. However, this doesn't allow for "shadow" requests to be accounted for in "requests". This is why we don't modify metrics for backup request failures.
A com.twitter.finagle.Filter that applies a timeout to requests.
A com.twitter.finagle.Filter that applies a timeout to requests.
If the response is not satisfied within the timeout,
the Future will be interrupted via Future.raise.
Implements various backoff strategies.
Implements various backoff strategies.
Strategies are defined by a Stream[Duration] and are intended for use with
RetryFilter.apply and RetryPolicy.backoff to determine the duration after which a request
is to be retried.
All backoffs created by factory methods on this object are infinite. Use Stream.take to
make them terminate.
DeadlineFilter provides an admission control module that can be pushed onto the stack to reject requests with expired deadlines (deadlines are set in the TimeoutFilter).
DeadlineFilter provides an admission control module that can be pushed onto the stack to reject requests with expired deadlines (deadlines are set in the TimeoutFilter). For servers, DeadlineFilter.module should be pushed onto the stack before the stats filters so stats are recorded for the request, and pushed after TimeoutFilter where a new Deadline is set. For clients, DeadlineFilter.module should be pushed before the stats filters; higher in the stack is preferable so requests are rejected as early as possible.
Deadlines cross process boundaries and can span multiple nodes in a call graph. Even if a direct caller doesn't set a deadline, the server may still receive one and thus potentially fail the request. It is advised that all clients in the call graph be well prepared to handle NACKs before using this.
A static FailedService object.
A module which allows clients to limit the number of pending requests per connection.
A module which allows clients to limit the number of pending requests per connection.
The effects of this filter are reflected in the stat "dispatcher/.../pending", which is a sum over per-host connections of dispatched requests between client and server. If the limit is configured as L and there are N per-host connections, "dispatcher/.../pending" will be no greater than L * N.
Note that the "pending" stat recorded in c.t.f.StatsFilter can be greater than L * N because requests can be between c.t.f.StatsFilter and c.t.f.PendingRequestFilter when the stat is read.
The user guide for more details.
The Stack parameters and modules for configuring which and how many failed requests are retried for a client.
The Stack parameters and modules for configuring which and how many failed requests are retried for a client.
The user guide for more details.
See RetryBudgets for Java APIs.