Packages

  • package root
    Definition Classes
    root
  • package com

    Start with com.twitter.finagle.

    Definition Classes
    root
  • package twitter

    Start with com.twitter.finagle.

    Definition Classes
    com
  • package finagle

    Finagle is an extensible RPC system.

    Finagle is an extensible RPC system.

    Services are represented by class com.twitter.finagle.Service. Clients make use of com.twitter.finagle.Service objects while servers implement them.

    Finagle contains a number of protocol implementations; each of these implement Client and/or com.twitter.finagle.Server. For example, Finagle's HTTP implementation, com.twitter.finagle.Http (in package finagle-http), exposes both.

    Thus a simple HTTP server is built like this:

    import com.twitter.finagle.{Http, Service}
    import com.twitter.finagle.http.{Request, Response}
    import com.twitter.util.{Await, Future}
    
    val service = new Service[Request, Response] {
      def apply(req: Request): Future[Response] =
        Future.value(Response())
    }
    val server = Http.server.serve(":8080", service)
    Await.ready(server)

    We first define a service to which requests are dispatched. In this case, the service returns immediately with a HTTP 200 OK response, and with no content.

    This service is then served via the Http protocol on TCP port 8080. Finally we wait for the server to stop serving.

    We can now query our web server:

    % curl -D - localhost:8080
    HTTP/1.1 200 OK

    Building an HTTP client is also simple. (Note that type annotations are added for illustration.)

    import com.twitter.finagle.{Http, Service}
    import com.twitter.finagle.http.{Request, Response}
    import com.twitter.util.{Future, Return, Throw}
    
    val client: Service[Request, Response] = Http.client.newService("localhost:8080")
    val f: Future[Response] = client(Request()).respond {
      case Return(rep) =>
        printf("Got HTTP response %s\n", rep)
      case Throw(exc) =>
        printf("Got error %s\n", exc)
    }

    Http.client.newService("localhost:8080") constructs a new com.twitter.finagle.Service instance connected to localhost TCP port 8080. We then issue a HTTP/1.1 GET request to URI "/". The service returns a com.twitter.util.Future representing the result of the operation. We listen to this future, printing an appropriate message when the response arrives.

    The Finagle homepage contains useful documentation and resources for using Finagle.

    Definition Classes
    twitter
  • package addr
    Definition Classes
    finagle
  • package builder
    Definition Classes
    finagle
  • package client
    Definition Classes
    finagle
  • package context
    Definition Classes
    finagle
  • package core
    Definition Classes
    finagle
  • package dispatch
    Definition Classes
    finagle
  • package exception
    Definition Classes
    finagle
  • package exp

    Package exp contains experimental code.

    Package exp contains experimental code. This can be removed or stabilized (moved elsewhere) at any time.

    Definition Classes
    finagle
  • package factory
    Definition Classes
    finagle
  • package filter
    Definition Classes
    finagle
  • package group
    Definition Classes
    finagle
  • package http
    Definition Classes
    finagle
  • package http2
    Definition Classes
    finagle
  • package httpproxy
    Definition Classes
    finagle
  • package kestrel
    Definition Classes
    finagle
  • package loadbalancer

    This package implements client side load balancing algorithms.

    This package implements client side load balancing algorithms.

    As an end-user, see the Balancers API to create instances which can be used to configure a Finagle client with various load balancing strategies.

    As an implementor, each algorithm gets its own subdirectory and is exposed via the Balancers object. Several convenient traits are provided which factor out common behavior and can be mixed in (i.e. Balancer, DistributorT, NodeT, and Updating).

    Definition Classes
    finagle
  • package mdns
    Definition Classes
    finagle
  • package memcached
    Definition Classes
    finagle
  • package exp
  • package java
  • package loadbalancer
  • package migration
  • package protocol
  • package replication

    Package replication implements a base cache client that can manage multiple cache replicas.

    Package replication implements a base cache client that can manage multiple cache replicas.

    The base replication client will forward cache command to all replicas, as well as collect and aggregate each replica's response into a ReplicationStatus object representing the replication consistency. The BaseReplicationClient will not handle the consistency between replicas in anyway, but only to report its view of the replication state. For instance, BaseReplicationClient provides interfaces similar to generic memcache client but always returns ReplicationStatus object which can be one of these three forms:

    • ConsistentReplication, indicating a consistent state across all replicas
    • InconsistentReplication, indicating an inconsistent state across all replicas
    • FailedReplication, indicating a failure state

    By checking the returned ReplicationStatus object, one can tell the cache replication status and then handle it with application specific logic.

    In addition to a base replication client, a simple replication client wrapper that's compatible with generic cache client interface is also provided. The SimpleReplicationClient only supports a subset of all memcached commands for now, and will succeed only if the command succeed on all cache replicas. In a more complicate caching scenario, this simple/naive replication client may not be applicable.

  • package util
  • BaseClient
  • CacheNode
  • CacheNodeGroup
  • CachePoolCluster
  • CachePoolConfig
  • CasResult
  • Client
  • ClientAdaptor
  • ConnectedClient
  • Entry
  • FailureAccrualException
  • GetResult
  • GetsResult
  • Interpreter
  • InterpreterService
  • KetamaClient
  • KetamaClientBuilder
  • KetamaClientKey
  • MockClient
  • PHPMemCacheClient
  • PHPMemCacheClientBuilder
  • PartitionedClient
  • PoolingReadRepairClient
  • ProxyClient
  • RubyMemCacheClient
  • RubyMemCacheClientBuilder
  • Server
  • StaticCachePoolCluster
  • TwemcacheClient
  • TwemcacheConnectedClient
  • TwemcachePartitionedClient
  • TwitterCacheResolver
  • TwitterCacheResolverException
  • ZookeeperCachePoolCluster
  • ZookeeperStateMonitor
  • package mux

    Package mux implements a generic RPC multiplexer with a rich protocol.

    Package mux implements a generic RPC multiplexer with a rich protocol. Mux is itself encoding independent, so it is meant to use as the transport for other RPC systems (eg. thrift). In OSI terminology, it is a pure session layer.

    In the below description, all numeric values are unsigned and in big-endian byte order. The schema size:4 body:10 defines the field size to be 4 bytes, followed by 10 bytes of the field body. The schema key~4 defines the field key to be defined by 4 bytes interpreted as the size of the field, followed by that many bytes comprising the field itself--it is shorthand for keysize:4 key:keysize. Groups are denoted by parenthesis; * denotes repetition of the previous schema 0 or more times, while {n} indicates repetition exactly n times. Unspecified sizes consume the rest of the frame: they may be specified only as the last field in the message.

    All strings in Mux are Utf-8 encoded, and are never null-terminated.

    Message framing

    Messages in mux are framed with a 4-byte big-endian size header, followed by 1 byte describing the message type and a 3-byte tag; or, diagrammatically: size:4 type:1 tag:3. The remainder of the frame (size-4 bytes) contains the body. Its format depends on the message type, documented below.

    Tag 0 designates a "marker" T message that expects no reply. Some messages may be split into an ordered sequence of fragments. Tag MSB=0 denotes the last message in such a sequence, making the tag namespace 23 bits. The tag is otherwise arbitrary, and is chosen by the sender of the T message.

    Currently, only Tdispatch and Rdispatch messages may be split into an ordered sequence of fragments. TdispatchError message ends a Tdispatch sequence and an Rerr ends an Rdispatch sequence.

    Message types, interpreted as a two's complement, 1-byte integer are numbered as follows: positive numbers are T-messages; their negative complement is the corresponding R message. T-messages greater than 63 (correspondingly R-messages smaller than -63) are session messages. The message number -128 is reserved for Rerr. All other messages are application messages. Middle boxes may forward application messages indiscriminately. Because of an early implementation bug, two aliases exist: 127 is Rerr, and -62 is Tdiscarded.

    The protocol is full duplex: both the server and client may send T messages initiating an exchange.

    Exchanges

    Messages are designated as "T messages" or "R messages", T and R being stand-ins for transmit and receive. A T message initiates an exchange and is assigned a free tag by the sender. A reply is either an R message of the same type (Rx replies to Tx for some x), or an Rerr, indicating a session layer error. R messages are matched to their T messages by tag, and the reply concludes the exchange and frees the tag for future use. Implementations should reuse small tag numbers.

    Messages

    size:4 Tinit:1 tag:3 version:2 (key~4 value~4)* reinitializes a session. Clients typically send this at the beginning of the session. When doing so, the sender may issue no more T messages until the corresponding size:4 Rinit:1 tag:3 version:2 (key~4 value~4)* has been received. After the Rinit was received, all connection state has been reset (outstanding tags are invalidated) and the stream is resumed according to the newly negotiated parameters. Prior to the first Tinit, the session operates at version 1. Rinit's version field is the accepted version of the session (which may be lower than the one requested by Tinit).

    size:4 Treq:1 tag:3 n:1 (key:1 value~1){n} body: initiates the request described by its body. The request body is delivered to the application. The request header contains a number of key-value pairs that describe request metadata.

    Keys for Treq messages are as follows:

    1. traceid: a 24-byte value describing the full Dapper trace id assigned by the client. The value's format is spanid:8 parentid:8 traceid:8.

    2. traceflag: a bitmask describing trace flags. Currently, the only defined flag is bit 0 which enables "debug mode", asking the server to force trace sampling.

    size:4 Tdispatch:1 tag:3 nctx:2 (ckey~2 cval~2){nc} dst~2 nd:2 (from~2 to~2){nd} body: implements destination dispatch. Tdispatch messages carry a set of keyed request contexts, followed by a logical destination encoded as a UTF-8 string. A delegation table follows describing rewrite rules that apply to this request.

    size:4 Rreq:1 tag:3 status:1 body: replies to a request. Status codes are as follows: 0=OK; the body contains the reply. 1=ERROR; the body contains a string describing the error. 2=NACK; a negative acknowledgment, the body contains a string describing the reason.

    size:4 Rdispatch:1 tag:3 status:1 nctx:2 (key~2 value~2){nctx} body: replies to a Tdispatch request. Status codes are as in Rreq. Replies can include request contexts. MuxFailure flags are currently sent via Rdispatch contexts under the "MuxFailure" key. See the MuxFailure flags section below.

    size:4 Rerr:1 tag:3 why: indicates that the corresponding T message produced an error. Rerr is specifically for server errors: the server failed to interpret or act on the message. The body carries a string describing the error.

    size:4 Tdrain:1 tag:3 is a request sent by the server telling the client to stop sending new requests. A client acknowledges this with an Rdrain message.

    size:4 Tping:1 tag:3 is sent by either party to check the liveness of its peer; these should be responded to immediately with a Rping message.

    size:4 Tdiscarded:1 tag:3 discard_tag:3 why: is a marker message and therefore has a tag value of 0. discard_tag indicates the tag of the Tdispatch to be discarded by the client. This can be used as a hint for early termination. Why is a string describing why the request was discarded. Note that it does *not* free the server from the obligation of replying to the original Treq.

    size:4 Tlease:1 tag:3 unit:1 howmuch:8 is a marker message indicating that a lease has been issued for howmuch units. As a marker message, its tag value must be 0. Unit '0' is reserved for duration in milliseconds. Whenever a lease has not been issued, a client can assume it holds an indefinite lease. Adhering to the lease is optional, but the server may reject requests or provide degraded service should the lease expire. This is used by servers to implement features like garbage collection avoidance.

    MuxFailure Flags

    Failure flags are read and written as an 8 byte integer. Unrecognized flags will be ignored silently, but should all be considered reserved for future use.

    Flag Value Meaning Restartable 1 << 0 Request is safe to re-issue Rejected 1 << 1 Request was rejected/Nacked by the server NonRetryable 1 << 2 Request should not be retried

    Definition Classes
    finagle
  • package mysql
    Definition Classes
    finagle
  • package namer
    Definition Classes
    finagle
  • package naming
    Definition Classes
    finagle
  • package netty3

    Package netty3 implements the bottom finagle primitives: {{com.twitter.finagle.Server}} and a client transport in terms of the netty3 event loop.

    Package netty3 implements the bottom finagle primitives: {{com.twitter.finagle.Server}} and a client transport in terms of the netty3 event loop.

    Note: when {{com.twitter.finagle.builder.ClientBuilder}} and {{com.twitter.finagle.builder.ServerBuilder}} are deprecated, package netty3 can move into its own package, so that only the (new-style) clients and servers that depend on netty3 bring it in.

    Definition Classes
    finagle
  • package netty4

    Package netty4 implements the bottom finagle primitives: com.twitter.finagle.Server and a client transport in terms of the netty4 event loop.

    Package netty4 implements the bottom finagle primitives: com.twitter.finagle.Server and a client transport in terms of the netty4 event loop.

    Definition Classes
    finagle
  • package param

    Defines common com.twitter.finagle.Stack.Param's shared between finagle clients and servers.

    Defines common com.twitter.finagle.Stack.Param's shared between finagle clients and servers.

    Definition Classes
    finagle
  • package pool
    Definition Classes
    finagle
  • package redis
    Definition Classes
    finagle
  • package server
    Definition Classes
    finagle
  • package serverset2
    Definition Classes
    finagle
  • package service
    Definition Classes
    finagle
  • package socks
    Definition Classes
    finagle
  • package ssl
    Definition Classes
    finagle
  • package stats
    Definition Classes
    finagle
  • package stream

    Finagle-stream implements a rather peculiar protocol: it streams discrete messages delineated by HTTP chunks.

    Finagle-stream implements a rather peculiar protocol: it streams discrete messages delineated by HTTP chunks. It isn't how we'd design a protocol to stream messages, but we are stuck with it for legacy reasons.

    Finagle-stream sessions are also one-shot: each session handles exactly one stream. The session terminates together with the stream.

    Definition Classes
    finagle
  • package thrift

    Please use the new interface, com.twitter.finagle.Thrift, for constructing Thrift clients and servers.

    Deprecation

    Please use the new interface, com.twitter.finagle.Thrift, for constructing Thrift clients and servers.

    Thrift codecs

    We provide client and server protocol support for the framed protocol. The public implementations are defined on the Thrift object:

    The type of the server codec is Service[Array[Byte], Array[Byte]] and the client codecs are Service[ThriftClientRequest, Array[Byte]]. The service provided is that of a "transport" of thrift messages (requests and replies) according to the protocol chosen. This is why the client codecs need to have access to a thrift ProtocolFactory.

    These transports are used by the services produced by the finagle thrift codegenerator.

    val service: Service[ThriftClientRequest, Array[Byte]] = ClientBuilder()
      .hosts("foobar.com:123")
      .stack(Thrift.client)
      .build()
    
    // Wrap the raw Thrift transport in a Client decorator. The client
    // provides a convenient procedural interface for accessing the Thrift
    // server.
    val client = new Hello.ServiceToClient(service, protocolFactory)

    In this example, Hello is the thrift interface, and the inner class ServiceToClient is provided by the finagle thrift code generator.

    Definition Classes
    finagle
  • package thriftmux
    Definition Classes
    finagle
  • package toggle
    Definition Classes
    finagle
  • package tracing
    Definition Classes
    finagle
  • package transport
    Definition Classes
    finagle
  • package util
    Definition Classes
    finagle
  • package zipkin
    Definition Classes
    finagle
  • package zookeeper
    Definition Classes
    finagle
p

com.twitter.finagle

memcached

package memcached

Linear Supertypes
Ordering
  1. Alphabetic
  2. By Inheritance
Inherited
  1. memcached
  2. AnyRef
  3. Any
  1. Hide All
  2. Show All
Visibility
  1. Public
  2. All

Type Members

  1. trait BaseClient [T] extends AnyRef

    A friendly client to talk to a Memcached server.

    A friendly client to talk to a Memcached server.

    See also

    The Memcached protocol docs for details on the API.

  2. case class CacheNode (host: String, port: Int, weight: Int, key: Option[String] = None) extends SocketAddress with Product with Serializable
  3. trait CachePoolCluster extends Cluster[CacheNode]
  4. case class CachePoolConfig (cachePoolSize: Int, detectKeyRemapping: Boolean = false) extends Product with Serializable

    Cache pool config data format Currently this data format is only used by ZookeeperCachePoolManager to read the config data from zookeeper serverset parent node, and the expected cache pool size is the only attribute we need for now.

    Cache pool config data format Currently this data format is only used by ZookeeperCachePoolManager to read the config data from zookeeper serverset parent node, and the expected cache pool size is the only attribute we need for now. In the future this can be extended for other config attributes like cache pool migrating state, backup cache servers list, or replication role, etc

  5. sealed trait CasResult extends AnyRef

    The result of a check and set command.

    The result of a check and set command.

    See also

    BaseClient.checkAndSet

  6. trait Client extends BaseClient[Buf]
  7. class ClientAdaptor [T] extends BaseClient[T] with Proxy
  8. class ConnectedClient extends Client

    A Client connected to an individual Memcached server.

    A Client connected to an individual Memcached server.

    Attributes
    protected
  9. case class Entry (value: Buf, expiry: Time) extends Product with Serializable
  10. class FailureAccrualException extends RequestException
  11. case class GetResult extends Product with Serializable
  12. case class GetsResult (getResult: GetResult) extends Product with Serializable
  13. class Interpreter extends AnyRef

    Evaluates a given Memcached operation and returns the result.

  14. class InterpreterService extends Service[Command, Response]
  15. abstract class KetamaClientKey extends AnyRef
  16. class MockClient extends Client

    Map-based mock client for testing

    Map-based mock client for testing

    Note: expiry and flags are ignored on update operations.

  17. class PHPMemCacheClient extends PartitionedClient

    PHP memcache-client (memcache.so) compatible client.

  18. case class PHPMemCacheClientBuilder (_nodes: Seq[(String, Int, Int)], _hashName: Option[String], _clientBuilder: Option[ClientBuilder[_, _, _, _, Yes]]) extends Product with Serializable

    Builder for memcache-client (memcache.so) compatible client.

  19. trait PartitionedClient extends Client

    A partitioned client is a client that delegates to an actual client based on the key value.

    A partitioned client is a client that delegates to an actual client based on the key value. Subclasses implement clientOf to choose the Client.

  20. class PoolingReadRepairClient extends Client

    This class is designed to support replicated memcached setups.

    This class is designed to support replicated memcached setups. It supports a limited subset of operations (just get, set, and delete).

  21. trait ProxyClient extends Client
  22. class RubyMemCacheClient extends PartitionedClient

    Ruby memcache-client (MemCache) compatible client.

  23. case class RubyMemCacheClientBuilder (_nodes: Seq[(String, Int, Int)], _clientBuilder: Option[ClientBuilder[_, _, _, _, Yes]]) extends Product with Serializable

    Builder for memcache-client (MemCache) compatible client.

  24. class StaticCachePoolCluster extends CachePoolCluster

    Cache pool based on a static list

  25. trait TwemcacheClient extends Client
  26. trait TwemcacheConnectedClient extends TwemcacheClient

    Twemcache commands implementation.

    Twemcache commands implementation. This trait can only be mixed into a memcache client implementation as extension.

  27. trait TwemcachePartitionedClient extends TwemcacheClient

    Twemcache commands implemenation for a partitioned client.

    Twemcache commands implemenation for a partitioned client. This trait can only be mixed into a ParitionedClient that is delegating twemcache compatible clients.

  28. class TwitterCacheResolver extends Resolver

    A com.twitter.finagle.Resolver for resolving destination names associated with Twitter cache pools.

  29. class TwitterCacheResolverException extends Exception

    Indicates that an error occurred while resolving a cache address.

    Indicates that an error occurred while resolving a cache address. See com.twitter.finagle.memcached.TwitterCacheResolver for details.

  30. class ZookeeperCachePoolCluster extends CachePoolCluster with ZookeeperStateMonitor

    Zookeeper based cache pool cluster with a serverset as the underlying pool.

    Zookeeper based cache pool cluster with a serverset as the underlying pool. It will monitor the underlying serverset changes and report the detected underlying pool size. It will also monitor the serverset parent node for cache pool config data, cache pool cluster update will be triggered whenever cache config data change event happens.

  31. trait ZookeeperStateMonitor extends AnyRef

    A zk monitor trait that assists with monitoring a given zk path for any node data change, in which the provided zk data handling implementation will be invoked.

    A zk monitor trait that assists with monitoring a given zk path for any node data change, in which the provided zk data handling implementation will be invoked.

    This monitor will maintain a queue so that every work item triggered by zk event will be processed in an order with a back off policy. It also set-up a zookeeper connection watcher by default to re-set the data change watcher even during zk re-connect.

    The monitor will set-up all watcher properly kick off the loop to process future event; you can also invoke loadZKData() in your class anytime to force reading zk data and apply it.

    Example use cases are: - zookeeper based CachePoolCluster uses this to monitor cache pool members change - zookeeper based MigrationClient uses this ot monitor migration state transitioning

  32. case class KetamaClientBuilder extends Product with Serializable
    Annotations
    @deprecated
    Deprecated

    (Since version 2015-02-22) Use the com.twitter.finagle.Memcached builder

  33. class Server extends AnyRef

    An in-process memcached server.

    An in-process memcached server.

    Annotations
    @deprecated
    Deprecated

    (Since version 7.0.0) Moved into test

Value Members

  1. object CacheNode extends Serializable
  2. object CacheNodeGroup
  3. object CachePoolCluster

    Cache specific cluster implementation.

    Cache specific cluster implementation. - A cache pool is a Cluster of cache nodes. - cache pool requires a underlying pool manager as the source of the cache nodes - the underlying pool manager encapsulates logic of monitoring the cache node changes and deciding when to update the cache pool cluster

  4. object CachePoolConfig extends Serializable

    Cache pool config data object

  5. object CasResult
  6. object Client
  7. object GetResult extends Serializable
  8. object KetamaClient
  9. object KetamaClientBuilder extends Serializable
  10. object KetamaClientKey
  11. object PHPMemCacheClientBuilder extends Serializable
  12. object PartitionedClient
  13. object TwemcacheClient
  14. object ZookeeperCachePoolCluster

    ZooKeeper based cache pool cluster companion object

  15. object ZookeeperStateMonitor

Inherited from AnyRef

Inherited from Any

Ungrouped