Pavel, > Very interesting, is there a ticket or IEP to follow? No, there is no ticket or IEP. I will create ticket, IEP and dev-list discussion after benchmarking of POC implementation.
пт, 21 авг. 2020 г. в 12:17, Pavel Tupitsyn <ptupit...@apache.org>: > 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 <ptupit...@apache.org> > 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 <plehanov.a...@gmail.com> > > 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 < > >> valentin.kuliche...@gmail.com>: > >> > >> > 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 <ptupit...@apache.org> > >> > 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 < > >> > > valentin.kuliche...@gmail.com> 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 < > >> ptupit...@apache.org> > >> > > > 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 > >> > > > > > >> > > > > >> > > > >> > > >> > > >
