Promising beginning of the week! So many talks in the past and finally we came
to the logical end.
Thanks to both of you Taras and Vovan to making this real ;)
Could any of you update the Migration Guide simplifying the life for those who
will be migrating from AI 1.x?
Cool!
Please check my neighboring thread about special .to() method on
IgniteFuture to make it even better :)
On Mon, Mar 27, 2017 at 1:32 PM Vladimir Ozerov
wrote:
> Igniters,
>
> I am glad to announce that old async-style is finally deprecated and now
> all asynchronous
Igniters,
I am glad to announce that old async-style is finally deprecated and now
all asynchronous methods are defined explicitly! Woohoo! Thanks to Taras
for this important contribution.
On Mon, Jan 23, 2017 at 6:12 PM, Taras Ledkov wrote:
> Each compute method produces
Each compute method produces task. For 'run', 'call' etc. methods the
classes of tasks are internal.
There are tests checking the task session by ComputeTaskFuture for these
methods.
I think we have to leave real class of future is
ComputeTaskInternalFuture#ComputeFuture to compatibility.
The
IgniteCompute was designed this way initially. See IgniteCompute.future()
override. May be it makes sense to leave this type only for execute(...)
methods.
On Fri, Jan 20, 2017 at 5:45 PM, Semyon Boikov wrote:
> Hi Taras,
>
> Why 'async' methods return ComputeTaskFuture,
Hi Taras,
Why 'async' methods return ComputeTaskFuture, not just IgniteFuture? It
seems that ComputeTaskFuture is needed only for tasks?
On Fri, Jan 20, 2017 at 5:18 PM, Taras Ledkov wrote:
> Gents
>
> I've done changes of the IgniteCompute as a subtask of the whole
Very cool! Clean and straightforward.
P.S.: If someone doesn't understand the fix - please look at new methods
with "async" suffix [1].
[1] https://github.com/gridgain/apache-ignite/blob/b81621bf2e8a
35b20989f95ff52c0f6d91dd75d6/modules/core/src/main/java/
org/apache/ignite/IgniteCompute.java
me too.
--Yakov
Answered.
On Mon, Dec 26, 2016 at 12:51 PM, Yakov Zhdanov wrote:
> Vladimir, I commented in https://issues.apache.org/jira/browse/IGNITE-4480
> and https://issues.apache.org/jira/browse/IGNITE-4479 and
> https://issues.apache.org/jira/browse/IGNITE-4476
>
> I agree that
Vladimir, I commented in https://issues.apache.org/jira/browse/IGNITE-4480
and https://issues.apache.org/jira/browse/IGNITE-4479 and
https://issues.apache.org/jira/browse/IGNITE-4476
I agree that current approach for async API is not good at all and needs to
be fixed.
As far as callback
And several more improvements to future API:
1) Remove startTime() and duration() methods:
https://issues.apache.org/jira/browse/IGNITE-4479
2) Fix broken cancellation semantics:
https://issues.apache.org/jira/browse/IGNITE-4480
On Thu, Dec 22, 2016 at 1:40 PM, Vladimir Ozerov
Gents,
I created tickets for all proposed improvements:
1) Nice async API: https://issues.apache.org/jira/browse/IGNITE-4475
2) Do not process IO messages synchronously for local node:
https://issues.apache.org/jira/browse/IGNITE-4476
3) Better IgniteFuture API and callback semantics:
Would be nice if someone would prototype a new cache API and post the
generated javadoc here. I think we all will benefit from reviewing it.
On Tue, Dec 20, 2016 at 12:17 PM, Vladimir Ozerov
wrote:
> Async API rework is mechanical addition of ~100 methods through
Async API rework is mechanical addition of ~100 methods through copy-paste.
Should not take more than a day to implement and more than another day to
rework tests.
On Tue, Dec 20, 2016 at 10:00 PM, Dmitriy Setrakyan
wrote:
> How difficult is this change? Does not look
How difficult is this change? Does not look like it can be done overnight.
On Tue, Dec 20, 2016 at 10:46 AM, Vladimir Ozerov
wrote:
> We already discussed this several months ago in other thread.
>
> "Async" methods is the most simple and straight API possible. .NET world
We already discussed this several months ago in other thread.
"Async" methods is the most simple and straight API possible. .NET world
goes this way all over their frameworks and nobody died. Hazelcast also
goes this way. Java goes this way (see CompletableFuture). This is common
and well-known
Me personal preference is to have a separate interface with all the
supported async methods. Basically in 2.0 we can have the same withAsync()
method but it will return this new interface.
Sergi
2016-12-20 21:31 GMT+03:00 Dmitriy Setrakyan :
> On Tue, Dec 20, 2016 at
On Tue, Dec 20, 2016 at 10:28 AM, Sergi Vladykin
wrote:
> +1 For removing withAsync. It is a broken design.
>
Sergi, do you also want to add all the async methods to the main API or do
you have some other design in mind?
+1 For removing withAsync. It is a broken design.
Sergi
2016-12-20 20:38 GMT+03:00 Dmitriy Setrakyan :
> On Tue, Dec 20, 2016 at 9:13 AM, Pavel Tupitsyn
> wrote:
>
> > I don't think that increased method number in the API is an issue.
> > Modern
On Tue, Dec 20, 2016 at 9:13 AM, Pavel Tupitsyn
wrote:
> I don't think that increased method number in the API is an issue.
> Modern IDEs have sophisticated auto-complete features that make it easy to
> find the right one.
>
It is not an issue of IDE support. It is an
I don't think that increased method number in the API is an issue.
Modern IDEs have sophisticated auto-complete features that make it easy to
find the right one.
As an API user, I would prefer sync and async methods side by side in the
same interface:
Use types 'cache.get(' and the IDE would show
The impact of this change seems quite significant. Also, some of the
issues, like starvation, will not be fixed with introduction of the new
API, as far as I can tell.
I would be against removing the current async support from the API in one
motion. I think we can deprecate it right now, in 2.0,
+1
在 2016/12/20 18:05, Pavel Tupitsyn 写道:
Huge +1 on this. Current API is very confusing.
On Tue, Dec 20, 2016 at 11:56 AM, Vladimir Ozerov
wrote:
Igniters,
We have complaints about design of our async API, and upcoming Ignite 2.0
release is a good candidate to fix
Huge +1 on this. Current API is very confusing.
On Tue, Dec 20, 2016 at 11:56 AM, Vladimir Ozerov
wrote:
> Igniters,
>
> We have complaints about design of our async API, and upcoming Ignite 2.0
> release is a good candidate to fix it.
>
> Problems:
>
> 1) API is verbose
24 matches
Mail list logo