Val, Agree with your points.
> async API should be primary It should be noted that all our APIs are inherently async, because thin client is implemented asynchronously. > with the sync version build on top We should document somehow that sync APIs are based on async ones, because this may be dangerous in some use cases. For example, as a user, I may have a thread pool of 4 threads for Ignite-related usage, that is also set as asyncContinuationExecutor [1]. Now if I run a lot of concurrent Ignite requests using sync API, all 4 threads will end up blocked on CompletableFutures. When one of the operations completes, we enqueue the completion to that same thread pool, but all threads are blocked on sync APIs, resulting in a deadlock. This can be prevented by using a different asyncContinuationExecutor, but sync API users won't be usually aware of this. [1] https://issues.apache.org/jira/browse/IGNITE-15359 On Wed, Sep 8, 2021 at 10:04 AM Courtney Robinson <courtney.robin...@hypi.io> wrote: > Hi Val, > > I'd highly support an async first API based on CompletionStage > < > https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/CompletionStage.html > > > or > its subtypes like CompletableFuture. > In Ignite 2 we've written a wrapper library around IgniteFuture to provide > CompletionStage instead because many of the newer libs we use support this. > If Ignite 3 went this way it'd remove a lot of boiler plate/wrapper that we > wrote to get what you're suggesting here. > > Regards, > Courtney Robinson > Founder and CEO, Hypi > Tel: ++44 208 123 2413 (GMT+0) <https://hypi.io> > > <https://hypi.io> > https://hypi.io > > > On Wed, Sep 8, 2021 at 12:44 AM Valentin Kulichenko < > valentin.kuliche...@gmail.com> wrote: > > > Igniters, > > > > I would like to gather some opinions on whether we want to focus on sync > vs > > async APIs in Ignite 3. > > > > Here are some initial considerations that I have: > > 1. Ignite 2.x is essentially "sync first". Async APIs exist, but they use > > non-standard IgniteFuture and provide counterintuitive guarantees. In my > > experience, they significantly lack usability, and because of that are > > rarely used. > > 2. In general, however, async execution becomes more and more prominent. > > Something we can't ignore if we want to create a modern framework. > > 3. Still, async support in Java is very limited (especially if compared > to > > other languages, like C# for example). > > > > My current position is the following (happy to discuss): > > 1. We should pay more attention to async APIs. As a general rule, async > API > > should be primary, with the sync version build on top. > > 2. In languages with proper async support (async-await, etc.), we can > skip > > sync API altogether. As an example of this, you can look at the first > > version of the .NET client [1]. It exposes only async methods, and it > > doesn't look like sync counterparts are really needed. > > 3. In Java (as well as other languages where applicable), we will add > sync > > APIs that simply delegate to async APIs. This will help users to avoid > > CompletableFuture if they don't want to use it. > > > > [1] https://github.com/apache/ignite-3/pull/306 > > > > Please share your thoughts. > > > > -Val > > >
