[
https://issues.apache.org/jira/browse/CASSANDRA-16670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17347732#comment-17347732
]
Ekaterina Dimitrova edited comment on CASSANDRA-16670 at 5/19/21, 3:20 PM:
---------------------------------------------------------------------------
When you run with the rules locally it works fine, but did you try in a full
CI? From what I remember and I read in the mentioned discussion, the rules are
overwritten by the build.xml timeouts when you run full CI.
We can verify this again by pushing a dev branch to Jenkins with low build.xml
timeout and higher timeout on a class level.
I will push a run later, thanks
About _InsertUpdateIfConditionTest,_ I haven't looked at it and its timings but
if it exceeds the unit tests' timeout significantly and qualifies for long
test, without exceeding also the long tests' timeouts, I would move it to a
long test. If it needs just a bit of time, and not frequently - I would add a
bit of time probably on a class level.
My reasoning comes from the point that if it exceeds the timeout just a bit -
we don't have to raise its timeout to a long test and wait for its timeouts too
long.
was (Author: e.dimitrova):
When you run with the rules locally it works fine, but did you try in a full
CI? From what I remember and I read in the mentioned discussion, the rules are
overwritten by the build.xml timeouts when you run full CI.
We can verify this again by pushing a dev branch to Jenkins with low build.xml
timeout and higher ClassRule.
I will push a run later, thanks
About _InsertUpdateIfConditionTest,_ I haven't looked at it and its timings but
if it exceeds the unit tests' timeout significantly and qualifies for long
test, without exceeding also the long tests' timeouts, I would move it to a
long test. If it needs just a bit of time, and not frequently - I would add a
bit of time probably on a class level.
My reasoning comes from the point that if it exceeds the timeout just a bit -
we don't have to raise its timeout to a long test and wait for its timeouts too
long.
> Flaky ViewComplexTest and InsertUpdateIfConditionTest
> -----------------------------------------------------
>
> Key: CASSANDRA-16670
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16670
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
> Reporter: Berenguer Blasi
> Assignee: Berenguer Blasi
> Priority: Normal
> Fix For: 4.0-rc2, 4.0, 4.x
>
>
> *ViewComplexTest*
> Flaky
> [test|https://ci-cassandra.apache.org/job/Cassandra-4.0/43/testReport/junit/org.apache.cassandra.cql3/ViewComplexTest/testPartialDeleteSelectedColumnWithoutFlush_3_/]
> *InsertUpdateIfConditionTest* (CASSANDRA-16676)
> Fails
> [here|https://ci-cassandra.apache.org/job/Cassandra-4.0/46/testReport/junit/org.apache.cassandra.cql3.validation.operations/InsertUpdateIfConditionTest/testListItem_2__clusterMinVersion_4_0_0_rc2_SNAPSHOT_/]
> with a timeout. We can see in the history it takes quite a while in
> [CI|https://ci-cassandra.apache.org/job/Cassandra-4.0/46/testReport/junit/org.apache.cassandra.cql3.validation.operations/InsertUpdateIfConditionTest/history/]
> _but_ it takes just 1m locally. Probably due to constrained resources.
> Looking at the
> [individual|https://ci-cassandra.apache.org/job/Cassandra-4.0/46/testReport/junit/org.apache.cassandra.cql3.validation.operations/InsertUpdateIfConditionTest/]
> test cases, for compression i.e., we can see 378 at an average of 1s each it
> can easily go over the timeout of 240s. Recommendation is to either move to
> 'long' section of to raise the timeout for the class for CI.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
