[DISCUSSION] IgniteFuture class future in Ignite-3.0.

[Andrey Mashenkov <an...@gmail.com>]

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

Re: [DISCUSSION] IgniteFuture class future in Ignite-3.0.

[Ivan Pavlukhin <vo...@gmail.com>]

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 <an...@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 <vo...@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
>> <an...@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 <vo...@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
>> >> <an...@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 <vo...@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
>> >> >> > <an...@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
>> >> >> >> <ga...@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
>> >> >> >> > > > <ga...@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
>> >> >> >> > > > > > > > > > >> > <an...@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
>> >> >> >> > > > > > > > > > >> >> <ko...@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

Re: [DISCUSSION] IgniteFuture class future in Ignite-3.0.

[Andrey Mashenkov <an...@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 <vo...@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 <an...@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 <vo...@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
> >> <an...@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 <vo...@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
> >> >> > <an...@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 <ga...@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
> >> >> >> > > > <ga...@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
> >> >> >> > > > > > > > > > >> > <an...@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
> >> >> >> > > > > > > > > > >> >> <ko...@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

Re: [DISCUSSION] IgniteFuture class future in Ignite-3.0.

[Ivan Pavlukhin <vo...@gmail.com>]

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 <an...@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 <vo...@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
>> <an...@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 <vo...@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
>> >> > <an...@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 <ga...@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
>> >> >> > > > <ga...@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 <at...@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
>> >> >> > > > > > > > > > >> > <an...@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
>> >> >> > > > > > > > > > >> >> <ko...@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

Re: [DISCUSSION] IgniteFuture class future in Ignite-3.0.

[Andrey Mashenkov <an...@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 <vo...@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 <an...@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 <vo...@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
> >> > <an...@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 <ga...@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
> >> >> > > > <ga...@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 <at...@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
> >> >> > > > > > > > > > >> > <an...@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
> >> >> > > > > > > > > > >> >> <ko...@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

Re: [DISCUSSION] IgniteFuture class future in Ignite-3.0.

[Ivan Pavlukhin <vo...@gmail.com>]

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 <an...@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 <vo...@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
>> > <an...@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 <ga...@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 <pt...@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
>> >> > > > <ga...@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 <at...@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
>> >> > > > > > > > > > >> > <an...@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
>> >> > > > > > > > > > >> >> <ko...@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

Re: [DISCUSSION] IgniteFuture class future in Ignite-3.0.

[Andrey Mashenkov <an...@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 <vo...@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
> > <an...@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 <ga...@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 <pt...@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 <ga...@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 <at...@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
> >> > > > > > > > > > >> > <an...@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
> >> > > > > > > > > > >> >> <ko...@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

Re: [DISCUSSION] IgniteFuture class future in Ignite-3.0.

[Ivan Pavlukhin <vo...@gmail.com>]

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 <va...@gmail.com>:
> Hi Andrey,
>
> Please see below.
>
> -Val
>
> On Wed, Mar 31, 2021 at 7:55 AM Andrey Mashenkov
> <an...@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 <ga...@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 <pt...@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 <ga...@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 <at...@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
>> > > > > > > > > > >> > <an...@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
>> > > > > > > > > > >> >> <ko...@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

Re: [DISCUSSION] IgniteFuture class future in Ignite-3.0.

[Valentin Kulichenko <va...@gmail.com>]

Hi Andrey,

Please see below.

-Val

On Wed, Mar 31, 2021 at 7:55 AM Andrey Mashenkov <an...@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 <ga...@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 <pt...@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 <ga...@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 <at...@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
> > > > > > > > > > >> > <an...@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
> > > > > > > > > > >> >> <ko...@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
>

Re: [DISCUSSION] IgniteFuture class future in Ignite-3.0.

[Andrey Mashenkov <an...@gmail.com>]

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.
*/
Completion of a child future doesn't trigger the completion of a parent.
So, we will need to extend the future anyway.

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.

BTW, CompletableFuture.anyOf() still can be used, see
CompletionStage.toCompletableFuture() contract.

The more I learn about CompletableFuture the stronger my opinion about
overriding it.


On Wed, Mar 31, 2021 at 9:31 AM Denis Garus <ga...@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 <pt...@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 <ga...@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 <at...@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 <ga...@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
> > > > > > > > > >> > <an...@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
> > > > > > > > > >> >> <ko...@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

Re: [DISCUSSION] IgniteFuture class future in Ignite-3.0.

[Denis Garus <ga...@gmail.com>]

> 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 <pt...@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 <ga...@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 <at...@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 <ga...@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
> > > > > > > > >> > <an...@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
> > > > > > > > >> >> <ko...@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
> > > >
> > >
> >
>

Re: [DISCUSSION] IgniteFuture class future in Ignite-3.0.

[Pavel Tupitsyn <pt...@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 <ga...@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 <at...@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 <ga...@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
> > > > > > > >> > <an...@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
> > > > > > > >> >> <ko...@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
> > >
> >
>

Re: [DISCUSSION] IgniteFuture class future in Ignite-3.0.

[Valentin Kulichenko <va...@gmail.com>]

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 <ga...@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 <at...@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 <ga...@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 <vo...@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
> > > > > > >> > <an...@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
> > > > > > >> >> <ko...@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
> >
>

Re: [DISCUSSION] IgniteFuture class future in Ignite-3.0.

[Denis Garus <ga...@gmail.com>]

> 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 <at...@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 <ga...@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 <vo...@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
> > > > > >> > <an...@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
> > > > > >> >> <ko...@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
>

Re: [DISCUSSION] IgniteFuture class future in Ignite-3.0.

[Atri Sharma <at...@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 <ga...@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 <vo...@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
> > > > >> > <an...@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
> > > > >> >> <ko...@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

Re: [DISCUSSION] IgniteFuture class future in Ignite-3.0.

[Andrey Mashenkov <an...@gmail.com>]

>
> 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?

Future has cancel() method for this.
Completing future from outside will never respect other subscribers that
may expect other guatantees.

>
> 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.
>
IgniteFuture contract will not have complete() or similar methods, but we a
free to pass any implementation.
Obviously, if a user casts the future to CompletableFuture or uses a
reflection to access IgniteFutureImpl hidden methods -
that means the user breaks the contract and CompletableFuture defensive
copy will not help either.


On Tue, Mar 30, 2021 at 2:28 PM Denis Garus <ga...@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 <vo...@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
> > > > >> > <an...@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
> > > > >> >> <ko...@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
> >
>


-- 
Best regards,
Andrey V. Mashenkov

Re: [DISCUSSION] IgniteFuture class future in Ignite-3.0.

[Denis Garus <ga...@gmail.com>]

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 <an...@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 <vo...@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 <vo...@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
> > > >> > <an...@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
> > > >> >> <ko...@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
>

Re: [DISCUSSION] IgniteFuture class future in Ignite-3.0.

[Andrey Mashenkov <an...@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 <vo...@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 <vo...@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
> > >> > <an...@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
> > >> >> <ko...@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 <at...@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

Re: [DISCUSSION] IgniteFuture class future in Ignite-3.0.

[Alexey Goncharuk <al...@gmail.com>]

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 <vo...@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 <vo...@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
> >> > <an...@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
> >> >> <ko...@gridgain.com>
> >> >> wrote:
> >> >>
> >> >> > CompletableFuture seems a better option to me.
> >> >> >
> >> >> > --
> >> >> > Regards,
> >> >> > Konstantin Orlov
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >> > > On 26 Mar 2021, at 11:07, Pavel Tupitsyn <pt...@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 <at...@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
>

Re: [DISCUSSION] IgniteFuture class future in Ignite-3.0.

[Ivan Pavlukhin <vo...@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 <va...@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 <vo...@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
>> > <an...@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
>> >> <ko...@gridgain.com>
>> >> wrote:
>> >>
>> >> > CompletableFuture seems a better option to me.
>> >> >
>> >> > --
>> >> > Regards,
>> >> > Konstantin Orlov
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > > On 26 Mar 2021, at 11:07, Pavel Tupitsyn <pt...@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 <at...@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

Re: [DISCUSSION] IgniteFuture class future in Ignite-3.0.

[Valentin Kulichenko <va...@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 <vo...@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
> > <an...@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 <ko...@gridgain.com>
> >> wrote:
> >>
> >> > CompletableFuture seems a better option to me.
> >> >
> >> > --
> >> > Regards,
> >> > Konstantin Orlov
> >> >
> >> >
> >> >
> >> >
> >> > > On 26 Mar 2021, at 11:07, Pavel Tupitsyn <pt...@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 <at...@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
>

Re: [DISCUSSION] IgniteFuture class future in Ignite-3.0.

[Ivan Pavlukhin <vo...@gmail.com>]

> 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 <va...@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
> <an...@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 <ko...@gridgain.com>
>> wrote:
>>
>> > CompletableFuture seems a better option to me.
>> >
>> > --
>> > Regards,
>> > Konstantin Orlov
>> >
>> >
>> >
>> >
>> > > On 26 Mar 2021, at 11:07, Pavel Tupitsyn <pt...@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 <at...@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

Re: [DISCUSSION] IgniteFuture class future in Ignite-3.0.

[Valentin Kulichenko <va...@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 <an...@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 <ko...@gridgain.com>
> wrote:
>
> > CompletableFuture seems a better option to me.
> >
> > --
> > Regards,
> > Konstantin Orlov
> >
> >
> >
> >
> > > On 26 Mar 2021, at 11:07, Pavel Tupitsyn <pt...@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 <at...@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
>

Re: [DISCUSSION] IgniteFuture class future in Ignite-3.0.

[Andrey Mashenkov <an...@gmail.com>]

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 <ko...@gridgain.com>
wrote:

> CompletableFuture seems a better option to me.
>
> --
> Regards,
> Konstantin Orlov
>
>
>
>
> > On 26 Mar 2021, at 11:07, Pavel Tupitsyn <pt...@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 <at...@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

Re: [DISCUSSION] IgniteFuture class future in Ignite-3.0.

[Konstantin Orlov <ko...@gridgain.com>]

CompletableFuture seems a better option to me.

-- 
Regards,
Konstantin Orlov




> On 26 Mar 2021, at 11:07, Pavel Tupitsyn <pt...@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 <ku...@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 <at...@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
>> 

Re: [DISCUSSION] IgniteFuture class future in Ignite-3.0.

[Pavel Tupitsyn <pt...@apache.org>]

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 <ku...@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 <at...@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
>

Re: [DISCUSSION] IgniteFuture class future in Ignite-3.0.

[Alexey Kukushkin <ku...@gmail.com>]

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 <at...@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

Re: [DISCUSSION] IgniteFuture class future in Ignite-3.0.

[Valentin Kulichenko <va...@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 <at...@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
>

Re: [DISCUSSION] IgniteFuture class future in Ignite-3.0.

[Alexei Scherbakov <al...@gmail.com>]

I think both options are fine, but personally lean toward CompletableFuture.

чт, 25 мар. 2021 г. в 17:56, Atri Sharma <at...@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, <an...@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

Re: [DISCUSSION] IgniteFuture class future in Ignite-3.0.

[Atri Sharma <at...@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, <an...@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
>