> > > >> >
> > > > > > > > >> >
> > > > > > > > >> > > async API should be primary
> > > > > > > > >> >
> > > > > > > > >> > It should be noted that all our
re 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 ma
> > > > >> > 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 ar
lock.
> > > > >> >
> > > > >> > This can be prevented by using a different
> > > asyncContinuationExecutor,
> > > > >> but
> > > > >> > sync API users won't be usually aware of this.
> > > > &
t
> > > >> > 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 R
> > >> > > Hi Val,
> > >> > >
> > >> > > I'd highly support an async first API based on CompletionStage
> > >> > > <
> > >> > >
> > >> >
> > >>
> >
> https://docs.or
<
> >> > >
> >> >
> >>
> https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/CompletionStage.html
> >> > > >
> >> > > or
> >> > > its subtypes like CompletableFuture.
> >> > > In Ignite 2 we'v
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&
e 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
> 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&
enko <
> 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:
> &
.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 init
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 counte
14 matches
Mail list logo
