...

Motivation

...

Provide async equivalents for all Java Thin Client APIs where possible:

• IgniteClient (createCache, destroyCache, cacheNames, ...)
• ClientCache (everything except queries)
• ClientCluster, ClientClusterGroup
• ClientCompute (already has executeAsync, but may need improvement - see below)
• ClientTransaction, ClientTransactions

Excluded APIs

• ClientServices: actual server calls are performed through java.lang.reflect.Proxy, making this asynchronous is nontrivial.
• Cache queries: most of the work is performed through QueryCursor, which is synchronous. We could implement AsyncQueryCursor and provide async iteration capabilities, but this is out of scope of this IEP.

Futures

Async APIs should return IgniteFuture for consistency with other Ignite APIs.a new kind of future: 

IgniteClientFuture<T> extends Future<T>, CompletionStage<T>

This future simply wraps CompletableFuture, which is a current standard for async Java APIs. We do not want to return CompletableFuture directly, because it is a class and it provides methods to complete it from outside.

ClientCompute#executeAsync returns plain j.u.c.Future, which does not provide completion callbacks or chaining, this should be changed (deprecate old method and create a new one).

...

Thin client responses are processed by a dedicated thin-client-channel thread (see TcpClientChannel#RECEIVER_THREAD_PREFIX usages). This thread calls GridFutureAdapter#onDone for the corresponding ClientRequestFuture when an operation completes. With a naïve implementation, we would wrap ClientRequestFuture in IgniteFutureImpl and this future in a CompletableFuture directly and return the result to the user code. However, if the user code calls IgniteFuture#listen, listeners calls one of many CompletableFuture#thenX methods, the callback will be executed by the same thin-client-channel thread, potentially capturing that thread forever, so no more client responses can be processed.

• Users do not need to worry about running their code on Ignite-specific thread
• We should offload thin-client-channel thread as much as possible to improve response processing performance

Therefore, response handling and user-defined continuations should be moved to another thread:

• Add ClientConfiguration.asyncContinuationExecutor property of type java.util.concurrent.Executor

• When null, use ForkJoinPool.

...

• commonPool()

Note that users can still provide an executor that does not use a separate thread, but the default behavior with ForkJoinPool should be suitable for most.

Implementation Details

TcpClientChannel is already mostly async: every request has corresponding ClientRequestFuture, and a dedicated thread completes those futures. The scope of this IEP includes reusing those futures for async operations.

However, socket writes are still performed from the initiator thread, only one thread at a time can write to a socket, and TcpClientChannel uses blocking socket APIs, so we only eliminate thread blocking for the duration of the request handling by the server

Risks and Assumptions

// Describe project risks, such as API or binary compatibility issues, major protocol changes, etc.

Discussion Links

Dev List: http:// Links to discussions on the devlist, if applicable.

Reference Links

/apache-ignite-developers.2346864.n4.nabble.com/IEP-51-Java-Thin-Client-Async-API-td48900.html

POC: https://github.com/apache/ignite/pull/8174// Links to various reference documents, if applicable.

Tickets