Motivation

Current Java Thin Client API is synchronous (blocking). Blocking APIs do not scale well.

Underlying protocol and Java implementation are inherently asynchronous, so any thin client API can have an async equivalent.

Description

APIs

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 CompletableFuture, which is a current standard for async Java APIs.

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).

Future Completion Thread

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 this future in a CompletableFuture directly and return the result to the user code. However, if the user code 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.

Discussion Links

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

POC: https://github.com/apache/ignite/pull/8174

Tickets

Unable to render Jira issues macro, execution error.