Package org.eclipse.jetty.server

Class AbstractConnector

java.lang.Object
org.eclipse.jetty.util.component.AbstractLifeCycle
org.eclipse.jetty.util.component.ContainerLifeCycle
org.eclipse.jetty.server.AbstractConnector
All Implemented Interfaces:
Connector, Container, Destroyable, Dumpable, Dumpable.DumpableContainer, Graceful, LifeCycle
Direct Known Subclasses:
AbstractNetworkConnector, LocalConnector, UnixSocketConnector
@ManagedObject("Abstract implementation of the Connector Interface") public abstract class AbstractConnector extends ContainerLifeCycle implements Connector, Dumpable

An abstract implementation of Connector that provides a ConnectionFactory mechanism for creating Connection instances for various protocols (HTTP, SSL, etc).

Connector Services

The abstract connector manages the dependent services needed by all specific connector instances:
  • The Executor service is used to run all active tasks needed by this connector such as accepting connections or handle HTTP requests. The default is to use the Server.getThreadPool() as an executor.
  • The Scheduler service is used to monitor the idle timeouts of all connections and is also made available to the connections to time such things as asynchronous request timeouts. The default is to use a new ScheduledExecutorScheduler instance.
  • The ByteBufferPool service is made available to all connections to be used to acquire and release ByteBuffer instances from a pool. The default is to use a new ArrayByteBufferPool instance.
These services are managed as aggregate beans by the ContainerLifeCycle super class and may either be managed or unmanaged beans.

Connection Factories

The connector keeps a collection of ConnectionFactory instances, each of which are known by their protocol name. The protocol name may be a real protocol (e.g. "http/1.1" or "h2") 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 SslConnectionFactory that has been instantiated with the HttpConnectionFactory as it's next protocol.

Configuring Connection Factories

The collection of available ConnectionFactory may be constructor injected or modified with the methods addConnectionFactory(ConnectionFactory), removeConnectionFactory(String) and setConnectionFactories(Collection). Only a single ConnectionFactory instance may be configured per protocol name, so if two factories with the same ConnectionFactory.getProtocol() are set, then the second will replace the first.

The protocol factory used for newly accepted connections is specified by the method 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 HttpConfiguration instance to the HttpConnectionFactory (or other factories that can also provide HTTP Semantics). Similarly the SslConnectionFactory is configured by passing it a SslContextFactory and a next protocol name.

Connection Factory Operation

ConnectionFactorys may simply create a Connection instance to support a specific protocol. For example, the HttpConnectionFactory will create a HttpConnection instance that can handle http/1.1, http/1.0 and http/0.9.

ConnectionFactorys may also create a chain of Connection instances, using other ConnectionFactory instances. For example, the SslConnectionFactory is configured with a next protocol name, so that once it has accepted a connection and created an SslConnection, it then used the next ConnectionFactory from the connector using the getConnectionFactory(String) method, to create a Connection instance that will handle the unencrypted bytes from the SslConnection. If the next protocol is "http/1.1", then the SslConnectionFactory will have a protocol name of "SSL-http/1.1" and lookup "http/1.1" for the protocol to run over the SSL connection.

ConnectionFactorys may also create temporary Connection instances that will exchange bytes over the connection to determine what is the next protocol to use. For example the ALPN protocol is an extension of SSL to allow a protocol to be specified during the SSL handshake. ALPN is used by the HTTP/2 protocol to negotiate the protocol that the client and server will speak. Thus to accept an HTTP/2 connection, the connector will be configured with ConnectionFactorys for "SSL-ALPN", "h2", "http/1.1" with the default protocol being "SSL-ALPN". Thus a newly accepted connection uses "SSL-ALPN", which specifies a SSLConnectionFactory with "ALPN" as the next protocol. Thus an SSL connection instance is created chained to an ALPN connection instance. The ALPN connection then negotiates with the client to determined the next protocol, which could be "h2" or the default of "http/1.1". Once the next protocol is determined, the ALPN connection calls getConnectionFactory(String) to create a connection instance that will replace the ALPN connection as the connection chained to the SSL connection.

Acceptors

The connector will execute a number of acceptor tasks to the Exception service passed to the constructor. The acceptor tasks run in a loop while the connector is running and repeatedly call the abstract accept(int) method. The implementation of the accept method must:
  1. block waiting for new connections
  2. accept the connection (eg socket accept)
  3. perform any configuration of the connection (eg. socket configuration)
  4. call the getDefaultConnectionFactory() 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 the number of available CPUs divided by 8. 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, HTTP/2 etc.)