----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/25160/#review119336 -----------------------------------------------------------
./src/java/test/org/apache/zookeeper/server/quorum/CommitProcessorConcurrencyTest.java (line 252) <https://reviews.apache.org/r/25160/#comment180649> I suggest to have 50 reads instead of 5 in the last step, and have the 100 committed updates only in committed, not in queue. Then check that it takes <= 50 runs to remove the reads from the queue and that after that there are still some committed updates in committed, i.e., reads were not starved by committed. Also, could you add another test to check that committed aren't starved by reads ? This is the bug you found and described in the jira, so we should have a test for it if we don't already. I think just as above - have many more reads in queue than committed in committed, and check that all committed are processed and many reads remain in queue. - Alexander Shraer On Feb. 16, 2016, 11:44 a.m., Kfir Lev-Ari wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/25160/ > ----------------------------------------------------------- > > (Updated Feb. 16, 2016, 11:44 a.m.) > > > Review request for zookeeper, Raul Gutierrez Segales and Alexander Shraer. > > > Repository: zookeeper > > > Description > ------- > > Please see https://issues.apache.org/jira/browse/ZOOKEEPER-2024 > > > Diffs > ----- > > ./src/java/main/org/apache/zookeeper/server/quorum/CommitProcessor.java > 1726708 > > ./src/java/test/org/apache/zookeeper/server/quorum/CommitProcessorConcurrencyTest.java > 1726708 > ./src/java/test/org/apache/zookeeper/server/quorum/CommitProcessorTest.java > 1726708 > > Diff: https://reviews.apache.org/r/25160/diff/ > > > Testing > ------- > > The attached unit tests, as well as the system test found in > https://issues.apache.org/jira/browse/ZOOKEEPER-2023. > > > Thanks, > > Kfir Lev-Ari > >
