[
https://issues.apache.org/jira/browse/CASSANDRA-17070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17435553#comment-17435553
]
Andres de la Peña edited comment on CASSANDRA-17070 at 10/28/21, 4:49 PM:
--------------------------------------------------------------------------
I'm not sure I understand why the MV cleanup can fail. Would the second round
of cleanup guarantee that the MV cleanups succeed, or would it reduce the
chances of having leftovers because it's unlikely to have the same error twice?
Maybe it's just giving more time for the first async cleanup to happen?
In any case, here are 500 runs of each ViewComplex test:
*
[ViewComplexDeletionsTest|https://app.circleci.com/pipelines/github/adelapena/cassandra/1090/workflows/4362eefe-a13a-4a8c-a8eb-9e543a74623a/jobs/10187]
*
[ViewComplexLivenessTest|https://app.circleci.com/pipelines/github/adelapena/cassandra/1091/workflows/a9185c89-ceff-4ddd-90c0-960281233fe3/jobs/10189]
*
[ViewComplexTTLTest|https://app.circleci.com/pipelines/github/adelapena/cassandra/1092/workflows/1f74edb4-3a41-47fd-b95c-0edc1d514a20/jobs/10191]
*
[ViewComplexTest|https://app.circleci.com/pipelines/github/adelapena/cassandra/1093/workflows/f2e69851-19ea-4ab6-9315-5af9d721ec3d/jobs/10193]
*
[ViewComplexUpdatesTest|https://app.circleci.com/pipelines/github/adelapena/cassandra/1094/workflows/0d25bf72-7c90-4287-92d6-21a751082e21/jobs/10196]
>From this only a test runner for {{ViewComplexTest}} is failing due to
>timeouts.
It's not strictly related to the fix, but it seems there is some repeated code
among the five tests in which {{ViewComplexTest}} was split by CASSANDRA-16670.
Probably we should do the same thing that we did with {{ViewTest}} in
CASSANDRA-16777 and extract a superclass to avoid code duplication. This would
changes like this one a bit easier to do. I gave it a go in [this
commit|https://github.com/adelapena/cassandra/commit/204f3bbe69aae9165c0570224bfd811c8bbd4d07],
and it saves us some 176 lines of code, which I think is always nice.
Here are some repeated runs for the tests using a common superclass, with no
failures so far:
*
[ViewComplexDeletionsTest|https://app.circleci.com/pipelines/github/adelapena/cassandra/1096/workflows/ded0dfe1-e736-468a-babb-0c007a6bf3c9/jobs/10201]
*
[ViewComplexLivenessTest|https://app.circleci.com/pipelines/github/adelapena/cassandra/1097/workflows/544b429d-b712-428c-b97d-edd50076992a/jobs/10203]
*
[ViewComplexTTLTest|https://app.circleci.com/pipelines/github/adelapena/cassandra/1098/workflows/c062d815-2e26-4a75-aa64-656bfc48c8cc/jobs/10205]
*
[ViewComplexTest|https://app.circleci.com/pipelines/github/adelapena/cassandra/1099/workflows/1f834191-b30b-4380-87ce-da257fac731e/jobs/10207]
*
[ViewComplexUpdatesTest|https://app.circleci.com/pipelines/github/adelapena/cassandra/1095/workflows/3df8138d-1d7b-4283-be3c-a23cb2c0bc40]
An alternative/complementary approach to avoid problems with leftovers from
previous runs is making sure that all MVs are created with a new, unique name.
This way the tests don't collide with any surviving MVs if the cleanup has
failed or if it hasn't finished. {{CQLTester}} does this with keyspace, table,
function and aggregate names.
I gave a go to this generation of unique names
[here|https://github.com/adelapena/cassandra/commit/e1928447e4139f1ad4126d9ed34e3de9d3bceb10].
It is just for {{ViewComplexTest}}, but we may consider having a more generic
and reusable solution for creating/cleaning MVs in {{CQLTester}}, although I
think we don't have to do it here. wdyt?
was (Author: adelapena):
I'm not sure I understand why the MV cleanup can fail. Would the second round
of cleanup guarantee that the MV cleanups succeed, or would it reduce the
chances of having leftovers because it's unlikely to have the same error twice?
Maybe it's just giving more time for the first async cleanup to happen?
In any case, here are 500 runs of each ViewComplex test:
*
[ViewComplexDeletionsTest|https://app.circleci.com/pipelines/github/adelapena/cassandra/1090/workflows/4362eefe-a13a-4a8c-a8eb-9e543a74623a/jobs/10187]
*
[ViewComplexLivenessTest|https://app.circleci.com/pipelines/github/adelapena/cassandra/1091/workflows/a9185c89-ceff-4ddd-90c0-960281233fe3/jobs/10189]
*
[ViewComplexTTLTest|https://app.circleci.com/pipelines/github/adelapena/cassandra/1092/workflows/1f74edb4-3a41-47fd-b95c-0edc1d514a20/jobs/10191]
*
[ViewComplexTest|https://app.circleci.com/pipelines/github/adelapena/cassandra/1093/workflows/f2e69851-19ea-4ab6-9315-5af9d721ec3d/jobs/10193]
*
[ViewComplexUpdatesTest|https://app.circleci.com/pipelines/github/adelapena/cassandra/1094/workflows/0d25bf72-7c90-4287-92d6-21a751082e21/jobs/10196]
>From this only a test runner for {{ViewComplexTest}} is failing due to
>timeouts.
It's not strictly related to the fix, but it seems there is some repeated code
among the five tests in which {{ViewComplexTest}} was split by CASSANDRA-16670.
Probably we should do the same thing that we did with {{ViewTest}} in
CASSANDRA-16777 and extract a superclass to avoid code duplication. This would
changes like this one a bit easier to do. I gave it a go in [this
commit|https://github.com/adelapena/cassandra/commit/204f3bbe69aae9165c0570224bfd811c8bbd4d07],
and it saves us some 176 lines of code, which I think is always nice.
Here are some repeated runs for the test using a common superclass, with no
failures so far:
*
[ViewComplexDeletionsTest|https://app.circleci.com/pipelines/github/adelapena/cassandra/1096/workflows/ded0dfe1-e736-468a-babb-0c007a6bf3c9/jobs/10201]
*
[ViewComplexLivenessTest|https://app.circleci.com/pipelines/github/adelapena/cassandra/1097/workflows/544b429d-b712-428c-b97d-edd50076992a/jobs/10203]
*
[ViewComplexTTLTest|https://app.circleci.com/pipelines/github/adelapena/cassandra/1098/workflows/c062d815-2e26-4a75-aa64-656bfc48c8cc/jobs/10205]
*
[ViewComplexTest|https://app.circleci.com/pipelines/github/adelapena/cassandra/1099/workflows/1f834191-b30b-4380-87ce-da257fac731e/jobs/10207]
*
[ViewComplexUpdatesTest|https://app.circleci.com/pipelines/github/adelapena/cassandra/1095/workflows/3df8138d-1d7b-4283-be3c-a23cb2c0bc40]
An alternative/complementary approach to avoid problems with leftovers from
previous test runs is making sure that all MVs are created with a new, unique
name. This way the tests don't collide with any surviving MVs if the cleanup
has failed or if it hasn't finished. {{CQLTester}} does this with keyspace,
table, function and aggregate names.
I gave it a go to this generation of unique names
[here|https://github.com/adelapena/cassandra/commit/e1928447e4139f1ad4126d9ed34e3de9d3bceb10].
It is just for {{ViewComplexTest}}, but we may consider having a more generic
and reusable solution for creating/cleaning MVs in {{CQLTester}}, although I
think we don't have to do it here. wdyt?
> ViewComplexTest hardening
> -------------------------
>
> Key: CASSANDRA-17070
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17070
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
> Reporter: Berenguer Blasi
> Assignee: Berenguer Blasi
> Priority: Normal
> Fix For: 4.0.x, 4.x
>
>
> I have seen a number of times already the {{ViewComplexTest}} family timeout
> on test method teardown. This leaves a dirty env behind triggering the
> following test methods to fail on it. This ticket aims at hardening them.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
