ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ivan Pavlukhin <vololo...@gmail.com>
Subject Re: [DISCUSSION] IgniteFuture class future in Ignite-3.0.
Date Fri, 09 Apr 2021 09:43:39 GMT
Hi Andrey,

I agree that public API based on CompletableFuture might be very
useful. The thing I worry about is that with CompletableFuture used
internally we can miss some important capabilities (e.g. mentioned
cancellation). ReactiveStreams specification on the other hand defines
a lot of interesting and important things and it can serve as guidance
for Ignite developers.

So, my vision here is that it is very important to have well-defined
semantics internally. Introducing public API based on
CompletableFuture is fine as well because enough users can be quite
happy with it.

2021-04-05 14:49 GMT+03:00, Andrey Mashenkov <andrey.mashenkov@gmail.com>:
> Hi Ivan,
>
> JDK flow API looks interesting. I think we should use it abroad.
> Though, Java 14 is not LTS (long-term support) release. I guess many users
> will prefer Java 15,
> but actually, we have no agreement about switching to Java 15 which may
> require some additional efforts.
> For now, we could import the required classes into Ignite module as we've
> done with JSR-166 (concurrent collections).
>
> I think we should use Flow-like API for Queries, Cursors, Compute results
> and even Transactions.
> E.g. reactive transaction API is must have and it can be looked like:
> Transaction.compose(tx -> table1.getAsync(a)).thenApply(tx ->
> table2.putAsync()).thenApply(tx -> tx.commit());
>
> Agree, CompletableFuture looks totally unusable for cases that supposed
> cancellation capabilities, due to broken cancellation semantic [1].
> However, cancellation support for simple table operations doesn't make any
> sense and we still can use CompletableFuture for e.g. table operations
> unless we found it unusable for Transaction API that is not designed yet.
>
> I've looked at reactive API as CompletableFuture replacement for simple
> cases.
> At first glance, it is very complex and may require too much effort on our
> user side, and/or hard to understand for the user.
>
> Maybe it make sense to create an IEP for future replacement with all the
> examples for the table, transaction, compute APIs?
> WDYT?
>
> [1]
> https://stackoverflow.com/questions/43389894/recursively-cancel-an-allof-completablefuture
>
> On Sat, Apr 3, 2021 at 1:40 AM Ivan Pavlukhin <vololo100@gmail.com> wrote:
>
>> Andrey,
>>
>> As you might know Java has it is own Reactive abstractions since 9
>> [1]. Moreover, an original Reactive Streams library has a bridge with
>> Java [2].
>>
>> Personally I do not love CompletableFuture because it's API seems
>> questionable to me in various aspects, e.g. mentioned cancellation.
>> Currently I think that the cleanest way is custom abstractions
>> (possibly implementing CompletionStage) at first. And providing
>> bridges to other APIs (including CompletableFuture) as a next step.
>> Various API integrations can come in form of extensions.
>>
>> > JDK classes are well-known and reactive frameworks usually have
>> converters
>> to/from CompletableFuture [1] [2].
>>
>> Here I have doubts that it is feasible to achieve it fairly. E.g. once
>> again cancellation. While reactive API supports cancellation it will
>> not be possible to cancel computation for anything built from
>> CompletableFuture.
>>
>> [1]
>> https://docs.oracle.com/en/java/javase/14/docs/api/java.base/java/util/concurrent/Flow.Publisher.html
>> [2]
>> https://www.reactive-streams.org/reactive-streams-1.0.3-javadoc/org/reactivestreams/FlowAdapters.html
>>
>> 2021-04-02 12:00 GMT+03:00, Andrey Mashenkov
>> <andrey.mashenkov@gmail.com>:
>> > Ivan,
>> > thanks for the link. I think, now I've got what you mean.
>> >
>> > I don't think we want to have any framework as a dependency and rely on
>> > their lifecycle, roadmaps goals and
>> > bother about compatibility.
>> > JDK classes are well-known and reactive frameworks usually have
>> converters
>> > to/from CompletableFuture [1] [2].
>> > So, users are free to choose any reactive framework.
>> >
>> > I think will need reactive abstractions in near future for Queries API
>> and
>> > maybe Transaction API design.
>> > These projects are good enough where we can get inspiration.
>> >
>> > [1]
>> >
>> https://projectreactor.io/docs/core/release/api/reactor/core/publisher/Mono.html#fromFuture-java.util.concurrent.CompletableFuture-
>> > [2]
>> >
>> https://github.com/ReactiveX/RxJava/blob/3.x/src/main/java/io/reactivex/rxjava3/internal/jdk8/CompletableFromCompletionStage.java
>> >
>> > On Thu, Apr 1, 2021 at 1:29 PM Ivan Pavlukhin <vololo100@gmail.com>
>> wrote:
>> >
>> >> Andrey,
>> >>
>> >> > Reactive abstractions look more suitable for Queries rather than
>> >> > cache/table async operations and don't offer the power of chaining
>> like
>> >> > CompletableStage.
>> >>
>> >> Could you please elaborate what capabilities do you mean? AFAIK there
>> >> are quite powerful APIs for singular reactive abstractions as well.
>> >> E.g. [1].
>> >>
>> >> [1]
>> >>
>> https://projectreactor.io/docs/core/release/api/reactor/core/publisher/Mono.html
>> >>
>> >> 2021-04-01 12:33 GMT+03:00, Andrey Mashenkov
>> >> <andrey.mashenkov@gmail.com>:
>> >> > Val,
>> >> > I just complain JDK CompletableFuture itself is not ideal, but
>> >> > already
>> >> > implemented, well-known and tested.
>> >> > It still a good alternative compared to custom future implementation
>> to
>> >> me.
>> >> >
>> >> > Ok, I feel most of us agree with CompletableFuture as a replacement
>> for
>> >> > custom IgniteFuture.
>> >> > Let's try to use it, but keep in mind that we MUST return a
>> >> > defective
>> >> copy
>> >> > (via copy() or minimalStage()) to user to prevent misusage on the
>> >> > user
>> >> > side.
>> >> > It would be nice if we'll follow the same requirement in our
>> >> > internal
>> >> code,
>> >> > e.g. if a component returns a future that further can be used in
>> >> > other
>> >> > components, especially in custom plugins.
>> >> >
>> >> > Ivan, thanks for the example.
>> >> > Reactive abstractions look more suitable for Queries rather than
>> >> > cache/table async operations and don't offer the power of chaining
>> like
>> >> > CompletableStage.
>> >> > AFAIK, guys who involved in SQL engine development based on Calcite
>> >> already
>> >> > use reactive patterns.
>> >> >
>> >> >
>> >> > On Thu, Apr 1, 2021 at 3:15 AM Ivan Pavlukhin <vololo100@gmail.com>
>> >> wrote:
>> >> >
>> >> >> Folks,
>> >> >>
>> >> >> Regarding Reactive abstractions. While it might look too complex
>> >> >> for
>> >> >> simple KV cases it can be quite powerful for queries. Also there
>> >> >> are
>> >> >> known solutions for cancellation, backpressure and flow control. It
>> >> >> can greatly simplify things for users familiar with Reactive
>> >> >> programming rather than learning Ignite-specific Query/QueryCursor
>> >> >> API.
>> >> >>
>> >> >> Also it looks like there are well-defined semantics [1]. E.g.
>> >> >> cancellation seems to be defined much better than for
>> >> >> CompletableFuture.
>> >> >>
>> >> >> [1]
>> >> >>
>> https://github.com/reactive-streams/reactive-streams-jvm#specification
>> >> >>
>> >> >> 2021-03-31 21:30 GMT+03:00, Valentin Kulichenko <
>> >> >> valentin.kulichenko@gmail.com>:
>> >> >> > Hi Andrey,
>> >> >> >
>> >> >> > Please see below.
>> >> >> >
>> >> >> > -Val
>> >> >> >
>> >> >> > On Wed, Mar 31, 2021 at 7:55 AM Andrey Mashenkov
>> >> >> > <andrey.mashenkov@gmail.com>
>> >> >> > wrote:
>> >> >> >
>> >> >> >> CompletableFuture cancellation will not work as many users
>> >> >> >> expected.
>> >> >> >> Javadoc says:
>> >> >> >> /* Since (unlike {@link FutureTask}) this class has no direct
>> >> >> >> * control over the computation that causes it to be completed,
>> >> >> >> * cancellation is treated as just another form of exceptional
>> >> >> >> * completion.
>> >> >> >> */
>> >> >> >>
>> >> >> >
>> >> >> > Let's not make assumptions about the expectations of the users.
>> >> >> > That's
>> >> >> > exactly why I initially leaned towards a custom interface as
>> >> >> > well,
>> >> >> > but
>> >> >> > that's a mistake.
>> >> >> > Indeed, this contract might look weird to us, because the current
>> >> >> > version
>> >> >> > of Ignite behaves differently. However, there are much more
>> >> >> > developers
>> >> >> > using CompletableFuture and other standard async frameworks, than
>> >> >> > developers using the async functionality of Ignite. Therefore,
>> >> >> > our
>> >> >> > intuitions can easily be wrong.
>> >> >> >
>> >> >> >
>> >> >> >> Completion of a child future doesn't trigger the completion of a
>> >> >> >> parent.
>> >> >> >> So, we will need to extend the future anyway.
>> >> >> >>
>> >> >> >
>> >> >> > First of all, as Pavel mentioned, you can attach your own
>> >> >> > listener
>> >> >> > before
>> >> >> > returning a CompletableFuture to the user. You don't need to
>> extend.
>> >> >> > Second of all, there is still a discussion to be had on whether
>> >> >> > the
>> >> >> parent
>> >> >> > needs to be completed. I don't actually think it's obvious, and
>> most
>> >> >> likely
>> >> >> > it's case by case. With CompletableFuture you have enough
>> >> >> > flexibility
>> >> >> > to
>> >> >> > control the behavior.
>> >> >> >
>> >> >> >
>> >> >> >>
>> >> >> >> Also, cancel() method contract differs from IgniteFuture in 2.0,
>> >> >> >> Completable method return true if the future was cancelled,
>> >> >> >> but IgniteFuture return true only if it wasn't cancel prior the
>> >> >> >> call.
>> >> >> >> Thus, if cancel() was called twice we will have different
>> >> >> >> results
>> >> >> >> for
>> >> >> >> CompletableFuture and IgniteFuture,
>> >> >> >> that makes CompletableFuture barely usable for our internal
>> >> >> >> purposes.
>> >> >> >>
>> >> >> >
>> >> >> > It doesn't really matter how IgniteFuture in 2.0 behaves. It was
>> >> >> > created
>> >> >> > long before continuations and other async concepts became
>> mainstream
>> >> >> > (in
>> >> >> > Java world at least).
>> >> >> > Also, we don't have to use it for internal purposes, of course.
>> >> >> > I'm
>> >> >> > only
>> >> >> > talking about public APIs.
>> >> >> >
>> >> >> >
>> >> >> >>
>> >> >> >> BTW, CompletableFuture.anyOf() still can be used, see
>> >> >> >> CompletionStage.toCompletableFuture() contract.
>> >> >> >>
>> >> >> >
>> >> >> > In my view, this actually kills the idea of a custom future.
>> >> Basically,
>> >> >> > the proposal is to introduce a custom entity to restrict access
>> >> >> > to
>> >> some
>> >> >> of
>> >> >> > the CompletableFuture methods, but then allow to convert this
>> custom
>> >> >> entity
>> >> >> > to a CompletableFuture that has all the methods. This makes zero
>> >> >> > sense
>> >> >> > to
>> >> >> > me.
>> >> >> >
>> >> >> >
>> >> >> >>
>> >> >> >> The more I learn about CompletableFuture the stronger my opinion
>> >> about
>> >> >> >> overriding it.
>> >> >> >>
>> >> >> >>
>> >> >> >> On Wed, Mar 31, 2021 at 9:31 AM Denis Garus
>> >> >> >> <garus.d.g@gmail.com>
>> >> >> wrote:
>> >> >> >>
>> >> >> >> > > Stripping them from such functionality, which they are used
>> to,
>> >> is
>> >> >> >> > > most
>> >> >> >> > likely a bad idea.
>> >> >> >> >
>> >> >> >> > Completely agree with this point of view.
>> >> >> >> > Moreover, a user can pass CompletableFuture to another library
>> to
>> >> do
>> >> >> >> > any
>> >> >> >> > manipulations.
>> >> >> >> > So if we want to introduce our class instead of the java
>> >> >> >> > class,
>> >> >> >> > we
>> >> >> >> > should
>> >> >> >> > have solid arguments;
>> >> >> >> > otherwise, it can be a reason for irritation.
>> >> >> >> >
>> >> >> >> > ср, 31 мар. 2021 г. в 09:06, Pavel Tupitsyn <
>> ptupitsyn@apache.org
>> >> >:
>> >> >> >> >
>> >> >> >> > > Val,
>> >> >> >> > >
>> >> >> >> > > > we can have an IgniteFuture that extends
>> >> >> >> > > > CompletableFuture.
>> >> >> >> > > > This might be useful if want the cancel() operation to
>> cancel
>> >> >> >> > > > the
>> >> >> >> > > > underlying operation
>> >> >> >> > >
>> >> >> >> > > I think we can subscribe to the cancellation of the
>> >> >> CompletableFuture
>> >> >> >> > > and cancel the underlying operation without an extra class,
>> >> >> >> > > something like
>> >> >> >> > >
>> >> >> >> > >         fut.exceptionally(t -> {
>> >> >> >> > >             if (t instanceof CancellationException) {
>> >> >> >> > >                 // Cancel Ignite operation
>> >> >> >> > >             }
>> >> >> >> > >         });
>> >> >> >> > >
>> >> >> >> > > On Wed, Mar 31, 2021 at 7:45 AM Valentin Kulichenko <
>> >> >> >> > > valentin.kulichenko@gmail.com> wrote:
>> >> >> >> > >
>> >> >> >> > > > These are actually some interesting points. As I'm
>> >> >> >> > > > thinking
>> >> more
>> >> >> >> about
>> >> >> >> > > > this, I'm leaning towards changing my opinion and voting
>> >> >> >> > > > for
>> >> the
>> >> >> >> > > > CompletableFuture. Here is my reasoning.
>> >> >> >> > > >
>> >> >> >> > > > First, it's important to keep in mind that
>> >> >> >> > > > CompletableFuture
>> >> >> >> > > > is
>> >> >> not
>> >> >> >> an
>> >> >> >> > > > interface that we will implement, it's an implemented
>> >> >> >> > > > class.
>> >> >> >> Therefore,
>> >> >> >> > > > some of the concerns around complete() and cancel() method
>> >> >> >> > > > are
>> >> >> >> > > > not
>> >> >> >> > really
>> >> >> >> > > > relevant -- it's not up to us how these methods behave,
>> >> >> >> > > > they're
>> >> >> >> already
>> >> >> >> > > > implemented.
>> >> >> >> > > >
>> >> >> >> > > > Second, CompletableFuture does provide some useful
>> >> functionality
>> >> >> >> (anyOf
>> >> >> >> > > is
>> >> >> >> > > > one of the examples). I can even envision users wanting to
>> >> >> complete
>> >> >> >> the
>> >> >> >> > > > future under certain circumstances, e.g. after a timeout,
>> >> >> >> > > > using
>> >> >> >> > > > the completeOnTimeout method. Stripping them from such
>> >> >> >> > > > functionality,
>> >> >> >> > > which
>> >> >> >> > > > they are used to, is most likely a bad idea.
>> >> >> >> > > >
>> >> >> >> > > > And finally, we can have an IgniteFuture that extends
>> >> >> >> > CompletableFuture.
>> >> >> >> > > > This might be useful if want the cancel() operation to
>> cancel
>> >> >> >> > > > the
>> >> >> >> > > > underlying operation. This way we keep all the
>> >> >> >> > > > functionality
>> >> >> >> > > > of
>> >> >> >> > > > CompletableFuture while keeping a certain amount of
>> >> >> >> > > > flexibility
>> >> >> for
>> >> >> >> > > > specific cases.
>> >> >> >> > > >
>> >> >> >> > > > Thoughts?
>> >> >> >> > > >
>> >> >> >> > > > -Val
>> >> >> >> > > >
>> >> >> >> > > >
>> >> >> >> > > > On Tue, Mar 30, 2021 at 5:36 AM Denis Garus
>> >> >> >> > > > <garus.d.g@gmail.com>
>> >> >> >> > wrote:
>> >> >> >> > > >
>> >> >> >> > > > > > Completing future from outside will never respect
>> >> >> >> > > > > > other
>> >> >> >> subscribers
>> >> >> >> > > > that
>> >> >> >> > > > > > may expect other guatantees.
>> >> >> >> > > > >
>> >> >> >> > > > > For example, if we talk about public API like
>> >> >> >> > > > > IgniteCache,
>> >> >> >> > > > > what
>> >> >> >> > > > subscribers
>> >> >> >> > > > > may expect other guatantees?
>> >> >> >> > > > > IMHO, the best solution is to get the well-known
>> >> >> >> > > > > standard
>> >> >> >> > > > > interface
>> >> >> >> > to
>> >> >> >> > > a
>> >> >> >> > > > > user, and he will be happy.
>> >> >> >> > > > >
>> >> >> >> > > > > But when we talk about internal classes like "exchange
>> >> future"
>> >> >> >> > > > > they
>> >> >> >> > > could
>> >> >> >> > > > > be custom futures if convenient.
>> >> >> >> > > > >
>> >> >> >> > > > > вт, 30 мар. 2021 г. в 15:25, Atri Sharma
>> >> >> >> > > > > <atri@apache.org
>> >:
>> >> >> >> > > > >
>> >> >> >> > > > > > IMO the only way Ignite should cancel computations is
>> iff
>> >> >> >> > > > > > cancel
>> >> >> >> > > method
>> >> >> >> > > > > is
>> >> >> >> > > > > > invoked, not implicitly if complete is invoked.
>> >> >> >> > > > > >
>> >> >> >> > > > > > On Tue, 30 Mar 2021 at 4:58 PM, Denis Garus
>> >> >> >> > > > > > <garus.d.g@gmail.com
>> >> >> >> >
>> >> >> >> > > > wrote:
>> >> >> >> > > > > >
>> >> >> >> > > > > > > Hello!
>> >> >> >> > > > > > >
>> >> >> >> > > > > > > > Let's say a user started a compute with fut =
>> >> >> >> > > > compute.runAsync(task);
>> >> >> >> > > > > > > > and now calls fut.complete(someVal); Does this
>> >> >> >> > > > > > > > mean
>> >> that
>> >> >> >> Ignite
>> >> >> >> > > no
>> >> >> >> > > > > > longer
>> >> >> >> > > > > > > needs to execute the task?
>> >> >> >> > > > > > > > If the task is currently running, does it need to
>> >> >> >> > > > > > > > be
>> >> >> >> canceled?
>> >> >> >> > > > > > >
>> >> >> >> > > > > > > Yes, this case looks like Ignite should cancel
>> >> >> >> > > > > > > computations
>> >> >> >> > > because a
>> >> >> >> > > > > > user
>> >> >> >> > > > > > > wants to complete the future. Why not?
>> >> >> >> > > > > > > If there will be an opportunity to cancel a future,
>> why
>> >> is
>> >> >> it
>> >> >> >> > > > > > > a
>> >> >> >> > bad
>> >> >> >> > > > > > option
>> >> >> >> > > > > > > to finish a future through a complete() method?
>> >> >> >> > > > > > >
>> >> >> >> > > > > > > > If you look at Ignite-2 code, you may found a
>> >> >> >> > > > > > > > number
>> >> >> >> > > > > > > > of
>> >> >> >> places
>> >> >> >> > > > where
>> >> >> >> > > > > we
>> >> >> >> > > > > > > return e.g. exchange futures or partition release
>> >> futures.
>> >> >> >> > > > > > > > Assume the impact if we will return
>> CompletableFuture
>> >> >> >> instead,
>> >> >> >> > > > which
>> >> >> >> > > > > > can
>> >> >> >> > > > > > > be completed in 3-rd party plugin by mistake?
>> >> >> >> > > > > > >
>> >> >> >> > > > > > > If exchange futures or partition release futures can
>> be
>> >> >> >> returned
>> >> >> >> > to
>> >> >> >> > > > > 3-rd
>> >> >> >> > > > > > > party plugin by mistake, it is poor encapsulation.
>> >> >> >> > > > > > > And if it will be IgniteFuter rather than
>> >> CompletedFuture,
>> >> >> >> > anyway,
>> >> >> >> > > > this
>> >> >> >> > > > > > can
>> >> >> >> > > > > > > harm.
>> >> >> >> > > > > > >
>> >> >> >> > > > > > > вт, 30 мар. 2021 г. в 13:14, Andrey Mashenkov <
>> >> >> >> > > > > > andrey.mashenkov@gmail.com
>> >> >> >> > > > > > > >:
>> >> >> >> > > > > > >
>> >> >> >> > > > > > > > Guys,
>> >> >> >> > > > > > > >
>> >> >> >> > > > > > > > I want to remember there is one more point to pay
>> >> >> attention
>> >> >> >> to.
>> >> >> >> > > > > > > > Extending Future and CompletableStage is more than
>> >> >> >> > > > > > > > just
>> >> >> >> > prevents
>> >> >> >> > > > > > > unexpected
>> >> >> >> > > > > > > > behavior if a user completed the future.
>> >> >> >> > > > > > > >
>> >> >> >> > > > > > > > First of all, it helps us to write safer code as
>> >> >> >> > > > > > > > we
>> >> >> >> > > > > > > > won't
>> >> >> a
>> >> >> >> > > method
>> >> >> >> > > > > > > contract
>> >> >> >> > > > > > > > exposed such methods as to a user as to a
>> >> >> >> > > > > > > > developer.
>> >> >> >> > > > > > > > If you look at Ignite-2 code, you may found a
>> >> >> >> > > > > > > > number
>> >> >> >> > > > > > > > of
>> >> >> >> places
>> >> >> >> > > > where
>> >> >> >> > > > > we
>> >> >> >> > > > > > > > return e.g. exchange futures or partition release
>> >> >> >> > > > > > > > futures.
>> >> >> >> > > > > > > > Assume the impact if we will return
>> CompletableFuture
>> >> >> >> instead,
>> >> >> >> > > > which
>> >> >> >> > > > > > can
>> >> >> >> > > > > > > be
>> >> >> >> > > > > > > > completed in 3-rd party plugin by mistake?
>> >> >> >> > > > > > > >
>> >> >> >> > > > > > > > The suggested approach allows us to don't bother
>> >> >> >> > > > > > > > if
>> a
>> >> >> >> > > > > CompletableFuture
>> >> >> >> > > > > > > has
>> >> >> >> > > > > > > > to be wrapped or not.
>> >> >> >> > > > > > > >
>> >> >> >> > > > > > > >
>> >> >> >> > > > > > > > On Tue, Mar 30, 2021 at 12:22 PM Alexey Goncharuk
>> >> >> >> > > > > > > > <
>> >> >> >> > > > > > > > alexey.goncharuk@gmail.com> wrote:
>> >> >> >> > > > > > > >
>> >> >> >> > > > > > > > > Ivan,
>> >> >> >> > > > > > > > >
>> >> >> >> > > > > > > > > My concern with the concept of a user completing
>> >> >> >> > > > > > > > > the
>> >> >> >> > > > > > > > > future
>> >> >> >> > > > > returned
>> >> >> >> > > > > > > from
>> >> >> >> > > > > > > > > Ignite public API is that it is unclear how to
>> >> >> >> > > > > > > > > interpret
>> >> >> >> this
>> >> >> >> > > > > action
>> >> >> >> > > > > > > > (this
>> >> >> >> > > > > > > > > backs Val's message).
>> >> >> >> > > > > > > > > Let's say a user started a compute with fut =
>> >> >> >> > > > > compute.runAsync(task);
>> >> >> >> > > > > > > and
>> >> >> >> > > > > > > > > now calls fut.complete(someVal); Does this mean
>> >> >> >> > > > > > > > > that
>> >> >> >> > > > > > > > > Ignite
>> >> >> >> > no
>> >> >> >> > > > > longer
>> >> >> >> > > > > > > > needs
>> >> >> >> > > > > > > > > to execute the task? If the task is currently
>> >> running,
>> >> >> >> > > > > > > > > does
>> >> >> >> > it
>> >> >> >> > > > need
>> >> >> >> > > > > > to
>> >> >> >> > > > > > > be
>> >> >> >> > > > > > > > > canceled?
>> >> >> >> > > > > > > > >
>> >> >> >> > > > > > > > > Using CompletableFuture.anyOf() is a good
>> >> >> >> > > > > > > > > instrument
>> >> >> >> > > > > > > > > in
>> >> >> >> this
>> >> >> >> > > case
>> >> >> >> > > > > > > because
>> >> >> >> > > > > > > > > it makes the 'first future wins' contract
>> >> >> >> > > > > > > > > explicit
>> >> >> >> > > > > > > > > in
>> >> >> the
>> >> >> >> > code.
>> >> >> >> > > > > > Besides
>> >> >> >> > > > > > > > > that, the point regarding the cancel() method is
>> >> >> >> > > > > > > > > valid,
>> >> >> >> > > > > > > > > and
>> >> >> >> > we
>> >> >> >> > > > will
>> >> >> >> > > > > > > need
>> >> >> >> > > > > > > > > some custom mechanics to cancel a computation,
>> >> >> >> > > > > > > > > so
>> a
>> >> >> >> > > > > > > > > custom
>> >> >> >> > > > > interface
>> >> >> >> > > > > > > that
>> >> >> >> > > > > > > > > simply extends both Future and CompletableStage
>> >> >> >> > > > > > > > > seems
>> >> >> >> > > reasonable
>> >> >> >> > > > to
>> >> >> >> > > > > > me.
>> >> >> >> > > > > > > > >
>> >> >> >> > > > > > > > > --AG
>> >> >> >> > > > > > > > >
>> >> >> >> > > > > > > > > пн, 29 мар. 2021 г. в 09:12, Ivan Pavlukhin <
>> >> >> >> > > vololo100@gmail.com
>> >> >> >> > > > >:
>> >> >> >> > > > > > > > >
>> >> >> >> > > > > > > > > > Val,
>> >> >> >> > > > > > > > > >
>> >> >> >> > > > > > > > > > There were enough hype around Reactive
>> >> >> >> > > > > > > > > > programming
>> >> >> past
>> >> >> >> > > years.
>> >> >> >> > > > I
>> >> >> >> > > > > > > > > > remind a lot of talks about RxJava. And I
>> suppose
>> >> it
>> >> >> >> worth
>> >> >> >> > to
>> >> >> >> > > > > > > consider
>> >> >> >> > > > > > > > > > it. But it requires some time to study modern
>> >> trends
>> >> >> to
>> >> >> >> > make
>> >> >> >> > > a
>> >> >> >> > > > > > > choice.
>> >> >> >> > > > > > > > > > So far I am not ready to facilitate Reactive
>> >> >> >> > > > > > > > > > API
>> >> for
>> >> >> >> Ignite
>> >> >> >> > > 3.
>> >> >> >> > > > > > > > > >
>> >> >> >> > > > > > > > > > Regarding CompletableFuture.
>> >> >> >> > > > > > > > > >
>> >> >> >> > > > > > > > > > > The point is that currently a future
>> >> >> >> > > > > > > > > > > returned
>> >> from
>> >> >> >> > > > > > > > > > > any
>> >> >> >> of
>> >> >> >> > > > > > Ignite's
>> >> >> >> > > > > > > > > async
>> >> >> >> > > > > > > > > > > operations is supposed to be completed with
>> >> >> >> > > > > > > > > > > a
>> >> >> >> > > > > > > > > > > value
>> >> >> >> only
>> >> >> >> > by
>> >> >> >> > > > > > Ignite
>> >> >> >> > > > > > > > > > itself,
>> >> >> >> > > > > > > > > > > not by the user. If we follow the same
>> approach
>> >> in
>> >> >> >> Ignite
>> >> >> >> > > 3,
>> >> >> >> > > > > > > > returning
>> >> >> >> > > > > > > > > > > CompletableFuture is surely wrong in my
>> >> >> >> > > > > > > > > > > view.
>> >> >> >> > > > > > > > > >
>> >> >> >> > > > > > > > > > My first thoughts was similar. But later I
>> >> >> >> > > > > > > > > > thought
>> >> >> what
>> >> >> >> > > > > > > > > > a
>> >> >> >> > > user
>> >> >> >> > > > > > would
>> >> >> >> > > > > > > > > > like do with returned future. And one of cases
>> >> >> >> > > > > > > > > > I
>> >> >> >> > > > > > > > > > imagined
>> >> >> >> > > was a
>> >> >> >> > > > > > case
>> >> >> >> > > > > > > > > > of alternative result. E.g. a user uses Ignite
>> >> >> >> > > > > > > > > > and
>> >> >> >> another
>> >> >> >> > > data
>> >> >> >> > > > > > > source
>> >> >> >> > > > > > > > > > in his application. He wants to use a value
>> >> >> >> > > > > > > > > > arrived
>> >> >> >> faster.
>> >> >> >> > > He
>> >> >> >> > > > > > > > > > combines 2 futures like
>> >> >> >> > > > > > > > > > CompletableFuture.anyOf(...).
>> >> >> >> > > > > Consequently
>> >> >> >> > > > > > > > > > even if we prohibit
>> >> >> >> > > > > > > > > > CompletableFuture.complete(...)
>> >> >> >> > > explicitly
>> >> >> >> > > > > then
>> >> >> >> > > > > > > it
>> >> >> >> > > > > > > > > > will be possible to create a combination that
>> >> >> >> > > > > > > > > > will
>> >> >> >> > > > > > > > > > allow
>> >> >> >> > > > > premature
>> >> >> >> > > > > > > > > > future completion. After all generally
>> >> >> >> > > > > > > > > > CompletableFuture
>> >> >> >> > is a
>> >> >> >> > > > > > > > > > placeholder for async computaion result and if
>> >> >> >> > > > > > > > > > a
>> >> >> >> > > > > > > > > > user
>> >> >> >> wants
>> >> >> >> > > to
>> >> >> >> > > > > > > > > > substitute result returned from Ignite why
>> should
>> >> we
>> >> >> >> > disallow
>> >> >> >> > > > him
>> >> >> >> > > > > > to
>> >> >> >> > > > > > > > > > do it?
>> >> >> >> > > > > > > > > >
>> >> >> >> > > > > > > > > > Also I found one more suspicious thing with
>> >> >> >> > > CompletableFuture.
>> >> >> >> > > > As
>> >> >> >> > > > > > it
>> >> >> >> > > > > > > > > > is a concrete class it implements a cancel()
>> >> method.
>> >> >> >> > > > > > > > > > And
>> >> >> >> > as I
>> >> >> >> > > > see
>> >> >> >> > > > > > the
>> >> >> >> > > > > > > > > > implementation does not try to cancel
>> >> >> >> > > > > > > > > > underlying
>> >> >> >> > > computations.
>> >> >> >> > > > Is
>> >> >> >> > > > > > not
>> >> >> >> > > > > > > > > > it a problem?
>> >> >> >> > > > > > > > > >
>> >> >> >> > > > > > > > > > 2021-03-29 7:30 GMT+03:00, Valentin Kulichenko
>> >> >> >> > > > > > > > > > <
>> >> >> >> > > > > > > > > > valentin.kulichenko@gmail.com>:
>> >> >> >> > > > > > > > > > > Ivan,
>> >> >> >> > > > > > > > > > >
>> >> >> >> > > > > > > > > > > It's not really about the "harm", but more
>> >> >> >> > > > > > > > > > > about
>> >> >> >> > > > > > > > > > > "what
>> >> >> >> > > should
>> >> >> >> > > > > we
>> >> >> >> > > > > > do
>> >> >> >> > > > > > > > if
>> >> >> >> > > > > > > > > > this
>> >> >> >> > > > > > > > > > > method is called?". Imagine the following
>> code:
>> >> >> >> > > > > > > > > > >
>> >> >> >> > > > > > > > > > > CompletableFuture<String> fut =
>> >> >> >> > > > > > > > > > > cache.getAsync(key);
>> >> >> >> > > > > > > > > > > fut.complete("something");
>> >> >> >> > > > > > > > > > >
>> >> >> >> > > > > > > > > > > What should happen in this case?
>> >> >> >> > > > > > > > > > >
>> >> >> >> > > > > > > > > > > The point is that currently a future
>> >> >> >> > > > > > > > > > > returned
>> >> from
>> >> >> >> > > > > > > > > > > any
>> >> >> >> of
>> >> >> >> > > > > > Ignite's
>> >> >> >> > > > > > > > > async
>> >> >> >> > > > > > > > > > > operations is supposed to be completed with
>> >> >> >> > > > > > > > > > > a
>> >> >> >> > > > > > > > > > > value
>> >> >> >> only
>> >> >> >> > by
>> >> >> >> > > > > > Ignite
>> >> >> >> > > > > > > > > > itself,
>> >> >> >> > > > > > > > > > > not by the user. If we follow the same
>> approach
>> >> in
>> >> >> >> Ignite
>> >> >> >> > > 3,
>> >> >> >> > > > > > > > returning
>> >> >> >> > > > > > > > > > > CompletableFuture is surely wrong in my
>> >> >> >> > > > > > > > > > > view.
>> >> >> >> > > > > > > > > > >
>> >> >> >> > > > > > > > > > > At the same time, if we take a fundamentally
>> >> >> >> > > > > > > > > > > different
>> >> >> >> > > route
>> >> >> >> > > > > with
>> >> >> >> > > > > > > the
>> >> >> >> > > > > > > > > > async
>> >> >> >> > > > > > > > > > > APIs, this whole discussion might become
>> >> >> >> > > > > > > > > > > irrelevant.
>> >> >> >> For
>> >> >> >> > > > > example,
>> >> >> >> > > > > > > can
>> >> >> >> > > > > > > > > you
>> >> >> >> > > > > > > > > > > elaborate on your thinking around the
>> >> >> >> > > > > > > > > > > reactive
>> >> >> >> > > > > > > > > > > API?
>> >> >> >> > > > > > > > > > > Do
>> >> >> >> > you
>> >> >> >> > > > have
>> >> >> >> > > > > > any
>> >> >> >> > > > > > > > > > > specifics in mind?
>> >> >> >> > > > > > > > > > >
>> >> >> >> > > > > > > > > > > -Val
>> >> >> >> > > > > > > > > > >
>> >> >> >> > > > > > > > > > > On Sat, Mar 27, 2021 at 9:18 PM Ivan
>> >> >> >> > > > > > > > > > > Pavlukhin
>> >> >> >> > > > > > > > > > > <
>> >> >> >> > > > > > > vololo100@gmail.com>
>> >> >> >> > > > > > > > > > wrote:
>> >> >> >> > > > > > > > > > >
>> >> >> >> > > > > > > > > > >> > The methods below shouldn't be accessible
>> >> >> >> > > > > > > > > > >> > for
>> >> >> >> > > > > > > > > > >> > user:
>> >> >> >> > > > > > > > > > >> > complete()
>> >> >> >> > > > > > > > > > >> > completeExceptionaly()
>> >> >> >> > > > > > > > > > >>
>> >> >> >> > > > > > > > > > >> Folks, in case of user-facing API, do you
>> >> >> >> > > > > > > > > > >> think
>> >> >> >> > > > > > > > > > >> there
>> >> >> >> > is a
>> >> >> >> > > > > real
>> >> >> >> > > > > > > harm
>> >> >> >> > > > > > > > > > >> in allowing a user to manually "complete" a
>> >> >> >> > > > > > > > > > >> future?
>> >> >> >> > > > > > > > > > >> I
>> >> >> >> > > > suppose
>> >> >> >> > > > > a
>> >> >> >> > > > > > > user
>> >> >> >> > > > > > > > > > >> employs some post-processing for future
>> >> >> >> > > > > > > > > > >> results
>> >> >> >> > > > > > > > > > >> and
>> >> >> >> > > > > potentially
>> >> >> >> > > > > > > > wants
>> >> >> >> > > > > > > > > > >> to have control of these results as well.
>> E.g.
>> >> >> >> premature
>> >> >> >> > > > > > > completion
>> >> >> >> > > > > > > > in
>> >> >> >> > > > > > > > > > >> case when a result is no longer needed is
>> >> >> >> > > > > > > > > > >> possible
>> >> >> >> > usage.
>> >> >> >> > > > > > > > > > >>
>> >> >> >> > > > > > > > > > >> Also I thinkg it might be a good time to
>> >> >> >> > > > > > > > > > >> ponder
>> >> >> >> > > > > > > > > > >> about
>> >> >> >> > > > > > > Future/Promise
>> >> >> >> > > > > > > > > > >> APIs in general. Why such API is our
>> >> >> >> > > > > > > > > > >> choice?
>> >> >> >> > > > > > > > > > >> Can
>> >> >> >> > > > > > > > > > >> we
>> >> >> >> > choose
>> >> >> >> > > > > e.g.
>> >> >> >> > > > > > > > > > >> Reactive API style instead?
>> >> >> >> > > > > > > > > > >>
>> >> >> >> > > > > > > > > > >> 2021-03-27 0:33 GMT+03:00, Valentin
>> Kulichenko
>> >> >> >> > > > > > > > > > >> <
>> >> >> >> > > > > > > > > > >> valentin.kulichenko@gmail.com>:
>> >> >> >> > > > > > > > > > >> > Andrey,
>> >> >> >> > > > > > > > > > >> >
>> >> >> >> > > > > > > > > > >> > I see. So in a nutshell, you're saying
>> >> >> >> > > > > > > > > > >> > that
>> >> >> >> > > > > > > > > > >> > we
>> >> >> >> > > > > > > > > > >> > want
>> >> >> >> to
>> >> >> >> > > > > return
>> >> >> >> > > > > > a
>> >> >> >> > > > > > > > > future
>> >> >> >> > > > > > > > > > >> that
>> >> >> >> > > > > > > > > > >> > the user's code is not allowed to
>> >> >> >> > > > > > > > > > >> > complete.
>> >> >> >> > > > > > > > > > >> > In
>> >> >> >> > > > > > > > > > >> > this
>> >> >> >> > > case,
>> >> >> >> > > > I
>> >> >> >> > > > > > > think
>> >> >> >> > > > > > > > > it's
>> >> >> >> > > > > > > > > > >> > clear that CompletableFuture is not what
>> >> >> >> > > > > > > > > > >> > we
>> >> >> >> > > > > > > > > > >> > need.
>> >> >> >> > > > > > > > > > >> > We
>> >> >> >> > > > > actually
>> >> >> >> > > > > > > > need a
>> >> >> >> > > > > > > > > > >> > NonCompletableFuture :)
>> >> >> >> > > > > > > > > > >> >
>> >> >> >> > > > > > > > > > >> > My vote is for the custom interface.
>> >> >> >> > > > > > > > > > >> >
>> >> >> >> > > > > > > > > > >> > -Val
>> >> >> >> > > > > > > > > > >> >
>> >> >> >> > > > > > > > > > >> > On Fri, Mar 26, 2021 at 2:25 AM Andrey
>> >> >> >> > > > > > > > > > >> > Mashenkov
>> >> >> >> > > > > > > > > > >> > <andrey.mashenkov@gmail.com>
>> >> >> >> > > > > > > > > > >> > wrote:
>> >> >> >> > > > > > > > > > >> >
>> >> >> >> > > > > > > > > > >> >> Val,
>> >> >> >> > > > > > > > > > >> >>
>> >> >> >> > > > > > > > > > >> >> The methods below shouldn't be
>> >> >> >> > > > > > > > > > >> >> accessible
>> >> >> >> > > > > > > > > > >> >> for
>> >> >> >> > > > > > > > > > >> >> user:
>> >> >> >> > > > > > > > > > >> >> complete()
>> >> >> >> > > > > > > > > > >> >> completeExceptionaly()
>> >> >> >> > > > > > > > > > >> >>
>> >> >> >> > > > > > > > > > >> >> Returning CompletableFuture we must
>> >> >> >> > > > > > > > > > >> >> always
>> >> >> >> > > > > > > > > > >> >> make
>> >> >> a
>> >> >> >> > copy
>> >> >> >> > > to
>> >> >> >> > > > > > > prevent
>> >> >> >> > > > > > > > > the
>> >> >> >> > > > > > > > > > >> >> original future from being completed by
>> >> >> >> > > > > > > > > > >> >> mistake.
>> >> >> >> > > > > > > > > > >> >> I think it will NOT be enough to do that
>> >> >> returing
>> >> >> >> the
>> >> >> >> > > > > future
>> >> >> >> > > > > > to
>> >> >> >> > > > > > > > the
>> >> >> >> > > > > > > > > > >> >> end-user, but from every critical module
>> to
>> >> >> >> > > > > > > > > > >> >> the
>> >> >> >> > outside
>> >> >> >> > > > of
>> >> >> >> > > > > > the
>> >> >> >> > > > > > > > > > module,
>> >> >> >> > > > > > > > > > >> >> e.g. to plugins. The impact of
>> >> >> >> > > > > > > > > > >> >> disclosing
>> >> >> >> > > ExchangeFuture,
>> >> >> >> > > > > > > > > > >> >> PartitionReleaseFuture to plugins may be
>> >> >> serious.
>> >> >> >> > > > > > > > > > >> >>
>> >> >> >> > > > > > > > > > >> >> IgniteFuture<T> extends Future<T>,
>> >> >> >> CompletionStage<T>
>> >> >> >> > > > which
>> >> >> >> > > > > > > > > > >> >> implementation
>> >> >> >> > > > > > > > > > >> >> will just wrap CompletableFuture these
>> >> >> >> > > > > > > > > > >> >> issues
>> >> >> >> > > > > > > > > > >> >> will
>> >> >> >> be
>> >> >> >> > > > > > resolved
>> >> >> >> > > > > > > in
>> >> >> >> > > > > > > > > > >> natural
>> >> >> >> > > > > > > > > > >> >> way.
>> >> >> >> > > > > > > > > > >> >> In addition we can force
>> >> toCompletableFuture()
>> >> >> >> method
>> >> >> >> > > to
>> >> >> >> > > > > > > return a
>> >> >> >> > > > > > > > > > >> >> defensive
>> >> >> >> > > > > > > > > > >> >> copy(), that resolves the last concern.
>> >> >> >> > > > > > > > > > >> >>
>> >> >> >> > > > > > > > > > >> >>
>> >> >> >> > > > > > > > > > >> >> On Fri, Mar 26, 2021 at 11:38 AM
>> Konstantin
>> >> >> Orlov
>> >> >> >> > > > > > > > > > >> >> <korlov@gridgain.com>
>> >> >> >> > > > > > > > > > >> >> wrote:
>> >> >> >> > > > > > > > > > >> >>
>> >> >> >> > > > > > > > > > >> >> > CompletableFuture seems a better
>> >> >> >> > > > > > > > > > >> >> > option
>> >> >> >> > > > > > > > > > >> >> > to
>> >> >> >> > > > > > > > > > >> >> > me.
>> >> >> >> > > > > > > > > > >> >> >
>> >> >> >> > > > > > > > > > >> >> > --
>> >> >> >> > > > > > > > > > >> >> > Regards,
>> >> >> >> > > > > > > > > > >> >> > Konstantin Orlov
>> >> >> >> > > > > > > > > > >> >> >
>> >> >> >> > > > > > > > > > >> >> >
>> >> >> >> > > > > > > > > > >> >> >
>> >> >> >> > > > > > > > > > >> >> >
>> >> >> >> > > > > > > > > > >> >> > > On 26 Mar 2021, at 11:07, Pavel
>> >> >> >> > > > > > > > > > >> >> > > Tupitsyn
>> >> <
>> >> >> >> > > > > > > > ptupitsyn@apache.org
>> >> >> >> > > > > > > > > >
>> >> >> >> > > > > > > > > > >> >> > > wrote:
>> >> >> >> > > > > > > > > > >> >> > >
>> >> >> >> > > > > > > > > > >> >> > > On the one hand, I agree with
>> >> >> >> > > > > > > > > > >> >> > > Alexey.
>> >> >> >> > > > > > > > > > >> >> > > CompletableFuture has complete*
>> methods
>> >> >> which
>> >> >> >> > > should
>> >> >> >> > > > > not
>> >> >> >> > > > > > be
>> >> >> >> > > > > > > > > > >> available
>> >> >> >> > > > > > > > > > >> >> to
>> >> >> >> > > > > > > > > > >> >> > > the user code.
>> >> >> >> > > > > > > > > > >> >> > > This can be solved with a simple
>> >> interface
>> >> >> >> > > > > > > > > > >> >> > > like
>> >> >> >> > we
>> >> >> >> > > do
>> >> >> >> > > > > in
>> >> >> >> > > > > > > Thin
>> >> >> >> > > > > > > > > > >> Client:
>> >> >> >> > > > > > > > > > >> >> > > IgniteClientFuture<T> extends
>> >> >> >> > > > > > > > > > >> >> > > Future<T>,
>> >> >> >> > > > > > CompletionStage<T>
>> >> >> >> > > > > > > > > > >> >> > >
>> >> >> >> > > > > > > > > > >> >> > >
>> >> >> >> > > > > > > > > > >> >> > > On the other hand:
>> >> >> >> > > > > > > > > > >> >> > > - CompletionStage has
>> >> >> >> > > > > > > > > > >> >> > > toCompletableFuture
>> >> >> >> anyway
>> >> >> >> > > > > (rather
>> >> >> >> > > > > > > > weird)
>> >> >> >> > > > > > > > > > >> >> > > - Other libraries use
>> CompletableFuture
>> >> >> >> > > > > > > > > > >> >> > > and
>> >> >> >> > > > > > > > > > >> >> > > it
>> >> >> >> > > seems
>> >> >> >> > > > to
>> >> >> >> > > > > > be
>> >> >> >> > > > > > > > fine
>> >> >> >> > > > > > > > > > >> >> > > - Using CompletableFuture is the
>> >> >> >> > > > > > > > > > >> >> > > simplest
>> >> >> >> > approach
>> >> >> >> > > > > > > > > > >> >> > >
>> >> >> >> > > > > > > > > > >> >> > >
>> >> >> >> > > > > > > > > > >> >> > > So I lean towards CompletableFuture
>> >> >> >> > > > > > > > > > >> >> > > too.
>> >> >> >> > > > > > > > > > >> >> > >
>> >> >> >> > > > > > > > > > >> >> > > On Fri, Mar 26, 2021 at 10:46 AM
>> Alexey
>> >> >> >> > Kukushkin <
>> >> >> >> > > > > > > > > > >> >> > kukushkinalexey@gmail.com>
>> >> >> >> > > > > > > > > > >> >> > > wrote:
>> >> >> >> > > > > > > > > > >> >> > >
>> >> >> >> > > > > > > > > > >> >> > >> I do not like Java's
>> CompletableFuture
>> >> >> >> > > > > > > > > > >> >> > >> and
>> >> >> >> > prefer
>> >> >> >> > > > our
>> >> >> >> > > > > > own
>> >> >> >> > > > > > > > > Future
>> >> >> >> > > > > > > > > > >> >> > (revised
>> >> >> >> > > > > > > > > > >> >> > >> IgniteFuture).
>> >> >> >> > > > > > > > > > >> >> > >>
>> >> >> >> > > > > > > > > > >> >> > >> My understanding of the Future (or
>> >> >> >> > > > > > > > > > >> >> > >> Promise)
>> >> >> >> > > pattern
>> >> >> >> > > > in
>> >> >> >> > > > > > > > general
>> >> >> >> > > > > > > > > > is
>> >> >> >> > > > > > > > > > >> >> having
>> >> >> >> > > > > > > > > > >> >> > >> two separate APIs:
>> >> >> >> > > > > > > > > > >> >> > >>
>> >> >> >> > > > > > > > > > >> >> > >>   1. Server-side: create, set
>> >> >> >> > > > > > > > > > >> >> > >> result,
>> >> >> >> > > > > > > > > > >> >> > >> raise
>> >> >> >> > error,
>> >> >> >> > > > > > cancel
>> >> >> >> > > > > > > > from
>> >> >> >> > > > > > > > > > >> >> > >> server.
>> >> >> >> > > > > > > > > > >> >> > >>   2. Client-side: get result,
>> >> >> >> > > > > > > > > > >> >> > >> handle
>> >> >> >> > > > > > > > > > >> >> > >> error,
>> >> >> >> > cancel
>> >> >> >> > > > > from
>> >> >> >> > > > > > > > client
>> >> >> >> > > > > > > > > > >> >> > >>
>> >> >> >> > > > > > > > > > >> >> > >> Java's CompletableFuture looks like
>> >> >> >> > > > > > > > > > >> >> > >> both
>> >> >> the
>> >> >> >> > > > > client-side
>> >> >> >> > > > > > > and
>> >> >> >> > > > > > > > > > >> >> > >> server-side API. The "Completeable"
>> >> >> >> > > > > > > > > > >> >> > >> prefix
>> >> >> >> > > > > > > > > > >> >> > >> in
>> >> >> >> > the
>> >> >> >> > > > name
>> >> >> >> > > > > > is
>> >> >> >> > > > > > > > > > already
>> >> >> >> > > > > > > > > > >> >> > confusing
>> >> >> >> > > > > > > > > > >> >> > >> for a client since it cannot
>> >> >> >> > > > > > > > > > >> >> > >> "complete"
>> >> >> >> > > > > > > > > > >> >> > >> an
>> >> >> >> > > > operation,
>> >> >> >> > > > > > > only a
>> >> >> >> > > > > > > > > > >> >> > >> server
>> >> >> >> > > > > > > > > > >> >> can.
>> >> >> >> > > > > > > > > > >> >> > >>
>> >> >> >> > > > > > > > > > >> >> > >> I would create our own IgniteFuture
>> >> >> >> > > > > > > > > > >> >> > >> adding
>> >> >> >> > > > client-side
>> >> >> >> > > > > > > > > > >> functionality
>> >> >> >> > > > > > > > > > >> >> we
>> >> >> >> > > > > > > > > > >> >> > >> currently miss (like client-side
>> >> >> >> cancellation).
>> >> >> >> > > > > > > > > > >> >> > >>
>> >> >> >> > > > > > > > > > >> >> > >>
>> >> >> >> > > > > > > > > > >> >> > >> пт, 26 мар. 2021 г. в 01:08,
>> >> >> >> > > > > > > > > > >> >> > >> Valentin
>> >> >> >> > Kulichenko <
>> >> >> >> > > > > > > > > > >> >> > >> valentin.kulichenko@gmail.com>:
>> >> >> >> > > > > > > > > > >> >> > >>
>> >> >> >> > > > > > > > > > >> >> > >>> Andrey,
>> >> >> >> > > > > > > > > > >> >> > >>>
>> >> >> >> > > > > > > > > > >> >> > >>> Can you compile a full list of
>> >> >> >> > > > > > > > > > >> >> > >>> these
>> >> >> >> > > > > > > > > > >> >> > >>> risky
>> >> >> >> > > methods,
>> >> >> >> > > > > and
>> >> >> >> > > > > > > > > > >> >> > >>> elaborate
>> >> >> >> > > > > > > > > > >> >> > >>> on
>> >> >> >> > > > > > > > > > >> >> > what
>> >> >> >> > > > > > > > > > >> >> > >>> the risks are?
>> >> >> >> > > > > > > > > > >> >> > >>>
>> >> >> >> > > > > > > > > > >> >> > >>> Generally, CompletableFuture is a
>> >> >> >> > > > > > > > > > >> >> > >>> much
>> >> >> >> > > > > > > > > > >> >> > >>> better
>> >> >> >> > > > option,
>> >> >> >> > > > > > > > because
>> >> >> >> > > > > > > > > > >> >> > >>> it's
>> >> >> >> > > > > > > > > > >> >> > >>> standard. But we need to make sure
>> it
>> >> >> >> actually
>> >> >> >> > > fits
>> >> >> >> > > > > our
>> >> >> >> > > > > > > > needs
>> >> >> >> > > > > > > > > > >> >> > >>> and
>> >> >> >> > > > > > > > > > >> >> > doesn't
>> >> >> >> > > > > > > > > > >> >> > >>> do more harm than good.
>> >> >> >> > > > > > > > > > >> >> > >>>
>> >> >> >> > > > > > > > > > >> >> > >>> -Val
>> >> >> >> > > > > > > > > > >> >> > >>>
>> >> >> >> > > > > > > > > > >> >> > >>> On Thu, Mar 25, 2021 at 12:23 PM
>> >> >> >> > > > > > > > > > >> >> > >>> Alexei
>> >> >> >> > > Scherbakov
>> >> >> >> > > > <
>> >> >> >> > > > > > > > > > >> >> > >>> alexey.scherbakoff@gmail.com>
>> wrote:
>> >> >> >> > > > > > > > > > >> >> > >>>
>> >> >> >> > > > > > > > > > >> >> > >>>> I think both options are fine,
>> >> >> >> > > > > > > > > > >> >> > >>>> but
>> >> >> >> personally
>> >> >> >> > > lean
>> >> >> >> > > > > > > toward
>> >> >> >> > > > > > > > > > >> >> > >>>> CompletableFuture.
>> >> >> >> > > > > > > > > > >> >> > >>>>
>> >> >> >> > > > > > > > > > >> >> > >>>> чт, 25 мар. 2021 г. в 17:56, Atri
>> >> >> >> > > > > > > > > > >> >> > >>>> Sharma
>> >> >> <
>> >> >> >> > > > > > > atri@apache.org
>> >> >> >> > > > > > > > >:
>> >> >> >> > > > > > > > > > >> >> > >>>>
>> >> >> >> > > > > > > > > > >> >> > >>>>> I would suggest using
>> >> >> >> > > > > > > > > > >> >> > >>>>> CompletableFuture
>> >> >> >> > > > > > > > > > >> >> > >>>>> --
>> >> >> >> I
>> >> >> >> > > > don't
>> >> >> >> > > > > > see
>> >> >> >> > > > > > > a
>> >> >> >> > > > > > > > > need
>> >> >> >> > > > > > > > > > >> for
>> >> >> >> > > > > > > > > > >> >> > >>>>> a
>> >> >> >> > > > > > > > > > >> >> > >>>> custom
>> >> >> >> > > > > > > > > > >> >> > >>>>> interface that is unique to us.
>> >> >> >> > > > > > > > > > >> >> > >>>>>
>> >> >> >> > > > > > > > > > >> >> > >>>>> It also allows a lower barrier
>> >> >> >> > > > > > > > > > >> >> > >>>>> for
>> >> new
>> >> >> >> > > > contributors
>> >> >> >> > > > > > for
>> >> >> >> > > > > > > > > > >> >> understanding
>> >> >> >> > > > > > > > > > >> >> > >>>>> existing code
>> >> >> >> > > > > > > > > > >> >> > >>>>>
>> >> >> >> > > > > > > > > > >> >> > >>>>> On Thu, 25 Mar 2021, 20:18
>> >> >> >> > > > > > > > > > >> >> > >>>>> Andrey
>> >> >> >> Mashenkov,
>> >> >> >> > <
>> >> >> >> > > > > > > > > > >> >> > >>> andrey.mashenkov@gmail.com
>> >> >> >> > > > > > > > > > >> >> > >>>>>
>> >> >> >> > > > > > > > > > >> >> > >>>>> wrote:
>> >> >> >> > > > > > > > > > >> >> > >>>>>
>> >> >> >> > > > > > > > > > >> >> > >>>>>> Hi Igniters,
>> >> >> >> > > > > > > > > > >> >> > >>>>>>
>> >> >> >> > > > > > > > > > >> >> > >>>>>> I'd like to start a discussion
>> >> >> >> > > > > > > > > > >> >> > >>>>>> about
>> >> >> >> > replacing
>> >> >> >> > > > our
>> >> >> >> > > > > > > > custom
>> >> >> >> > > > > > > > > > >> >> > >>> IgniteFuture
>> >> >> >> > > > > > > > > > >> >> > >>>>>> class with CompletableFuture -
>> >> >> >> > > > > > > > > > >> >> > >>>>>> existed
>> >> >> >> > > > > > > > > > >> >> > >>>>>> JDK
>> >> >> >> > > class
>> >> >> >> > > > > > > > > > >> >> > >>>>>> or rework it's implementation
>> >> >> >> > > > > > > > > > >> >> > >>>>>> (like
>> >> >> some
>> >> >> >> > other
>> >> >> >> > > > > > > products
>> >> >> >> > > > > > > > > > done)
>> >> >> >> > > > > > > > > > >> to
>> >> >> >> > > > > > > > > > >> >> > >>>>>> a
>> >> >> >> > > > > > > > > > >> >> > >>>>>> composition of CompletionStage
>> and
>> >> >> >> > > > > > > > > > >> >> > >>>>>> Future
>> >> >> >> > > > > > interfaces.
>> >> >> >> > > > > > > > > > >> >> > >>>>>> or maybe other option if you
>> >> >> >> > > > > > > > > > >> >> > >>>>>> have
>> >> any
>> >> >> >> ideas.
>> >> >> >> > > Do
>> >> >> >> > > > > you?
>> >> >> >> > > > > > > > > > >> >> > >>>>>>
>> >> >> >> > > > > > > > > > >> >> > >>>>>> 1. The first approach pros and
>> >> >> >> > > > > > > > > > >> >> > >>>>>> cons
>> >> >> >> > > > > > > > > > >> >> > >>>>>> are
>> >> >> >> > > > > > > > > > >> >> > >>>>>> + Well-known JDK class
>> >> >> >> > > > > > > > > > >> >> > >>>>>> + Already implemented
>> >> >> >> > > > > > > > > > >> >> > >>>>>> - It is a class, not an
>> interface.
>> >> >> >> > > > > > > > > > >> >> > >>>>>> - Expose some potentially
>> >> >> >> > > > > > > > > > >> >> > >>>>>> harmful
>> >> >> >> > > > > > > > > > >> >> > >>>>>> methods
>> >> >> >> > like
>> >> >> >> > > > > > > > > "complete()".
>> >> >> >> > > > > > > > > > >> >> > >>>>>>
>> >> >> >> > > > > > > > > > >> >> > >>>>>> On the other side, it has
>> >> >> >> > > > > > > > > > >> >> > >>>>>> copy()
>> >> >> >> > > > > > > > > > >> >> > >>>>>> method
>> >> >> >> > > > > > > > > > >> >> > >>>>>> to
>> >> >> >> > > > create
>> >> >> >> > > > > > > > > defensive
>> >> >> >> > > > > > > > > > >> copy
>> >> >> >> > > > > > > > > > >> >> > >> and
>> >> >> >> > > > > > > > > > >> >> > >>>>>> minimalCompletionStage() to
>> >> >> >> > > > > > > > > > >> >> > >>>>>> restrict
>> >> >> >> harmful
>> >> >> >> > > > > method
>> >> >> >> > > > > > > > usage.
>> >> >> >> > > > > > > > > > >> >> > >>>>>> Thus, this look like an
>> applicable
>> >> >> >> solution,
>> >> >> >> > > but
>> >> >> >> > > > > we
>> >> >> >> > > > > > > > should
>> >> >> >> > > > > > > > > > be
>> >> >> >> > > > > > > > > > >> >> > >> careful
>> >> >> >> > > > > > > > > > >> >> > >>>>>> exposing internal future to the
>> >> >> outside.
>> >> >> >> > > > > > > > > > >> >> > >>>>>>
>> >> >> >> > > > > > > > > > >> >> > >>>>>> 2. The second approach is to
>> >> >> >> > > > > > > > > > >> >> > >>>>>> implement
>> >> >> >> > > > > > > > > > >> >> > >>>>>> our
>> >> >> >> > own
>> >> >> >> > > > > > > interface
>> >> >> >> > > > > > > > > > like
>> >> >> >> > > > > > > > > > >> >> > >>>>>> the
>> >> >> >> > > > > > > > > > >> >> > >>> next
>> >> >> >> > > > > > > > > > >> >> > >>>>> one:
>> >> >> >> > > > > > > > > > >> >> > >>>>>>
>> >> >> >> > > > > > > > > > >> >> > >>>>>> interface IgniteFuture<T>
>> >> >> >> > > > > > > > > > >> >> > >>>>>> extends
>> >> >> >> > > > > > CompletableStage<T>,
>> >> >> >> > > > > > > > > > >> Future<T>
>> >> >> >> > > > > > > > > > >> >> > >>>>>> {
>> >> >> >> > > > > > > > > > >> >> > >>>>>> }
>> >> >> >> > > > > > > > > > >> >> > >>>>>>
>> >> >> >> > > > > > > > > > >> >> > >>>>>> Pros and cons are
>> >> >> >> > > > > > > > > > >> >> > >>>>>> + Our interfaces/classes
>> contracts
>> >> >> >> > > > > > > > > > >> >> > >>>>>> will
>> >> >> >> > expose
>> >> >> >> > > > an
>> >> >> >> > > > > > > > > interface
>> >> >> >> > > > > > > > > > >> >> > >>>>>> rather
>> >> >> >> > > > > > > > > > >> >> > >>> than
>> >> >> >> > > > > > > > > > >> >> > >>>>>> concrete implementation.
>> >> >> >> > > > > > > > > > >> >> > >>>>>> + All methods are safe.
>> >> >> >> > > > > > > > > > >> >> > >>>>>> - Some implementation is
>> required.
>> >> >> >> > > > > > > > > > >> >> > >>>>>> - CompletableStage has a method
>> >> >> >> > > > > > toCompletableFuture()
>> >> >> >> > > > > > > > and
>> >> >> >> > > > > > > > > > can
>> >> >> >> > > > > > > > > > >> be
>> >> >> >> > > > > > > > > > >> >> > >>>>> converted
>> >> >> >> > > > > > > > > > >> >> > >>>>>> to CompletableFuture. This
>> >> >> >> > > > > > > > > > >> >> > >>>>>> should
>> >> >> >> > > > > > > > > > >> >> > >>>>>> be
>> >> >> >> > > supported.
>> >> >> >> > > > > > > > > > >> >> > >>>>>>
>> >> >> >> > > > > > > > > > >> >> > >>>>>> However, we still could wrap
>> >> >> >> > CompletableFuture
>> >> >> >> > > > and
>> >> >> >> > > > > > > don't
>> >> >> >> > > > > > > > > > >> >> > >>>>>> bother
>> >> >> >> > > > > > > > > > >> >> > >> about
>> >> >> >> > > > > > > > > > >> >> > >>>>>> creating a defensive copy.
>> >> >> >> > > > > > > > > > >> >> > >>>>>>
>> >> >> >> > > > > > > > > > >> >> > >>>>>>
>> >> >> >> > > > > > > > > > >> >> > >>>>>> Other project experience:
>> >> >> >> > > > > > > > > > >> >> > >>>>>> * Spotify uses
>> >> >> >> > > > > > > > > > >> >> > >>>>>> CompletableFuture
>> >> >> >> > > > > > > > > > >> >> > >>>>>> directly
>> >> >> >> > [1].
>> >> >> >> > > > > > > > > > >> >> > >>>>>> * Redis goes the second
>> >> >> >> > > > > > > > > > >> >> > >>>>>> approach
>> >> >> >> > > > > > > > > > >> >> > >>>>>> [2]
>> >> >> >> > > > > > > > > > >> >> > >>>>>> * Vertx explicitly extends
>> >> >> >> CompletableFuture
>> >> >> >> > > > [3].
>> >> >> >> > > > > > > > However,
>> >> >> >> > > > > > > > > > >> >> > >>>>>> they
>> >> >> >> > > > > > > > > > >> >> > >> have
>> >> >> >> > > > > > > > > > >> >> > >>>>> custom
>> >> >> >> > > > > > > > > > >> >> > >>>>>> future classes and a number of
>> >> >> >> > > > > > > > > > >> >> > >>>>>> helpers
>> >> >> >> that
>> >> >> >> > > > could
>> >> >> >> > > > > be
>> >> >> >> > > > > > > > > > replaced
>> >> >> >> > > > > > > > > > >> >> > >>>>>> with
>> >> >> >> > > > > > > > > > >> >> > >>>>>> CompletableStage. Maybe it is
>> just
>> >> >> >> > > > > > > > > > >> >> > >>>>>> a
>> >> >> >> > legacy.'
>> >> >> >> > > > > > > > > > >> >> > >>>>>>
>> >> >> >> > > > > > > > > > >> >> > >>>>>> Any thoughts?
>> >> >> >> > > > > > > > > > >> >> > >>>>>>
>> >> >> >> > > > > > > > > > >> >> > >>>>>> [1]
>> >> >> >> > > > > > > > > > >> >> > >>>>>>
>> >> >> >> > > > > > > > > > >> >> > >>>>>>
>> >> >> >> > > > > > > > > > >> >> > >>>>>
>> >> >> >> > > > > > > > > > >> >> > >>>>
>> >> >> >> > > > > > > > > > >> >> > >>>
>> >> >> >> > > > > > > > > > >> >> > >>
>> >> >> >> > > > > > > > > > >> >> >
>> >> >> >> > > > > > > > > > >> >>
>> >> >> >> > > > > > > > > > >>
>> >> >> >> > > > > > > > > >
>> >> >> >> > > > > > > > >
>> >> >> >> > > > > > > >
>> >> >> >> > > > > > >
>> >> >> >> > > > > >
>> >> >> >> > > > >
>> >> >> >> > > >
>> >> >> >> > >
>> >> >> >> >
>> >> >> >>
>> >> >>
>> >>
>> https://spotify.github.io/completable-futures/apidocs/com/spotify/futures/ConcurrencyReducer.html
>> >> >> >> > > > > > > > > > >> >> > >>>>>> [2]
>> >> >> >> > > > > > > > > > >> >> > >>>>>>
>> >> >> >> > > > > > > > > > >> >> > >>>>>>
>> >> >> >> > > > > > > > > > >> >> > >>>>>
>> >> >> >> > > > > > > > > > >> >> > >>>>
>> >> >> >> > > > > > > > > > >> >> > >>>
>> >> >> >> > > > > > > > > > >> >> > >>
>> >> >> >> > > > > > > > > > >> >> >
>> >> >> >> > > > > > > > > > >> >>
>> >> >> >> > > > > > > > > > >>
>> >> >> >> > > > > > > > > >
>> >> >> >> > > > > > > > >
>> >> >> >> > > > > > > >
>> >> >> >> > > > > > >
>> >> >> >> > > > > >
>> >> >> >> > > > >
>> >> >> >> > > >
>> >> >> >> > >
>> >> >> >> >
>> >> >> >>
>> >> >>
>> >>
>> https://lettuce.io/lettuce-4/release/api/com/lambdaworks/redis/RedisFuture.html
>> >> >> >> > > > > > > > > > >> >> > >>>>>> [3]
>> >> >> >> > > > > > > > > > >> >> > >>>>>>
>> >> >> >> > > > > > > > > > >> >> > >>>>>>
>> >> >> >> > > > > > > > > > >> >> > >>>>>
>> >> >> >> > > > > > > > > > >> >> > >>>>
>> >> >> >> > > > > > > > > > >> >> > >>>
>> >> >> >> > > > > > > > > > >> >> > >>
>> >> >> >> > > > > > > > > > >> >> >
>> >> >> >> > > > > > > > > > >> >>
>> >> >> >> > > > > > > > > > >>
>> >> >> >> > > > > > > > > >
>> >> >> >> > > > > > > > >
>> >> >> >> > > > > > > >
>> >> >> >> > > > > > >
>> >> >> >> > > > > >
>> >> >> >> > > > >
>> >> >> >> > > >
>> >> >> >> > >
>> >> >> >> >
>> >> >> >>
>> >> >>
>> >>
>> https://javadoc.io/static/org.jspare.vertx/vertx-jspare/1.1.0-M03/org/jspare/vertx/concurrent/VertxCompletableFuture.html
>> >> >> >> > > > > > > > > > >> >> > >>>>>> --
>> >> >> >> > > > > > > > > > >> >> > >>>>>> Best regards,
>> >> >> >> > > > > > > > > > >> >> > >>>>>> Andrey V. Mashenkov
>> >> >> >> > > > > > > > > > >> >> > >>>>>>
>> >> >> >> > > > > > > > > > >> >> > >>>>>
>> >> >> >> > > > > > > > > > >> >> > >>>>
>> >> >> >> > > > > > > > > > >> >> > >>>>
>> >> >> >> > > > > > > > > > >> >> > >>>> --
>> >> >> >> > > > > > > > > > >> >> > >>>>
>> >> >> >> > > > > > > > > > >> >> > >>>> Best regards,
>> >> >> >> > > > > > > > > > >> >> > >>>> Alexei Scherbakov
>> >> >> >> > > > > > > > > > >> >> > >>>>
>> >> >> >> > > > > > > > > > >> >> > >>>
>> >> >> >> > > > > > > > > > >> >> > >>
>> >> >> >> > > > > > > > > > >> >> > >>
>> >> >> >> > > > > > > > > > >> >> > >> --
>> >> >> >> > > > > > > > > > >> >> > >> Best regards,
>> >> >> >> > > > > > > > > > >> >> > >> Alexey
>> >> >> >> > > > > > > > > > >> >> > >>
>> >> >> >> > > > > > > > > > >> >> >
>> >> >> >> > > > > > > > > > >> >> >
>> >> >> >> > > > > > > > > > >> >>
>> >> >> >> > > > > > > > > > >> >> --
>> >> >> >> > > > > > > > > > >> >> Best regards,
>> >> >> >> > > > > > > > > > >> >> Andrey V. Mashenkov
>> >> >> >> > > > > > > > > > >> >>
>> >> >> >> > > > > > > > > > >> >
>> >> >> >> > > > > > > > > > >>
>> >> >> >> > > > > > > > > > >>
>> >> >> >> > > > > > > > > > >> --
>> >> >> >> > > > > > > > > > >>
>> >> >> >> > > > > > > > > > >> Best regards,
>> >> >> >> > > > > > > > > > >> Ivan Pavlukhin
>> >> >> >> > > > > > > > > > >>
>> >> >> >> > > > > > > > > > >
>> >> >> >> > > > > > > > > >
>> >> >> >> > > > > > > > > >
>> >> >> >> > > > > > > > > > --
>> >> >> >> > > > > > > > > >
>> >> >> >> > > > > > > > > > Best regards,
>> >> >> >> > > > > > > > > > Ivan Pavlukhin
>> >> >> >> > > > > > > > > >
>> >> >> >> > > > > > > > >
>> >> >> >> > > > > > > >
>> >> >> >> > > > > > > >
>> >> >> >> > > > > > > > --
>> >> >> >> > > > > > > > Best regards,
>> >> >> >> > > > > > > > Andrey V. Mashenkov
>> >> >> >> > > > > > > >
>> >> >> >> > > > > > >
>> >> >> >> > > > > > --
>> >> >> >> > > > > > Regards,
>> >> >> >> > > > > >
>> >> >> >> > > > > > Atri
>> >> >> >> > > > > > Apache Concerted
>> >> >> >> > > > > >
>> >> >> >> > > > >
>> >> >> >> > > >
>> >> >> >> > >
>> >> >> >> >
>> >> >> >>
>> >> >> >>
>> >> >> >> --
>> >> >> >> Best regards,
>> >> >> >> Andrey V. Mashenkov
>> >> >> >>
>> >> >> >
>> >> >>
>> >> >>
>> >> >> --
>> >> >>
>> >> >> Best regards,
>> >> >> Ivan Pavlukhin
>> >> >>
>> >> >>
>> >> >
>> >> > --
>> >> > Best regards,
>> >> > Andrey V. Mashenkov
>> >> >
>> >>
>> >>
>> >> --
>> >>
>> >> Best regards,
>> >> Ivan Pavlukhin
>> >>
>> >>
>> >
>> > --
>> > Best regards,
>> > Andrey V. Mashenkov
>> >
>>
>>
>> --
>>
>> Best regards,
>> Ivan Pavlukhin
>>
>>
>
> --
> Best regards,
> Andrey V. Mashenkov
>


-- 

Best regards,
Ivan Pavlukhin

Mime
View raw message