Hi Andrey, Thank you for bringing this question to the list. I already reviewed this PR and it looks good to me. But I would like to hear more opinions from other community members regarding the whole approach.
One important detail - we are going to create new suites as a child classes of existing suites with irrelevant tests excluded manually. This way if a new test is added to existing cache suite, it will be automatically added to TC suite as well, and we will see potential MVCC issues in a nightly build. This is critical thing to keep MVCC mode on par with “classical” transactions. I am not 100% happy with the fact that we will know about new failures only after problematic commit is pushed. But I do not see how to improve it without extending Run All time for another 30 hours. This will do more harm than good. So proposed solution looks like a good pros-cons balance at the moment. Vladimir. ср, 21 нояб. 2018 г. в 17:59, Andrey Mashenkov <andrey.mashen...@gmail.com>: > Hi Igniters, > > As you may already know, MVCC transaction feature will be available in > upcoming Ignite-2.7. > However, MVCC Tx feature is released for beta testing and has many > limitations and we a going > to improve stability and integrations with other features in future > releases. > > We can reuse existed transactional cache tests and run them in Mvcc mode to > get much better test coverage with small looses. > Here is a ticket for this IGNITE-10001 [1]. > > This mean we will have twice more "Cache Tests" and get TC runs some > longer. > To reduce new Mvcc cache suites impact and save TC time we are going to > 1. Include new tests to nightly suite only, this will allow us to put our > ears to the ground. > 2. Exclude non-tx tests and non-relevant tx cases and aggressively mute > tests for unsupported features integrations. > > I've implement a PR to one of tasks [2] as an example how it can be done. > > Technical details: > 1. Introduced a new FORCE_MVCC flag and created a child "Mvcc Cache 2" > suite for "Cache 2" test suite with FORCE_MVCC flag on. > 2. Implemented a hook that change TRANSACTIONAL cache atomicity mode to > TRANSACTIONAL_SNAPSHOT if FORCE_MVCC flag turned on. > This allow us to check MVCC mode without creating new test classes and > minimal intervention in existed tests code. > 3. All irrelevant tests marked as ignored in Mvcc suite. > 4. Known unsupported cases are muted. New failures muted as well > (corresponding tickets were created). > > > Any pros\cons? > Can someone please review a PR? > > [1] https://issues.apache.org/jira/browse/IGNITE-10001 > [2] https://issues.apache.org/jira/browse/IGNITE-10002 > -- > Best regards, > Andrey V. Mashenkov >
