Examples of AbstractConnector

• com.google.gwt.thirdparty.org.mortbay.jetty.AbstractConnector
• diva.canvas.connector.AbstractConnector
  An abstract implementation of Connector. The implementation provides default implementations of all routing methods except for route(). It also provides a set of methods for setting the appearance of the connector, such as line width, dashes, and color. To do so, it uses an instance of PaintedPath, so see that class for a more detailed description of the paint- and stroke-related methods. @version $Id: AbstractConnector.java,v 1.15 2005/07/08 19:54:47 cxh Exp $ @author John Reekie @author Michael Shilman
• org.eclipse.jetty.server.AbstractConnector

  An abstract implementation of {@link Connector} that provides a {@link ConnectionFactory} mechanismfor creating {@link Connection} instances for various protocols (HTTP, SSL, SPDY, etc).

  Connector Services

  The abstract connector manages the dependent services needed by all specific connector instances:

  • The {@link Executor} service is used to run all active tasks needed by this connector such as accepting connectionsor handle HTTP requests. The default is to use the {@link Server#getThreadPool()} as an executor.
  • The {@link Scheduler} service is used to monitor the idle timeouts of all connections and is also made availableto the connections to time such things as asynchronous request timeouts. The default is to use a new {@link ScheduledExecutorScheduler} instance.
  • The {@link ByteBufferPool} service is made available to all connections to be used to acquire and release{@link ByteBuffer} instances from a pool. The default is to use a new {@link ArrayByteBufferPool} instance.

  These services are managed as aggregate beans by the {@link ContainerLifeCycle} super class andmay either be managed or unmanaged beans.

  Connection Factories

  The connector keeps a collection of {@link ConnectionFactory} instances, each of which are known by theirprotocol name. The protocol name may be a real protocol (eg http/1.1 or spdy/3) or it may be a private name that represents a special connection factory. For example, the name "SSL-http/1.1" is used for an {@link SslConnectionFactory} that has been instantiated with the {@link HttpConnectionFactory} as it'snext protocol.

  Configuring Connection Factories

  The collection of available {@link ConnectionFactory} may be constructor injected or modified with themethods {@link #addConnectionFactory(ConnectionFactory)}, {@link #removeConnectionFactory(String)} and{@link #setConnectionFactories(Collection)}. Only a single {@link ConnectionFactory} instance may be configuredper protocol name, so if two factories with the same {@link ConnectionFactory#getProtocol()} are set, thenthe second will replace the first.

  The protocol factory used for newly accepted connections is specified by the method {@link #setDefaultProtocol(String)} or defaults to the protocol of the first configured factory.

  Each Connection factory type is responsible for the configuration of the protocols that it accepts. Thus to configure the HTTP protocol, you pass a {@link HttpConfiguration} instance to the {@link HttpConnectionFactory}(or the SPDY factories that can also provide HTTP Semantics). Similarly the {@link SslConnectionFactory} isconfigured by passing it a {@link SslContextFactory} and a next protocol name.

  Connection Factory Operation

  {@link ConnectionFactory}s may simply create a {@link Connection} instance to support a specificprotocol. For example, the {@link HttpConnectionFactory} will create a {@link HttpConnection} instancethat can handle http/1.1, http/1.0 and http/0.9.

  {@link ConnectionFactory}s may also create a chain of {@link Connection} instances, using other {@link ConnectionFactory} instances.For example, the {@link SslConnectionFactory} is configured with a next protocol name, so that once it has accepteda connection and created an {@link SslConnection}, it then used the next {@link ConnectionFactory} from theconnector using the {@link #getConnectionFactory(String)} method, to create a {@link Connection} instance thatwill handle the unecrypted bytes from the {@link SslConnection}. If the next protocol is "http/1.1", then the {@link SslConnectionFactory} will have a protocol name of "SSL-http/1.1" and lookup "http/1.1" for the protocolto run over the SSL connection.

  {@link ConnectionFactory}s may also create temporary {@link Connection} instances that will exchange bytesover the connection to determine what is the next protocol to use. For example the NPN protocol is an extension of SSL to allow a protocol to be specified during the SSL handshake. NPN is used by the SPDY protocol to negotiate the version of SPDY or HTTP that the client and server will speak. Thus to accept a SPDY connection, the connector will be configured with {@link ConnectionFactory}s for "SSL-NPN", "NPN", "spdy/3", "spdy/2", "http/1.1" with the default protocol being "SSL-NPN". Thus a newly accepted connection uses "SSL-NPN", which specifies a SSLConnectionFactory with "NPN" as the next protocol. Thus an SslConnection instance is created chained to an NPNConnection instance. The NPN connection then negotiates with the client to determined the next protocol, which could be "spdy/3", "spdy/2" or the default of "http/1.1". Once the next protocol is determined, the NPN connection calls {@link #getConnectionFactory(String)} to create a connection instance that will replace the NPN connection asthe connection chained to the SSLConnection.

  Acceptors

  The connector will execute a number of acceptor tasks to the {@link Exception} service passed to the constructor.The acceptor tasks run in a loop while the connector is running and repeatedly call the abstract {@link #accept(int)} method.The implementation of the accept method must:
• block waiting for new connections
• accept the connection (eg socket accept)
• perform any configuration of the connection (eg. socket linger times)
• call the {@link #getDefaultConnectionFactory()} {@link ConnectionFactory#newConnection(Connector,org.eclipse.jetty.io.EndPoint)}method to create a new Connection instance. The default number of acceptor tasks is the minimum of 1 and half the number of available CPUs. Having more acceptors may reduce the latency for servers that see a high rate of new connections (eg HTTP/1.0 without keep-alive). Typically the default is sufficient for modern persistent protocols (HTTP/1.1, SPDY etc.)