You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

Asynchronous Client HTTP Transport

By default, CXF uses a transport based on the in-JDK HttpURLConnection object to perform HTTP requests. The HttpURLConnection object uses a blocking model for all IO operations which requires a per-thread execution model. From a pure performance standpoint, this model generally performs very well, but it does have problems scaling when many requests need to be executed simultaneously.

Also, the JAX-WS specification allows for generation of asynchronous methods on generated proxies as well as using asynchronous methods on the Dispatch objects. These methods can take an AsyncHandler object and return a polling Future object so applications do not have to wait for the response. With the HttpURLConnection based transport, CXF was forced to consume a background thread for each outstanding request.

CXF also has an HTTP client transport that is based on the Apache HTTP Components HttpAsyncClient library. The HttpAsyncClient library uses a non-blocking IO model. This allows many more requests to be outstanding without consume extra background threads. It also allows greater control over things like Keep-Alive handling which is very difficult or impossible with the HttpURLConnection based transport. However, the non-blocking model does not perform quite as well as the blocking model for pure synchronous request/response transactions.

By default, if the cxf-rt-transports-http-hc module is found on the classpath, CXF will use the HttpAsyncClient based implementation for any Async calls, but will continue to use the HttpURLConnection based transport for synchronous calls. This allows a good balance of performance for the common synchronous cases with scalability for the asynchronous cases. However, using a contextual property of "use.async.http.conduit" and set to true/false, you can control whether the async or blocking version is used.

Configuration

The Asynchronous HTTP Transport has several options that can set using Bus properties or via the OSGi configuration services to control various aspects of the underlying Apache HTTP Components HttpAsyncClient objects.

Settings related to the underlying TCP socket:

org.apache.cxf.transport.http.async.TCP_NODELAY

The TCP_NODELAY for the socket. Defaults to true.

org.apache.cxf.transport.http.async.SO_KEEPALIVE

 

org.apache.cxf.transport.http.async.SO_LINGER

 

org.apache.cxf.transport.http.async.SO_TIMEOUT

 

Settings related to Keep-Alive connection management:

org.apache.cxf.transport.http.async.MAX_CONNECTIONS

Maximum number of connections opened per host. Default is 1000.

org.apache.cxf.transport.http.async.MAX_PER_HOST_CONNECTIONS

Maximum number of connections opened in total. Default is 5000.

Settings related to Apache HttpAsyncClient threads and selectors:

org.apache.cxf.transport.http.async.ioThreadCount

Number of threads HttpAsyncClient uses to process IO events. Default is "-1" which means one thread per CPU core.

org.apache.cxf.transport.http.async.interestOpQueued

true/false for whether the interest ops are queues or process directly.

org.apache.cxf.transport.http.async.selectInterval

Default 1000 ms. How often the selector thread wakes up if there are no events to process additional things like queue expirations.

Setting to control which conduit is used

org.apache.cxf.transport.http.async.usePolicy

ALWAYS, ASYNC_ONLY, NEVER.

  • No labels