To put it another way: - true sync operation completes by itself - sync-over-async operation requires another thread to complete
On Wed, Sep 8, 2021 at 10:15 PM Pavel Tupitsyn <ptupit...@apache.org> wrote: > Val, > > That's exactly what I have in mind. > Yes, we block the user thread, but then we should unblock it by completing > the future. > We can't complete the future from a Netty thread [1], so we'll need some > other thread from some executor. > If there are no threads available (because they are blocked by the sync > API above), the future won't complete => deadlock. > > [1] > https://lists.apache.org/thread.html/r528659381d983a177d779f56ef3d7da6fe17eb3504383f5f87727514%40%3Cdev.ignite.apache.org%3E > > On Wed, Sep 8, 2021 at 9:40 PM Valentin Kulichenko < > valentin.kuliche...@gmail.com> wrote: > >> Pavel, >> >> I might be missing something - could you please elaborate a little more? >> >> When I say "sync on top of async", I basically mean that (for example) >> 'insert(..)' is equivalent to 'insertAsync(..).join()'. In my >> understanding, it only blocks the user's thread. >> >> Am I wrong? Or you have a different implementation in mind? >> >> -Val >> >> On Wed, Sep 8, 2021 at 12:50 AM Pavel Tupitsyn <ptupit...@apache.org> >> wrote: >> >> > 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 >> > > > >> > > >> > >> >
