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.
Provide async equivalents for all Java Thin Client APIs where possible:
Async APIs should return 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 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.
Therefore, response handling and user-defined continuations should be moved to another thread:
Add ClientConfiguration.asyncContinuationExecutor property of type java.util.concurrent.Executor
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.
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.