Igniters,
The PR is ready for review
https://github.com/apache/ignite/pull/8174
On Tue, Sep 22, 2020 at 11:51 AM Pavel Tupitsyn
wrote:
> Yes, this makes a lot of sense (and can be applied to Services, too).
>
> I've filed the ticket: https://issues.apache.org/jira/browse/IGNITE-13471
> This req
Yes, this makes a lot of sense (and can be applied to Services, too).
I've filed the ticket: https://issues.apache.org/jira/browse/IGNITE-13471
This requires a separate IEP, of course.
On Mon, Sep 21, 2020 at 6:33 PM mnk wrote:
> Pavel Tupitsyn wrote
> >> result of a remote execution is a Compl
Pavel Tupitsyn wrote
>> result of a remote execution is a CompletionStage
>
> Can you give an example? What is a remote execution? Is this about Compute
> and/or Services?
This is about Compute.
Let's say I'm doing affinityCallAsync for IgniteCallable where R
implements CompletableStage or R is
> result of a remote execution is a CompletionStage
Can you give an example? What is a remote execution? Is this about Compute
and/or Services?
On Mon, Sep 21, 2020 at 5:11 PM mnk wrote:
> So one question I have here (and this maybe out of scope) - but what about
> the cases where the result o
So one question I have here (and this maybe out of scope) - but what about
the cases where the result of a remote execution is a CompletionStage? In
this case, I would want to have a local CompletionStage which "represents"
the remote one. In other words when the remote one is completed, the value
So one question I have here (and this maybe out of scope) - but what about
the cases where the result of a remote execution is a CompletionStage? In
this case, I would want to have a local CompletionStage which "represents"
the remote one. In other words when the remote one is completed, the value
Hello folks,
I agree with Val: IgniteFuture was created long before we could use the
Java futures and is being kept for compatibility reasons. While keeping API
consistent between thin/thick clients is a good reason, I think moving to
Java futures benefits more to the project and end-users.
Agree
Hi guys,
It would be really cool to have async operations.
My point is that the worst thing that we have at the moment is that we need
to write data to the socket under the sndLock.
It makes it nearly impossible for users to implement async operations on
their side.
Of course they can scale up by
Alexey, what do you think? Which Future should be used here?
Now, about the "not fully sync" interface - I believe this is acceptable as
a first
approach.
Best Regards,
Igor
On Mon, Aug 24, 2020 at 12:37 PM Pavel Tupitsyn
wrote:
> I've changed the IEP and added a new future interface to the P
I've changed the IEP and added a new future interface to the POC:
interface IgniteClientFuture extends Future, CompletionStage
The implementation simply wraps the CompletableFuture.
On Fri, Aug 21, 2020 at 11:22 PM Valentin Kulichenko <
valentin.kuliche...@gmail.com> wrote:
> Hi Pavel,
>
> Inter
Hi Pavel,
Interesting findings :) Agree that we should not use the CompletableFuture
- it clearly has a different purpose.
I think that the approach taken by Redis makes more sense. I don't like
that it requires a custom interface, but I think we can live with that.
I would be glad to hear other
Pavel,
> Very interesting, is there a ticket or IEP to follow?
No, there is no ticket or IEP. I will create ticket, IEP and dev-list
discussion after benchmarking of POC implementation.
пт, 21 авг. 2020 г. в 12:17, Pavel Tupitsyn :
> Alex,
>
> > not fully async, since "send" is still used in the
Alex,
> not fully async, since "send" is still used in the user's thread
Correct. I've added those details to the IEP.
I'll investigate the ways to make this fully non-blocking,
but for now let's consider this to be out of scope of this IEP.
> POC for thin client data streamer
Very interesting, i
Val,
The problems with CompletableFuture in public API are:
* It is a class, not an interface
* It is completable - anyone can call .complete(), which is not what we want
There seems to be no clear guidance in Java world on async API design;
however, it is often recommended to return CompletionSt
Pavel,
Thanks for the discussion, I've also faced with the necessity of having
async calls while implementing POC for thin client data streamer [1] and
solve it similarly (but in my case it's required only for internal
implementation, so I've only changed the internal API).
I want to note that de
Ok, I've reflected this in the IEP
On Fri, Aug 21, 2020 at 3:35 AM Valentin Kulichenko <
valentin.kuliche...@gmail.com> wrote:
> Sounds good. I've added this to the 3.0 roadmap:
> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+3.0
>
> Unless there are any objections from others,
Sounds good. I've added this to the 3.0 roadmap:
https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+3.0
Unless there are any objections from others, let's stick with the
CompletableFuture for any future development, including the thin client.
-Val
On Thu, Aug 20, 2020 at 9:30 AM Pa
Val, no objections from my side.
As noted above, the only benefit of IgniteFuture is consistency across
thin/thick APIs,
which is probably not so important.
On Thu, Aug 20, 2020 at 6:28 PM Valentin Kulichenko <
valentin.kuliche...@gmail.com> wrote:
> Hi Pavel,
>
> Are there any benefits of Ignite
Hi Pavel,
Are there any benefits of IgniteFuture over CompletableFuture?
IgniteFuture was created long ago, during the time when CompletableFuture
did not exist. There is a big chance that IgniteFuture actually became
redundant at the moment we transitioned to Java8. If that's the case, I
would p
Igniters,
I've prepared an IEP [1], please review and let me know what you think.
In particular, I'd like to discuss the Future interface to be used:
* IgniteFuture is the first candidate - Thin APIs will be consistent with
Thick APIs, probably better for existing Ignite users.
* CompletableFutur
20 matches
Mail list logo
