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. > > >
