ID | IEP-51 |
Author | |
Sponsor | |
Created |
|
Status | DRAFT |
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 IgniteFuture for consistency with other Ignite 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).
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 return the result to the user code. However, if the user code calls IgniteFuture#listen, listeners 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.
// Describe project risks, such as API or binary compatibility issues, major protocol changes, etc.
// Links to discussions on the devlist, if applicable.
// Links to various reference documents, if applicable.