Interface HttpClientTransport

All Superinterfaces:
ClientConnectionFactory, HttpClient.Aware, Invocable
All Known Implementing Classes:
AbstractConnectorHttpClientTransport, AbstractHttpClientTransport, HttpClientTransportDynamic, HttpClientTransportOverFCGI, HttpClientTransportOverHTTP, HttpClientTransportOverHTTP2, HttpClientTransportOverHTTP3

public interface HttpClientTransport extends ClientConnectionFactory, HttpClient.Aware, Invocable
HttpClientTransport represents what transport implementations should provide in order to plug in a different transport for HttpClient.

While the HttpClient APIs define the HTTP semantic (request, response, headers, etc.) how an HTTP exchange is carried over the network depends on implementations of this class.

The default implementation uses the HTTP protocol to carry over the network the HTTP exchange, but the HTTP exchange may also be carried using the FCGI protocol, the HTTP/2 protocol or, in the future, other protocols.

  • Method Details

    • setHttpClient

      void setHttpClient(HttpClient client)
      Sets the HttpClient instance on this transport.

      This is needed because of a chicken-egg problem: in order to create the HttpClient a HttpClientTransport is needed, that therefore cannot have a reference yet to the HttpClient.

      Specified by:
      setHttpClient in interface HttpClient.Aware
      Parameters:
      client - the HttpClient that uses this transport.
    • newOrigin

      Origin newOrigin(Request request)
      Creates a new Origin with the given request.
      Parameters:
      request - the request that triggers the creation of the Origin
      Returns:
      an Origin that identifies a destination
    • newDestination

      Destination newDestination(Origin origin)
      Creates a new, transport-specific, HttpDestination object.

      HttpDestination controls the destination-connection cardinality: protocols like HTTP have 1-N cardinality, while multiplexed protocols like HTTP/2 have a 1-1 cardinality.

      Parameters:
      origin - the destination origin
      Returns:
      a new, transport-specific, HttpDestination object
    • connect

      void connect(SocketAddress address, Map<String,Object> context)
      Establishes a physical connection to the given address.
      Parameters:
      address - the address to connect to
      context - the context information to establish the connection
    • getConnectionPoolFactory

      ConnectionPool.Factory getConnectionPoolFactory()
      Returns:
      the factory for ConnectionPool instances
    • setConnectionPoolFactory

      void setConnectionPoolFactory(ConnectionPool.Factory factory)
      Set the factory for ConnectionPool instances.
      Parameters:
      factory - the factory for ConnectionPool instances
    • getInvocationType

      Invocable.InvocationType getInvocationType()
      Specified by:
      getInvocationType in interface Invocable
      Returns:
      the Invocable.InvocationType associated with this HttpClientTransport.
      See Also:
    • setInvocationType

      void setInvocationType(Invocable.InvocationType invocationType)

      Sets the Invocable.InvocationType associated with this HttpClientTransport.

      The values are typically either:

      By default, the value is Invocable.InvocationType.BLOCKING.

      A response listener declared to be Invocable.InvocationType.BLOCKING incurs in one additional context switch, where the NIO processing thread delegates the response processing to another thread. This ensures that the NIO processing thread can immediately continue with other NIO processing activities, if any (for example, processing another connection). This also means that processing of different connections is parallelized.

      Invocable.InvocationType.BLOCKING must be used when you want response listeners to be invoked by virtual threads.

      On the other hand, a response listener declared to be Invocable.InvocationType.NON_BLOCKING does not incur in the additional context switch, and therefore it is potentially more efficient. However, the processing of different connections is serialized, which means that the last connection will be processed only after the previous connections (and their respective response listeners) have been processed.

      A response listener declared to be Invocable.InvocationType.NON_BLOCKING, but then executing blocking code, will block the NIO processing performed by HttpClient's implementation: the current connection and possibly other connections will not be further processed, until the blocking response listener returns.

      Parameters:
      invocationType - the Invocable.InvocationType associated with this HttpClientTransport.
      See Also: