Totally agree with this particular suggestion. On more than just a few occasions I've been greatly confused by Ignite's "asynchronous" operations that in reality are blocking under some circumstances and non-blocking under others... Go figure! The reason I was given for such design was performance, if I remember correctly. I hope the Ignite experts on this mailing list will be able to provide more specifics if the community is interested.
In general an asynchronous operation is the one that returns a future immediately without any blocking of the calling thread. The outcome of the invocation is then communicated back exclusively via the future. With the growing popularity of reactive programming style (a la Rx Java, etc.), I think it is crucial to get this fixed. Regards Andrey ________________________________ From: Semyon Boikov <sboi...@gridgain.com> Sent: Thursday, July 21, 2016 1:04 AM To: dev@ignite.apache.org Subject: Re: Rework "withAsync" in Apache 2.0 Another issue which usually confuses users is Ignite 'implementation details' of asynchronous execution: it operation is local it can be executed from calling thread (for example, if 'async put' is executed in atomic cache from primary node then cache store will be updated from calling thread). Does it make sense to fix this as well? On Thu, Jul 21, 2016 at 10:55 AM, Yakov Zhdanov <yzhda...@apache.org> wrote: > Agree with Alex. Vova, please go on with issues taking Alex's comments into > consideration. > > Thanks! > > --Yakov > > 2016-07-21 10:43 GMT+03:00 Alexey Goncharuk <alexey.goncha...@gmail.com>: > > > Big +1 on this in general. > > > > I would also relax our guarantees on operations submitted from the same > > thread. Currently we guarantee that sequential invocations of async > > operations happen in the same order. I think that if a user wants such > > guarantees, he must define these dependencies explicitly by calling > chain() > > on returning futures. > > > > This change will significantly improve cache operations performance in > > async mode. > > > > 3) Sync operations normally* should not* be implemented through async. > This > > > is a long story - if we delegate to async, then we have to bother with > > > additional threads, associated back-pressure control and all that crap. > > > Sync call must be sync unless there is a very strong reason to go > through > > > async path. > > > > > Not sure about this, though. In most cases a cache operation implies > > request/response over the network, so I think we should have explicit > > synchronous counterparts only for methods that are guaranteed to be > local. > > >
