Packages

  • package root
    Definition Classes
    root
  • package com
    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 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 liveness
    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 namer
    Definition Classes
    finagle
  • package naming
    Definition Classes
    finagle
  • package offload
    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 pushsession
    Definition Classes
    finagle
  • PipeliningClientPushSession
  • PushChannelHandle
  • PushChannelHandleProxy
  • PushListener
  • PushSession
  • PushStackClient
  • PushStackServer
  • PushTransporter
  • RefPushSession
  • package server
    Definition Classes
    finagle
  • package service
    Definition Classes
    finagle
  • package ssl
    Definition Classes
    finagle
  • package stats
    Definition Classes
    finagle
  • package thrift
    Definition Classes
    finagle
  • package tracing
    Definition Classes
    finagle
  • package transport
    Definition Classes
    finagle
  • package util
    Definition Classes
    finagle
p

com.twitter.finagle

pushsession

package pushsession

Type Members

  1. final class PipeliningClientPushSession[In, Out] extends PushSession[In, Out]

    A Pipelined PushSession.

    A Pipelined PushSession.

    This assumes servers will respect normal pipelining semantics, and that replies will be sent in the same order as requests were sent.

    Because many requests might be sharing the same push channel, Futures returned by PipeliningClientPushSession#apply are masked, and will only propagate the interrupt if the Future doesn't return after a configurable amount of time after the interruption. This ensures that interrupting a Future in one request won't change the result of another request unless the connection is stuck, and does not look like it will make progress. Use stallTimeout to configure this timeout.

  2. trait PushChannelHandle[In, Out] extends Closable with ClientConnection

    Abstraction for interacting with the underlying I/O pipeline.

    Abstraction for interacting with the underlying I/O pipeline.

    The ChannelHandle provides tools for writing messages to the peer, an Executor which provides single threaded behavior for executed tasks, and information about the peer and state of the pipeline.

    All method calls on the ChannelHandle are guaranteed not to result in re-entrance into the PushSession so long as these methods are called from within the serialExecutor. Specifically, if a session invokes a method on the handle it will not result in a new event reaching the session before the method call has returned. This avoids situations such as a session performing a write and before the call returns a new inbound message arrives and mutates session state in an unexpected way.

    All failures are fatal to the PushChannelHandle including write failures. Specifically, any failure results in the onClose promise being completed with the exception in the Throw pathway and the underlying socket will be closed.

  3. abstract class PushChannelHandleProxy[In, Out] extends PushChannelHandle[In, Out]

    Base proxy implementation for PushChannelHandle

    Base proxy implementation for PushChannelHandle

    Implementations should override methods as appropriate.

  4. trait PushListener[In, Out] extends AnyRef

    A PushListener provide a method, listen, to expose a server on the the given SocketAddress.

    A PushListener provide a method, listen, to expose a server on the the given SocketAddress. sessionBuilder is called for each new connection. It is furnished with a typed PushChannelHandle representing this connection and expects a PushSession to be returned asynchronously, at which point the session will begin to receive events. The returned ListeningServer is used to inspect the server and to shut it down.

  5. abstract class PushSession[In, Out] extends Closable

    Representation of a push-based protocol session.

    Representation of a push-based protocol session.

    The PushSession is intended to be used with the PushChannelHandle abstraction to provide the interface for building a push-based protocol implementation. In this pattern, events coming from the socket are 'pushed' into the session via the receive method with well defined thread behavior. Specifically, the receive method will be called with new events from the single-threaded Executor available in the associated PushChannelHandle. This provides two key benefits for push-based protocol implementations: - We remove the overhead of the Future abstraction intrinsic to the Transport and Dispatcher based model. - The session itself provides a clear pattern for managing synchronization that works well with the Promise abstraction by avoiding explicit synchronization. See the README.md for more details.

  6. abstract class PushStackClient[Req, Rep, This <: PushStackClient[Req, Rep, This]] extends EndpointerStackClient[Req, Rep, This]

    Base type for building a com.twitter.finagle.client.StackClient using the push-based protocol tools.

  7. trait PushStackServer[Req, Rep, This <: PushStackServer[Req, Rep, This]] extends ListeningStackServer[Req, Rep, This]

    Implementation of ListeningStackServer which uses the push-based abstractions.

  8. trait PushTransporter[In, Out] extends AnyRef

    PushSessionTransporters attempt to construct a PushChannelHandle and provide it to the factory function, returning any errors as failed Futures.

    PushSessionTransporters attempt to construct a PushChannelHandle and provide it to the factory function, returning any errors as failed Futures.

    Note

    There is one PushTransporter assigned per remote peer.

  9. final class RefPushSession[In, Out] extends PushSession[In, Out]

    Proxy PushSession which can update the underlying session.

    Proxy PushSession which can update the underlying session.

    Thread safety considerations

    - receive is only intended to be called from within the serial executor, which is a general rule in all PushSession implementations. - updateRef should be called only from within the handle's serial executor. This is to avoid race conditions between closing the underlying session (which happens in the serial executor) and replacing it with a new session: if replacing happens in the same thread, there is no need to worry about broadcasting close events from the old session to the new one. - close and status are safe to call from any thread.

Ungrouped