...

Motivation

...

Futures

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

...

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.

Discussion Links

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

...