Alex, > not fully async, since "send" is still used in the user's thread Correct. I've added those details to the IEP. I'll investigate the ways to make this fully non-blocking, but for now let's consider this to be out of scope of this IEP.
> POC for thin client data streamer Very interesting, is there a ticket or IEP to follow? On Fri, Aug 21, 2020 at 11:01 AM Pavel Tupitsyn <[email protected]> wrote: > Val, > > The problems with CompletableFuture in public API are: > * It is a class, not an interface > * It is completable - anyone can call .complete(), which is not what we > want > > There seems to be no clear guidance in Java world on async API design; > however, it is often recommended to return CompletionStage instead of > CompletableFuture > from the public APIs [1] [2], and some products follow this [3]. > > Other products return their own future interface that extends both Future > and CompletionStage, > which seems to be a better alternative to me [4]. > > Thoughts? > > [1] > https://stackoverflow.com/questions/47571117/what-is-the-difference-between-completionstage-and-completablefuture > [2] > https://stackoverflow.com/questions/34930840/should-i-return-completablefuture-or-future-when-defining-api > <https://stackoverflow.com/questions/34930840/should-i-return-completablefuture-or-future-when-defining-api#:~:text=by%20returning%20a%20CompletableFuture%2C%20you,API%2C%20which%20is%20not%20good.> > [3] > https://docs.hazelcast.org/docs/latest/javadoc/com/hazelcast/cache/ICache.html > [4] > https://lettuce.io/lettuce-4/release/api/com/lambdaworks/redis/RedisFuture.html > > On Fri, Aug 21, 2020 at 10:28 AM Alex Plehanov <[email protected]> > wrote: > >> Pavel, >> >> Thanks for the discussion, I've also faced with the necessity of having >> async calls while implementing POC for thin client data streamer [1] and >> solve it similarly (but in my case it's required only for internal >> implementation, so I've only changed the internal API). >> >> I want to note that described in IEP approach (and implemented in POC) is >> not fully async, since "send" is still used in the user's thread. To make >> it fully async we need additional sending thread (since blocking IO is >> used >> for communication with the server). If partition awareness is enabled >> there >> will be 2 threads per each server connection, perhaps we should think >> about >> moving to NIO and introducing some kind of communication thread pool. >> >> [1]: https://github.com/apache/ignite/pull/8175 >> >> пт, 21 авг. 2020 г. в 03:35, Valentin Kulichenko < >> [email protected]>: >> >> > Sounds good. I've added this to the 3.0 roadmap: >> > https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+3.0 >> > >> > Unless there are any objections from others, let's stick with the >> > CompletableFuture for any future development, including the thin client. >> > >> > -Val >> > >> > On Thu, Aug 20, 2020 at 9:30 AM Pavel Tupitsyn <[email protected]> >> > wrote: >> > >> > > Val, no objections from my side. >> > > As noted above, the only benefit of IgniteFuture is consistency across >> > > thin/thick APIs, >> > > which is probably not so important. >> > > >> > > On Thu, Aug 20, 2020 at 6:28 PM Valentin Kulichenko < >> > > [email protected]> wrote: >> > > >> > > > Hi Pavel, >> > > > >> > > > Are there any benefits of IgniteFuture over CompletableFuture? >> > > > >> > > > IgniteFuture was created long ago, during the time when >> > CompletableFuture >> > > > did not exist. There is a big chance that IgniteFuture actually >> became >> > > > redundant at the moment we transitioned to Java8. If that's the >> case, I >> > > > would prefer using CompletableFuture in the thin client and getting >> rid >> > > of >> > > > IgniteFuture altogether in 3.0. >> > > > >> > > > What do you think? >> > > > >> > > > -Val >> > > > >> > > > On Thu, Aug 20, 2020 at 7:19 AM Pavel Tupitsyn < >> [email protected]> >> > > > wrote: >> > > > >> > > > > Igniters, >> > > > > >> > > > > I've prepared an IEP [1], please review and let me know what you >> > think. >> > > > > >> > > > > In particular, I'd like to discuss the Future interface to be >> used: >> > > > > * IgniteFuture is the first candidate - Thin APIs will be >> consistent >> > > with >> > > > > Thick APIs, probably better for existing Ignite users. >> > > > > * CompletableFuture is the standard for async Java APIs. Many >> users >> > may >> > > > > prefer that instead of a custom IgniteFuture. >> > > > > >> > > > > [1] >> > > > > >> > > > > >> > > > >> > > >> > >> https://cwiki.apache.org/confluence/display/IGNITE/IEP-51%3A+Java+Thin+Client+Async+API >> > > > > >> > > > >> > > >> > >> >
