You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Ekaterina Dimitrova (Jira)" <ji...@apache.org> on 2021/05/19 15:21:00 UTC

[jira] [Comment Edited] (CASSANDRA-16670) Flaky ViewComplexTest and InsertUpdateIfConditionTest

    [ 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: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org