A copy constructor in lieu of defining StackServer as a case class.
A copy constructor in lieu of defining StackServer as a case class.
Create a new instance of a PushListener which will be used to accept connections
Create a new instance of a PushListener which will be used to accept connections
Make a new PushSession with the provided PushChannelHandle and Service
Make a new PushSession with the provided PushChannelHandle and Service
It is possible that the new session will receive a handle that has already been closed, and must free its resources under such circumstances.
,it is presumed that the new session will take ownership of both the handle and the service and it is the sessions job to release these resources.
The current parameter map used in this StackServer.
The current parameter map used in this StackServer.
The current stack used in this StackServer.
The current stack used in this StackServer.
Export info about the listener type to the global registry.
Export info about the listener type to the global registry.
The information about its implementation can then be queried at runtime.
Creates a new StackServer with parameter psp._1
and Stack Param type psp._2
.
Creates a new StackServer with parameter psp._1
and Stack Param type psp._2
.
Creates a new StackServer with parameter p
.
Creates a new StackServer with parameter p
.
Creates a new StackServer with additional parameters newParams
.
Creates a new StackServer with additional parameters newParams
.
Constructs a new ListeningServer
from the ServiceFactory
.
Constructs a new ListeningServer
from the ServiceFactory
.
Each new session is passed to the trackSession
function exactly once
to facilitate connection resource management.
Serve service
at addr
Serve service
at addr
Serve service
at addr
Serve service
at addr
Serve service
at addr
Serve service
at addr
Serve service
at addr
Serve service
at addr
Serve service
at addr
and announce with name
.
Serve service
at addr
and announce with name
. Announcements will be removed
when the service is closed. Omitting the addr
will bind to an ephemeral port.
Serve service
at addr
and announce with name
.
Serve service
at addr
and announce with name
. Announcements will be removed
when the service is closed. Omitting the addr
will bind to an ephemeral port.
Serve service
at addr
and announce with name
.
Serve service
at addr
and announce with name
. Announcements will be removed
when the service is closed. Omitting the addr
will bind to an ephemeral port.
Serve service
at addr
and announce with name
.
Serve service
at addr
and announce with name
. Announcements will be removed
when the service is closed. Omitting the addr
will bind to an ephemeral port.
Serve service
at addr
and announce with name
.
Serve service
at addr
and announce with name
. Announcements will be removed
when the service is closed. Omitting the addr
will bind to an ephemeral port.
Serve service
at addr
and announce with name
.
Serve service
at addr
and announce with name
. Announcements will be removed
when the service is closed. Omitting the addr
will bind to an ephemeral port.
An entry point for configuring the servers' admission control.
An entry point for configuring the servers' admission control.
Configures this server or client with given exception stats handler.
Configures this server or client with given exception stats handler.
Configures this server or client to shift user-defined computation (com.twitter.util.Future callbacks and transformations) off of IO threads into a given ExecutorService.
Configures this server or client to shift user-defined computation (com.twitter.util.Future callbacks and transformations) off of IO threads into a given ExecutorService.
By default, Finagle executes all futures in the IO threads, minimizing context switches. Given there is usually a fixed number of IO threads shared across a JVM process, it's critically important to ensure they aren't being blocked by the application code, affecting system's responsiveness. Shifting application-level work onto a dedicated FuturePool or ExecutorService offloads IO threads, which may improve throughput in CPU-bound systems.
As always, run your own tests before enabling this feature.
Configures this server or client to shift user-defined computation (com.twitter.util.Future callbacks and transformations) off of IO threads into a given FuturePool.
Configures this server or client to shift user-defined computation (com.twitter.util.Future callbacks and transformations) off of IO threads into a given FuturePool.
By default, Finagle executes all futures in the IO threads, minimizing context switches. Given there is usually a fixed number of IO threads shared across a JVM process, it's critically important to ensure they aren't being blocked by the application code, affecting system's responsiveness. Shifting application-level work onto a dedicated FuturePool or ExecutorService offloads IO threads, which may improve throughput in CPU-bound systems.
As always, run your own tests before enabling this feature.
Configures this server or client with given label
(default: empty string).
Configures this server or client with given label
(default: empty string).
The label
value is used for stats reporting to scope stats reported
from different clients/servers to a single stats receiver.
Configures this server or client with given util.Monitor (default: com.twitter.finagle.util.DefaultMonitor).
Configures this server or client with given util.Monitor (default: com.twitter.finagle.util.DefaultMonitor).
Monitors are Finagle's out-of-band exception reporters. Whenever an exception is thrown on a request path, it's reported to the monitor. The default monitor implementation, com.twitter.finagle.util.DefaultMonitor, logs these exceptions.
Monitors are wired into the server or client stacks via com.twitter.finagle.filter.MonitorFilter and are appl are applied to the following kinds of exceptions:
Service.apply(request)
Service.apply(request)
respond
, onSuccess
, onFailure
future callbacksmap
, flatMap
, transform
future continuationsPut it this way, we apply Monitor.handle
to an exception if we would otherwise "lose" it,
i.e. when it's not connected to the Future
, nor is it connected to the call stack.
You can compose multiple monitors if you want to extend or override the standard behavior,
defined in DefaultMonitor
.
import com.twitter.util.Monitor val consoleMonitor = new Monitor { def handle(exc: Throwable): Boolean = { Console.err.println(exc.toString) false // continue handling with the next monitor (usually DefaultMonitor) } } $.withMonitor(consoleMonitor)
Returning true
form within a monitor effectively terminates the monitor chain so no
exceptions are propagated down to the next monitor.
Creates a new StackServer with params
used to configure this StackServer's stack
.
Creates a new StackServer with params
used to configure this StackServer's stack
.
Configures the Tunable request timeout
of this server or client (if applying the
Tunable produces a value of None
, an unbounded timeout is used for the request).
Configures the Tunable request timeout
of this server or client (if applying the
Tunable produces a value of None
, an unbounded timeout is used for the request).
If the request has not completed within the Duration resulting from timeout.apply()
,
the pending work will be interrupted via com.twitter.util.Future.raise.
The client request timeout is the maximum amount of time given to a single request (if there are retries, they each get a fresh request timeout). The timeout is applied only after a connection has been acquired. That is: it is applied to the interval between the dispatch of the request and the receipt of the response.
The server request timeout is the maximum amount of time, a server is allowed to spend handling the incoming request. Using the Finagle terminology, this is an amount of time after which a non-satisfied future returned from the user-defined service times out.
Configures the request timeout
of this server or client (default: unbounded).
Configures the request timeout
of this server or client (default: unbounded).
If the request has not completed within the given timeout
, the pending
work will be interrupted via com.twitter.util.Future.raise.
The client request timeout is the maximum amount of time given to a single request (if there are retries, they each get a fresh request timeout). The timeout is applied only after a connection has been acquired. That is: it is applied to the interval between the dispatch of the request and the receipt of the response.
The server request timeout is the maximum amount of time, a server is allowed to spend handling the incoming request. Using the Finagle terminology, this is an amount of time after which a non-satisfied future returned from the user-defined service times out.
https://twitter.github.io/finagle/guide/Clients.html#timeouts-expiration
Configure a com.twitter.finagle.service.ResponseClassifier which is used to determine the result of a request/response.
Configure a com.twitter.finagle.service.ResponseClassifier which is used to determine the result of a request/response.
This allows developers to give Finagle the additional application-specific knowledge necessary in order to properly classify responses. Without this, Finagle cannot make judgements about application-level failures as it only has a narrow understanding of failures (for example: transport level, timeouts, and nacks).
As an example take an HTTP server that returns a response with a 500 status code. To Finagle this is a successful request/response. However, the application developer may want to treat all 500 status codes as failures and can do so via setting a com.twitter.finagle.service.ResponseClassifier.
ResponseClassifier is a PartialFunction and as such multiple classifiers can be composed together via PartialFunction.orElse.
Response classification is independently configured on the client and server.
For client-side response classification using com.twitter.finagle.builder.ClientBuilder,
see com.twitter.finagle.builder.ClientBuilder.responseClassifier
If unspecified, the default classifier is com.twitter.finagle.service.ResponseClassifier.Default which is a total function fully covering the input domain.
com.twitter.finagle.http.service.HttpResponseClassifier
for some
HTTP classification tools.
An entry point for configuring the client's sessions.
An entry point for configuring the client's sessions.
Session might be viewed as logical connection that wraps a physical connection (i.e., transport) and controls its lifecycle. Sessions are used in Finagle to maintain liveness, requests cancellation, draining, and many more.
The default setup for a Finagle server's sessions is to not put any timeouts on it.
A new StackServer using the function to create a new Stack.
A new StackServer using the function to create a new Stack.
The input to fn
is the client's current stack.
This API allows for easier usage when writing code that
uses method chaining.
This method is similar to transformed while providing easier API
ergonomics for one-off Stack
changes.
From Scala:
import com.twitter.finagle.Http
Http.server.withStack(_.prepend(MyStackModule))
From Java:
import com.twitter.finagle.Http; import static com.twitter.util.Function.func; Http.server().withStack(func(stack -> stack.prepend(MyStackModule)));
withStack(Stack)
A new StackServer with the provided Stack.
A new StackServer with the provided Stack.
withStack
that takes a Function1
for a more ergonomic
API when used with method chaining.
Configures this server or client with given stats.StatsReceiver (default: stats.DefaultStatsReceiver).
Configures this server or client with given stats.StatsReceiver (default: stats.DefaultStatsReceiver).
Configures this server or client with given tracing.Tracer (default: com.twitter.finagle.tracing.DefaultTracer).
Configures this server or client with given tracing.Tracer (default: com.twitter.finagle.tracing.DefaultTracer).
An entry point for configuring servers' com.twitter.finagle.transport.Transport.
An entry point for configuring servers' com.twitter.finagle.transport.Transport.
Transport
is a Finagle abstraction over the network connection (i.e., a TCP connection).
Implementation of ListeningStackServer which uses the push-based abstractions.