[
https://issues.apache.org/jira/browse/CASSANDRA-15757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17097448#comment-17097448
]
Andres de la Peña commented on CASSANDRA-15757:
-----------------------------------------------
I think that the test started to fail after CASSANDRA-15367, which added the
failing assertion to {{indexBuildingPagesLargePartitions}}. That assertion was
probably forgotten when the test was originally added by CASSANDRA-12796
([here|https://github.com/apache/cassandra/commit/36ce4e02b429b1297d71c5c8a963623c62d9e159#diff-13cb97758bcb11cce8fc6f4cb1990dd6R686]).
I think the reason why it fails is that
[{{Keyspace.writeOrder}}|https://github.com/apache/cassandra/commit/36ce4e02b429b1297d71c5c8a963623c62d9e159#diff-13cb97758bcb11cce8fc6f4cb1990dd6R965]
is globally shared, so other tests and/or tasks can concurrently use it to
start other operations, thus the barrier might not yet finished at the moment
we do the assertion. For example, the following simple test fails when
repeatedly run:
{code:java}
@Test
public void myTest()
{
OpOrder.Barrier b = Keyspace.writeOrder.newBarrier();
b.issue();
assertTrue(b.getSyncPoint().isFinished());
}
{code}
It fails because we have concurrent writes for the {{sstable_activity}} table,
probably caused by the teardown of previous test runs.
The proposed patch simply stores the barriers for {{Keyspace.writeOrder}} in a
separate list and awaits for their completion before doing the assert:
||Branch||PR||utest||parameterized||
|3.0
|[576|https://github.com/apache/cassandra/pull/576]|[74|https://ci-cassandra.apache.org/job/Cassandra-devbranch-test/74/]|[647|https://jenkins-dse.build.dsinternal.org/view/Parameterized/job/parameterized-testall/647/]|
|3.11
|[577|https://github.com/apache/cassandra/pull/577]|[75|https://ci-cassandra.apache.org/job/Cassandra-devbranch-test/75/]|[648|https://jenkins-dse.build.dsinternal.org/view/Parameterized/job/parameterized-testall/648/]|
|trunk|[578|https://github.com/apache/cassandra/pull/578]|[76|https://ci-cassandra.apache.org/job/Cassandra-devbranch-test/76/]|[649|https://jenkins-dse.build.dsinternal.org/view/Parameterized/job/parameterized-testall/649/]|
With this change it seems not to fail after some thousands of runs.
> CustomIndexTest.indexBuildingPagesLargePartitions is flaky
> ----------------------------------------------------------
>
> Key: CASSANDRA-15757
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15757
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
> Reporter: Jon Meredith
> Assignee: Andres de la Peña
> Priority: Normal
> Fix For: 4.0-rc
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> CustomIndexTest.indexBuildingPagesLargePartitions is flaky. Failed in CI and
> was able to reproduce failure inside IntelliJ by setting test Repeat to ‘Run
> Until Failure’. Failed after 459 iterations.
> {code}
> java.lang.AssertionError
> at org.junit.Assert.fail(Assert.java:86)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertTrue(Assert.java:52)
> at
> org.apache.cassandra.index.CustomIndexTest.lambda$indexBuildingPagesLargePartitions$1(CustomIndexTest.java:687)
> at java.base/java.util.ArrayList.forEach(ArrayList.java:1540)
> at
> org.apache.cassandra.index.CustomIndexTest.indexBuildingPagesLargePartitions(CustomIndexTest.java:687)
> at jdk.internal.reflect.GeneratedMethodAccessor14.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
> at
> com.intellij.rt.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:53)
> at
> com.intellij.rt.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:230)
> at com.intellij.rt.junit.JUnitStarter.main(JUnitStarter.java:58)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
