Trait

com.twitter.finagle.param

CommonParams

Related Doc: package param

Permalink

trait CommonParams[A <: Parameterized[A]] extends AnyRef

A collection of methods for configuring common parameters (labels, stats receivers, etc) shared between Finagle clients and servers.

A

a Stack.Parameterized server/client to configure

Self Type
CommonParams[A] with Parameterized[A]
Linear Supertypes
Known Subclasses
Ordering
  1. Alphabetic
  2. By Inheritance
Inherited
  1. CommonParams
  2. AnyRef
  3. Any
  1. Hide All
  2. Show All
Visibility
  1. Public
  2. All

Value Members

  1. final def !=(arg0: Any): Boolean

    Permalink
    Definition Classes
    AnyRef → Any
  2. final def ##(): Int

    Permalink
    Definition Classes
    AnyRef → Any
  3. final def ==(arg0: Any): Boolean

    Permalink
    Definition Classes
    AnyRef → Any
  4. final def asInstanceOf[T0]: T0

    Permalink
    Definition Classes
    Any
  5. def clone(): AnyRef

    Permalink
    Attributes
    protected[java.lang]
    Definition Classes
    AnyRef
    Annotations
    @throws( ... )
  6. final def eq(arg0: AnyRef): Boolean

    Permalink
    Definition Classes
    AnyRef
  7. def equals(arg0: Any): Boolean

    Permalink
    Definition Classes
    AnyRef → Any
  8. def finalize(): Unit

    Permalink
    Attributes
    protected[java.lang]
    Definition Classes
    AnyRef
    Annotations
    @throws( classOf[java.lang.Throwable] )
  9. final def getClass(): Class[_]

    Permalink
    Definition Classes
    AnyRef → Any
  10. def hashCode(): Int

    Permalink
    Definition Classes
    AnyRef → Any
  11. final def isInstanceOf[T0]: Boolean

    Permalink
    Definition Classes
    Any
  12. final def ne(arg0: AnyRef): Boolean

    Permalink
    Definition Classes
    AnyRef
  13. final def notify(): Unit

    Permalink
    Definition Classes
    AnyRef
  14. final def notifyAll(): Unit

    Permalink
    Definition Classes
    AnyRef
  15. final def synchronized[T0](arg0: ⇒ T0): T0

    Permalink
    Definition Classes
    AnyRef
  16. def toString(): String

    Permalink
    Definition Classes
    AnyRef → Any
  17. final def wait(): Unit

    Permalink
    Definition Classes
    AnyRef
    Annotations
    @throws( ... )
  18. final def wait(arg0: Long, arg1: Int): Unit

    Permalink
    Definition Classes
    AnyRef
    Annotations
    @throws( ... )
  19. final def wait(arg0: Long): Unit

    Permalink
    Definition Classes
    AnyRef
    Annotations
    @throws( ... )
  20. def withExceptionStatsHandler(exceptionStatsHandler: stats.ExceptionStatsHandler): A

    Permalink

    Configures this server or client with given exception stats handler.

  21. def withExecutionOffloaded(executor: ExecutorService): A

    Permalink

    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.

  22. def withExecutionOffloaded(pool: FuturePool): A

    Permalink

    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.

  23. def withLabel(label: String): A

    Permalink

    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.

  24. def withLabels(keywords: String*): A

    Permalink
  25. def withMonitor(monitor: util.Monitor): A

    Permalink

    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:

    • Synchronous exceptions thrown on request path, Service.apply(request)
    • Asynchronous exceptions (failed futures) thrown on request path, Service.apply(request)
    • Exceptions thrown from respond, onSuccess, onFailure future callbacks
    • Fatal exceptions thrown from map, flatMap, transform future continuations

    Put 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.

  26. def withRequestTimeout(timeout: Tunable[Duration]): A

    Permalink

    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.

    Client's Request Timeout

    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.

    Server's Request Timeout

    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.

    See also

    https://twitter.github.io/finagle/guide/Clients.html#timeouts-expiration and https://twitter.github.io/finagle/guide/Configuration.html#tunables

  27. def withRequestTimeout(timeout: Duration): A

    Permalink

    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.

    Client's Request Timeout

    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.

    Server's Request Timeout

    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.

    See also

    https://twitter.github.io/finagle/guide/Clients.html#timeouts-expiration

  28. def withResponseClassifier(responseClassifier: service.ResponseClassifier): A

    Permalink

    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

    Note

    If unspecified, the default classifier is com.twitter.finagle.service.ResponseClassifier.Default which is a total function fully covering the input domain.

    See also

    com.twitter.finagle.http.service.HttpResponseClassifier for some HTTP classification tools.

  29. def withStatsReceiver(statsReceiver: StatsReceiver): A

    Permalink

    Configures this server or client with given stats.StatsReceiver (default: stats.DefaultStatsReceiver).

  30. def withTracer(tracer: tracing.Tracer): A

    Permalink

    Configures this server or client with given tracing.Tracer (default: com.twitter.finagle.tracing.DefaultTracer).

Inherited from AnyRef

Inherited from Any

Ungrouped