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
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
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.
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
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
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
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
Hi Andrey,
Please see below.
-Val
On Wed, Mar 31, 2021 at 7:55 AM Andrey Mashenkov
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
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
> 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
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,
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
> 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
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 wrote:
> Hello!
>
> > Let's say a user started a compute with fut = compute.runAsync(task);
> > and now calls
>
> 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
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
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
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
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
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 fut = cache.getAsync(key);
fut.complete("something");
What should happen in this case?
The point is that currently a future returned from any of
> 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
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
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
CompletableFuture seems a better option to me.
--
Regards,
Konstantin Orlov
> On 26 Mar 2021, at 11:07, Pavel Tupitsyn 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
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 extends Future, CompletionStage
On the other hand:
- CompletionStage has
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
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
I think both options are fine, but personally lean toward CompletableFuture.
чт, 25 мар. 2021 г. в 17:56, Atri Sharma :
> 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
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,
wrote:
> Hi Igniters,
>
> I'd like to start a discussion
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
30 matches
Mail list logo
