Re: Ignite-2.0 - Make near readers update async by default

2017-02-07 Thread Yakov Zhdanov
Filed a ticket https://issues.apache.org/jira/browse/IGNITE-4665 --Yakov 2017-02-07 0:49 GMT+07:00 Dmitriy Setrakyan : > On Mon, Feb 6, 2017 at 12:29 AM, Yakov Zhdanov > wrote: > > > What users do not expect is that partitioned cache suddenly turns

Re: Ignite-2.0 - Make near readers update async by default

2017-02-06 Thread Dmitriy Setrakyan
On Mon, Feb 6, 2017 at 12:29 AM, Yakov Zhdanov wrote: > What users do not expect is that partitioned cache suddenly turns to > replicated with replicas on client machines running in virtual environment > on higher latency network. I am a bit surprised nobody sees it. I

Re: Ignite-2.0 - Make near readers update async by default

2017-02-05 Thread Yakov Zhdanov
>It still seems that outdated reads will be *more* outdated with async mode. >Also, is there a guarantee that a near-cache update will happen at all, if >you introduce the async mode? We have the same guarantees for continuous queries - updates are sent to listener and no ack is required on grid

Re: Ignite-2.0 - Make near readers update async by default

2017-02-03 Thread Dmitriy Setrakyan
Hm... interesting. My questions are inline. On Mon, Jan 30, 2017 at 3:29 PM, Yakov Zhdanov wrote: > Guys, > > Currently when we do cache updates in FULL_SYNC mode we update near readers > (near cache entries) synchronously. This is quite big drawback in design, I > think. I

Ignite-2.0 - Make near readers update async by default

2017-01-30 Thread Yakov Zhdanov
Guys, Currently when we do cache updates in FULL_SYNC mode we update near readers (near cache entries) synchronously. This is quite big drawback in design, I think. I get each near reader update at cost of 1 extra backup update. I think everyone understands that partitioned cache easily turns to