Hello. Ivan is right that "baseline auto-adjust" is disabled by default if you start your node on existing PDS. But "baseline auto-adjust" is enabled by default for in-memory cluster due to in-memory nodes also have bound to baseline since 2.8 version.
Also, I want to note that after this ticket(https://issues.apache.org/jira/projects/IGNITE/issues/IGNITE-12227). "baseline auto-adjust" would be disabled by default for any persistent cluster(empty and existed one) because current logic is a little confused and can lead to some problems which described in the ticket. -- Best regards, Anton Kalashnikov 27.12.2019, 17:58, "Ivan Bessonov" <bessonov...@gmail.com>: > Hello, > > "baseline auto-adjust" is disabled by default if you start your node on > existing PDS. > It's enabled on new clusters only. > > Existing installations should not be affected by the update. Is that ok? > > пт, 27 дек. 2019 г. в 14:46, Maxim Muzafarov <mmu...@apache.org>: > >> Ilya, >> >> +1 from my side. >> >> On Fri, 27 Dec 2019 at 14:36, Ilya Kasnacheev <ilya.kasnach...@gmail.com> >> wrote: >> > >> > Hello! >> > >> > I have also noticed that we have baseline auto-adjust enabled by default >> in >> > 2.8 builds, and it breaks existing code in runtime: >> > https://issues.apache.org/jira/browse/IGNITE-12504 >> > >> > I propose to turn auto-adjust off by default in 2.8 release. What do you >> > think? >> > >> > Regards, >> > -- >> > Ilya Kasnacheev >> > >> > >> > пт, 27 дек. 2019 г. в 12:40, Sergei Ryzhov <s.vi.ryz...@gmail.com>: >> > >> > > Hello! >> > > Task IGNITE-12470 is ready. >> > > https://issues.apache.org/jira/browse/IGNITE-12470 >> > > Please check this API. >> > > >> > > >> > > Regards, >> > > Ryzhov Sergei. >> > > >> > > чт, 26 дек. 2019 г. в 18:50, Maxim Muzafarov <mmu...@apache.org>: >> > > >> > > > Ilya, >> > > > >> > > > >> > > > I agree with you that there is no risk and spring-data-2.2 can be >> > > > safely cherry-picked to the ignite-2.8 branch. I'm OK with it. Will >> > > > you do such merge or I should do it by myself? >> > > > >> > > > >> > > > As for the second part of your email, you are proposing to bump up a >> > > > minor dependencies version (no API changes) for the whole components >> > > > mentioned in the parent/pom.xml file, right? From a point of the >> > > > release view, it seems not a good thing since a scope test of the >> > > > release becomes too wider. I don't think we will simplify thus the >> > > > year-long release test scope, so as for me, this sounds not good but >> > > > I'd like to hear thoughts of other community members on this point. >> > > > >> > > > As an alternative, for instance, we can bump minor versions only for >> > > > those components which have security vulnerabilities. To find such >> > > > dependencies, I've run some local test with a maven >> > > > dependency-check-maven [1] an open-source dependency check tool. Here >> > > > is a brief report (only a few modules tested): >> > > > >> > > > spring-core-4.3.18.RELEASE.jar : CVE-2018-15756 [2] >> > > > h2-1.4.197.jar : CVE-2018-10054, CVE-2018-14335 (discussed also [3]) >> > > > ignite-shmem-1.0.0.jar : CVE-2017-14614 >> > > > >> > > > >> > > > [1] https://jeremylong.github.io/DependencyCheck/index.html >> > > > [2] https://nvd.nist.gov/vuln/detail/CVE-2018-15756 >> > > > [3] https://issues.apache.org/jira/browse/IGNITE-10801 >> > > > >> > > > >> > > > >> > > > On Thu, 26 Dec 2019 at 15:52, Ilya Kasnacheev < >> ilya.kasnach...@gmail.com >> > > > >> > > > wrote: >> > > > > >> > > > > Hello! >> > > > > >> > > > > I propose to add the following ticket to the scope: >> > > > > https://issues.apache.org/jira/browse/IGNITE-12259 (3 commits, be >> > > > careful >> > > > > with release version) >> > > > > >> > > > > Adding tickets to scope surely seems crazy now, but I will provide >> the >> > > > > following considerations: >> > > > > * This is Spring Data 2.2 integration, which we currently do not >> have, >> > > > > leading to lots of confused questions on stack overflow and mailing >> > > list. >> > > > > Spring Data is important to our public image since many people may >> > > learn >> > > > > about out project by starting with Spring Data. >> > > > > >> > > > > * It has zero code impact outside of its own module (just 2 POM >> file >> > > > > touched and that's all). >> > > > > >> > > > > * The core was ready since early November but, due to gmail quirk, >> we >> > > did >> > > > > not react to it in time. >> > > > > >> > > > > WDYT? >> > > > > >> > > > > Another semi-related question. *Should we bump our dependencies' >> > > versions >> > > > > before releasing 2.8?* I talk mainly about spring and hibernate >> > > > > dependencies. We could switch them to their latest maintenance >> versions >> > > > to >> > > > > avoid shipping default links to outdated packages. >> > > > > >> > > > > I think this is one of things that are very hard to do between >> > > releases, >> > > > so >> > > > > I think this dependencies bumping should be a part of a formal >> > > > > release/testing cycle, and then be backported to master. >> > > > > >> > > > > I could volunteer to do that myself, if we agree to merge these >> version >> > > > > upgrades to ignite-2.8 and then re-test. >> > > > > >> > > > > Regards, >> > > > > -- >> > > > > Ilya Kasnacheev >> > > > > >> > > > > >> > > > > вт, 24 дек. 2019 г. в 13:22, Zhenya Stanilovsky >> > > > <arzamas...@mail.ru.invalid >> > > > > >: >> > > > > >> > > > > > >> > > > > > Igniters, i`l try to compare 2.8 release candidate vs 2.7.6, >> > > > > > last sha 2.8 was build from : 9d114f3137f92aebc2562a >> > > > > > i use yardstick benchmarks, 4 bare machine with: 2x Xeon X5570 >> 96Gb >> > > > 512GB >> > > > > > SSD 2048GB HDD 10GB/s >> > > > > > 1 for client (driver) and 3 for servers. >> > > > > > this mappings for graphs and real yardstick tests: >> > > > > > >> > > > > > atomic-put: IgnitePutBenchmark >> > > > > > sql-merge-query: IgniteSqlMergeQueryBenchmark >> > > > > > atomic-get: IgniteGetBenchmark >> > > > > > tx-get: IgniteGetTxBenchmark >> > > > > > tx-put: IgnitePutTxBenchmark >> > > > > > atomic-put-all-bs-10: IgnitePutAllBenchmark >> > > > > > tx-put-all-bs-10: IgnitePutAllTxBenchmark >> > > > > > >> > > > > > cacheMode — partitioned >> > > > > > CacheWriteSynchronizationMode.FULL_SYNC >> > > > > > 1 backup >> > > > > > >> > > > > > 1. wal = log_only 2. wal = none 3. persistence disabled. >> > > > > > Thanks Maxim for wiki page [1] >> > > > > > >> > > > > > >> > > > > > [1] >> > > > > > >> > > > >> > > >> >> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.8#ApacheIgnite2.8-Benchmarks >> > > > > > >> > > > > > do we need some bisect or other work here ? >> > > > > > >> > > > > > > >> > > > > > > >> > > > > > >------- Forwarded message ------- >> > > > > > >From: "Maxim Muzafarov" < mmu...@apache.org > >> > > > > > >To: dev@ignite.apache.org >> > > > > > >Cc: >> > > > > > >Subject: Apache Ignite 2.8 RELEASE [Time, Scope, Manager] >> > > > > > >Date: Fri, 20 Sep 2019 14:44:31 +0300 >> > > > > > > >> > > > > > >Igniters, >> > > > > > > >> > > > > > > >> > > > > > >It's almost a year has passed since the last major Apache >> Ignite 2.7 >> > > > > > >has been released. We've accumulated a lot of performance >> > > improvements >> > > > > > >and a lot of new features which are waiting for their release >> date. >> > > > > > >Here is my list of the most interesting things from my point >> since >> > > the >> > > > > > >last major release: >> > > > > > > >> > > > > > >Service Grid, >> > > > > > >Monitoring, >> > > > > > >Recovery Read >> > > > > > >BLT auto-adjust, >> > > > > > >PDS compression, >> > > > > > >WAL page compression, >> > > > > > >Thin client: best effort affinity, >> > > > > > >Thin client: transactions support (not yet) >> > > > > > >SQL query history >> > > > > > >SQL statistics >> > > > > > > >> > > > > > >I think we should no longer wait and freeze the master branch >> > > anymore >> > > > > > >and prepare the next major release by the end of the year. >> > > > > > > >> > > > > > > >> > > > > > >I propose to discuss Time, Scope of Apache Ignite 2.8 release >> and >> > > also >> > > > > > >I want to propose myself to be the release manager of the >> planning >> > > > > > >release. >> > > > > > > >> > > > > > >Scope Freeze: November 4, 2019 >> > > > > > >Code Freeze: November 18, 2019 >> > > > > > >Voting Date: December 10, 2019 >> > > > > > >Release Date: December 17, 2019 >> > > > > > > >> > > > > > > >> > > > > > >WDYT? >> > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > >> > > > > -- > Sincerely yours, > Ivan Bessonov
