Val, There we were not able to run queries against partitioned tables using replicated cache API (I already fixed that in master).
Here we are talking about query result inconsistency in case of PRIMARY_SYNC because of async backup update. Sergi 2017-04-18 11:04 GMT+03:00 Valentin Kulichenko < valentin.kuliche...@gmail.com>: > Can you please elaborate then? What is the logic there? > > -Val > > On Tue, Apr 18, 2017 at 9:55 AM, Sergi Vladykin <sergi.vlady...@gmail.com> > wrote: > > > Val, > > > > That discussion has nothing to do with this PRIMARY_SYNC problem. > > > > Sergi > > > > 2017-04-18 10:51 GMT+03:00 Valentin Kulichenko < > > valentin.kuliche...@gmail.com>: > > > > > Sergi, > > > > > > I'm talking about this discussion: > > > http://apache-ignite-developers.2346864.n4.nabble. > > > com/SQL-on-PARTITIONED-vs-REPLICATED-cache-td16478.html > > > > > > -Val > > > > > > On Tue, Apr 18, 2017 at 9:46 AM, Vladimir Ozerov <voze...@gridgain.com > > > > > wrote: > > > > > > > Val, > > > > > > > > PRIMARY_SYNC doesn't work correctly with the most common case of SQL > > > query > > > > execution over REPLICATED cache. Also it has weird consequences for > > > > continuous queries when coupled with another > > performance-over-correctness > > > > property "readFromBackup=true": user may receive CQ notification with > > new > > > > value, but subsequent GET on local node may return old value. > > > > > > > > On Tue, Apr 18, 2017 at 10:42 AM, Valentin Kulichenko < > > > > valentin.kuliche...@gmail.com> wrote: > > > > > > > > > This sounds more like an issue with query execution, rather than > > wrong > > > > > PRIMARY_SYNC > > > > > behavior. We already had a discussion about this optimization in > > > > replicated > > > > > cache and decided to switch it off by default. > > > > > > > > > > -Val > > > > > > > > > > On Tue, Apr 18, 2017 at 9:35 AM, Sergi Vladykin < > > > > sergi.vlady...@gmail.com> > > > > > wrote: > > > > > > > > > > > With replicated cache we can execute a query against backup > > > partitions > > > > > that > > > > > > were not updated yet because of PRIMARY_SYNC. Thus we do not see > an > > > > > update. > > > > > > > > > > > > Sergi > > > > > > > > > > > > 2017-04-18 10:30 GMT+03:00 Dmitriy Setrakyan < > > dsetrak...@apache.org > > > >: > > > > > > > > > > > > > Vladimir, > > > > > > > > > > > > > > What is wrong with a query in PRIMARY_SYNC mode? Why won't it > > work? > > > > > > > > > > > > > > D. > > > > > > > > > > > > > > On Tue, Apr 18, 2017 at 12:25 AM, Vladimir Ozerov < > > > > > voze...@gridgain.com> > > > > > > > wrote: > > > > > > > > > > > > > > > Folks, > > > > > > > > > > > > > > > > I received a number of complaints from users that our default > > > > setting > > > > > > > favor > > > > > > > > performance at the cost of correctness and subtle behavior. > > > > > Yesterday I > > > > > > > > faced one such situation on my own. > > > > > > > > > > > > > > > > I started REPLICATED cache on several nodes, put some data, > > > > executed > > > > > > > simple > > > > > > > > SQL and got wrong result. No errors, no warnings. The problem > > was > > > > > > caused > > > > > > > by > > > > > > > > default PRIMARY_SYNC mode. WTF, our cache doesn't work out of > > the > > > > > box! > > > > > > > > > > > > > > > > Another widely known examples are data streamer behavior, > "read > > > > form > > > > > > > > backups" + continuous queries. > > > > > > > > > > > > > > > > I propose to change our defaults to favor *correctness* over > > > > > > performance, > > > > > > > > and create good documentation and JavaDocs to explain users > how > > > to > > > > > tune > > > > > > > our > > > > > > > > product. Proposed changes: > > > > > > > > > > > > > > > > 1) FULL_SYNC as default; > > > > > > > > 2) "readFromBackups=false" as default; > > > > > > > > 3) "IgniteDataStreamer.allowOverwrite=true" as default. > > > > > > > > > > > > > > > > Users should not think how to make Ignite work correctly. It > > > should > > > > > be > > > > > > > > correct out of the box. > > > > > > > > > > > > > > > > Vladimir. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
