Interface HttpClientTransport
- All Superinterfaces:
 ClientConnectionFactory, HttpClient.Aware, Invocable
- All Known Implementing Classes:
 AbstractConnectorHttpClientTransport, AbstractHttpClientTransport, HttpClientTransportDynamic, HttpClientTransportOverFCGI, HttpClientTransportOverHTTP, HttpClientTransportOverHTTP2, HttpClientTransportOverHTTP3
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.
- 
Nested Class Summary
Nested classes/interfaces inherited from interface ClientConnectionFactory
ClientConnectionFactory.Decorator, ClientConnectionFactory.Info, ClientConnectionFactory.WrapperNested classes/interfaces inherited from interface Invocable
Invocable.Callable, Invocable.InvocationType, Invocable.ReadyTask, Invocable.Task - 
Field Summary
Fields inherited from interface ClientConnectionFactory
CONTEXT_KEYFields inherited from interface Invocable
__nonBlocking, NOOP - 
Method Summary
Modifier and TypeMethodDescriptionvoidconnect(SocketAddress address, Map<String, Object> context) Establishes a physical connection to the givenaddress.newDestination(Origin origin) Creates a new, transport-specific,HttpDestinationobject.Creates a new Origin with the given request.voidSet the factory for ConnectionPool instances.voidsetHttpClient(HttpClient client) Sets theHttpClientinstance on this transport.voidsetInvocationType(Invocable.InvocationType invocationType) Sets theInvocable.InvocationTypeassociated with thisHttpClientTransport.Methods inherited from interface ClientConnectionFactory
customize, newConnection 
- 
Method Details
- 
setHttpClient
Sets theHttpClientinstance on this transport.This is needed because of a chicken-egg problem: in order to create the
HttpClienta HttpClientTransport is needed, that therefore cannot have a reference yet to theHttpClient.- Specified by:
 setHttpClientin interfaceHttpClient.Aware- Parameters:
 client- theHttpClientthat uses this transport.
 - 
newOrigin
 - 
newDestination
Creates a new, transport-specific,HttpDestinationobject.HttpDestinationcontrols 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, 
HttpDestinationobject 
 - 
connect
Establishes a physical connection to the givenaddress.- Parameters:
 address- the address to connect tocontext- the context information to establish the connection
 - 
getConnectionPoolFactory
ConnectionPool.Factory getConnectionPoolFactory()- Returns:
 - the factory for ConnectionPool instances
 
 - 
setConnectionPoolFactory
Set the factory for ConnectionPool instances.- Parameters:
 factory- the factory for ConnectionPool instances
 - 
getInvocationType
Invocable.InvocationType getInvocationType()- Specified by:
 getInvocationTypein interfaceInvocable- Returns:
 - the 
Invocable.InvocationTypeassociated with thisHttpClientTransport. - See Also:
 
 - 
setInvocationType
Sets the
Invocable.InvocationTypeassociated with thisHttpClientTransport.The values are typically either:
Invocable.InvocationType.BLOCKING, to indicate that response listeners are executing blocking code, for example blocking network I/O, JDBC, etc.Invocable.InvocationType.NON_BLOCKING, to indicate that response listeners are executing non-blocking code.
By default, the value is
Invocable.InvocationType.BLOCKING.A response listener declared to be
Invocable.InvocationType.BLOCKINGincurs 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.BLOCKINGmust 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_BLOCKINGdoes 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 byHttpClient's implementation: the current connection and possibly other connections will not be further processed, until the blocking response listener returns.- Parameters:
 invocationType- theInvocable.InvocationTypeassociated with thisHttpClientTransport.- See Also:
 
 
 -