Package org.jboss.resteasy.client.jaxrs.engines

Class ApacheHttpAsyncClient4Engine

java.lang.Object
org.jboss.resteasy.client.jaxrs.engines.ApacheHttpAsyncClient4Engine
All Implemented Interfaces:
Closeable, AutoCloseable, ClientHttpEngine, AsyncClientHttpEngine
@Deprecated(forRemoval=true, since="6.2") public class ApacheHttpAsyncClient4Engine extends Object implements AsyncClientHttpEngine, Closeable
Deprecated, for removal: This API element is subject to removal in a future version.
This will be removed in a future release as the underlying default implementation of the ClientHttpEngine will be replaced.
AsyncClientHttpEngine using apache http components HttpAsyncClient 4.

Some words of caution:

  • Asynchronous IO means non-blocking IO utilizing few threads, typically at most as much threads as number of cores. As such, performance may profit from fewer thread switches and less memory usage due to fewer thread-stacks. But doing synchronous, blocking IO (the invoke-methods not returning a future) may suffer, because the data has to be transferred piecewiese to/from the io-threads.
  • Request-Entities are fully buffered in memory, thus this engine is unsuitable for very large uploads.
  • Response-Entities are buffered in memory, except if requesting a Response, InputStream or Reader as Result. Thus for large downloads or COMET one of these three return types must be requested, but there may be a performance penalty because the response-body is transferred piecewise from the io-threads. When using InvocationCallbacks, the response is always fully buffered in memory.
  • InvocationCallbacks are called from within the io-threads and thus must not block or else the application may slow down to a halt. Reading the response is safe (because the response is buffered in memory), as are other async (and in-memory) Client-invocations (the submit-calls returning a future not containing Response, InputStream or Reader). Again, there must be no blocking IO inside InvocationCallback! (If you are wondering why not to allow blocking calls by wrapping InvocationCallbacks in extra threads: Because then the main advantage of async IO, less threading, is lost.)
  • InvocationCallbacks may be called seemingly "after" the future-object returns. Thus, responses should be handled solely in the InvocationCallback.
  • InvocationCallbacks will see the same result as the future-object and vice versa. Thus, if the invocationcallback throws an exception, the future-object will not see it. Another reason to handle responses only in the InvocationCallback.
Author:
Markus Kull

  • Field Details

    • client

      protected final org.apache.http.impl.nio.client.CloseableHttpAsyncClient client
      Deprecated, for removal: This API element is subject to removal in a future version.

    • closeHttpClient

      protected final boolean closeHttpClient
      Deprecated, for removal: This API element is subject to removal in a future version.

  • Constructor Details

    • ApacheHttpAsyncClient4Engine

      public ApacheHttpAsyncClient4Engine(boolean closeHttpClient)
      Deprecated, for removal: This API element is subject to removal in a future version.

    • ApacheHttpAsyncClient4Engine

      public ApacheHttpAsyncClient4Engine(org.apache.http.impl.nio.client.CloseableHttpAsyncClient client, boolean closeHttpClient)
      Deprecated, for removal: This API element is subject to removal in a future version.

  • Method Details