Re: Make async API great again

2017-03-27 Thread Denis Magda
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?

Re: Make async API great again

2017-03-27 Thread Sergei Egorov
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

Re: Make async API great again

2017-03-27 Thread Vladimir Ozerov
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

Re: Make async API great again

2017-01-23 Thread Taras Ledkov
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

Re: Make async API great again

2017-01-20 Thread Vladimir Ozerov
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,

Re: Make async API great again

2017-01-20 Thread Semyon Boikov
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

Re: Make async API great again

2017-01-20 Thread Vladimir Ozerov
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

Re: Make async API great again

2016-12-26 Thread Yakov Zhdanov
me too. --Yakov

Re: Make async API great again

2016-12-26 Thread Vladimir Ozerov
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

Re: Make async API great again

2016-12-26 Thread Yakov Zhdanov
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

Re: Make async API great again

2016-12-22 Thread Vladimir Ozerov
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

Re: Make async API great again

2016-12-22 Thread 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:

Re: Make async API great again

2016-12-20 Thread Dmitriy Setrakyan
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

Re: Make async API great again

2016-12-20 Thread Vladimir Ozerov
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

Re: Make async API great again

2016-12-20 Thread Dmitriy Setrakyan
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

Re: Make async API great again

2016-12-20 Thread Vladimir Ozerov
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

Re: Make async API great again

2016-12-20 Thread Sergi Vladykin
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

Re: Make async API great again

2016-12-20 Thread Dmitriy Setrakyan
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?

Re: Make async API great again

2016-12-20 Thread Sergi Vladykin
+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

Re: Make async API great again

2016-12-20 Thread 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 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

Re: Make async API great again

2016-12-20 Thread Pavel Tupitsyn
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

Re: Make async API great again

2016-12-20 Thread Dmitriy Setrakyan
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,

Re: Make async API great again

2016-12-20 Thread 李玉珏
+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

Re: Make async API great again

2016-12-20 Thread 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 it. > > Problems: > > 1) API is verbose