[jira] [Commented] (CASSANDRA-16670) Flaky ViewComplexTest and InsertUpdateIfConditionTest
[ https://issues.apache.org/jira/browse/CASSANDRA-16670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17348025#comment-17348025 ] Ekaterina Dimitrova commented on CASSANDRA-16670: - Very low timeout in build.xml using your patch and it timed out: https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/856/workflows/57238d25-d581-4117-872a-422c9f785b6d/jobs/5096/tests > 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-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16581) Failure to execute queries should emit a KPI other than read timeout/unavailable so it can be alerted/tracked
[ https://issues.apache.org/jira/browse/CASSANDRA-16581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-16581: -- Status: In Progress (was: Changes Suggested) > Failure to execute queries should emit a KPI other than read > timeout/unavailable so it can be alerted/tracked > - > > Key: CASSANDRA-16581 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16581 > Project: Cassandra > Issue Type: Bug > Components: Messaging/Client, Observability/Metrics >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0-rc > > > When we are unable to parse a message we do not have a way to detect this > from a monitoring point of view so can get into situations where we believe > the database is fine but the clients are on-fire. This case popped up in the > 2.1 to 3.0 upgrade as paging state wasn’t mixed-mode safe. -- 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
[jira] [Updated] (CASSANDRA-16581) Failure to execute queries should emit a KPI other than read timeout/unavailable so it can be alerted/tracked
[ https://issues.apache.org/jira/browse/CASSANDRA-16581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-16581: -- Status: Patch Available (was: In Progress) > Failure to execute queries should emit a KPI other than read > timeout/unavailable so it can be alerted/tracked > - > > Key: CASSANDRA-16581 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16581 > Project: Cassandra > Issue Type: Bug > Components: Messaging/Client, Observability/Metrics >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0-rc > > > When we are unable to parse a message we do not have a way to detect this > from a monitoring point of view so can get into situations where we believe > the database is fine but the clients are on-fire. This case popped up in the > 2.1 to 3.0 upgrade as paging state wasn’t mixed-mode safe. -- 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
[jira] [Comment Edited] (CASSANDRA-16681) org.apache.cassandra.utils.memory.LongBufferPoolTest - tests are flaky
[
https://issues.apache.org/jira/browse/CASSANDRA-16681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17347872#comment-17347872
]
Adam Holmberg edited comment on CASSANDRA-16681 at 5/19/21, 9:18 PM:
-
I think this is a test issue. I think we have a race
[here|https://github.com/apache/cassandra/blob/9a432418f2277c40a1fe4b64049688d6354ecdca/test/burn/org/apache/cassandra/utils/memory/LongBufferPoolTest.java#L276-L284]
where, if threads exit after {{doneThreads}} is sampled, the assumptions
mentioned in the comment are violated.
I haven't assigned or posted a change because I'm still looking at some other
weirdness around this test and trying to understand how it was intended to work.
If anyone else wants to take a look and corroborate or just take the ticket,
it's fine by me.
was (Author: aholmber):
I think this is a test issue. I think we have a race
[here|https://github.com/apache/cassandra/blob/9a432418f2277c40a1fe4b64049688d6354ecdca/test/burn/org/apache/cassandra/utils/memory/LongBufferPoolTest.java#L276-L284]
where, if threads exit after doneThreads is sampled, the assumptions mentioned
in the comment are violated.
I haven't assigned or posted a change because I'm still looking at some other
weirdness around this test and trying to understand how it was intended to work.
If anyone else wants to take a look and corroborate or just take the ticket,
it's fine by me.
> org.apache.cassandra.utils.memory.LongBufferPoolTest - tests are flaky
> --
>
> Key: CASSANDRA-16681
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16681
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0, 4.0-rc
>
>
> Jenkins history:
> [https://jenkins-cm4.apache.org/job/Cassandra-4.0/50/testReport/junit/org.apache.cassandra.utils.memory/LongBufferPoolTest/testPoolAllocateWithRecyclePartially/history/]
> Fails being run in a loop in CircleCI:
> https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/844/workflows/945011f4-00ac-4678-89f6-5c0db0a40169/jobs/5008
>
--
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
[jira] [Commented] (CASSANDRA-16681) org.apache.cassandra.utils.memory.LongBufferPoolTest - tests are flaky
[ https://issues.apache.org/jira/browse/CASSANDRA-16681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17347872#comment-17347872 ] Adam Holmberg commented on CASSANDRA-16681: --- I think this is a test issue. I think we have a race [here|https://github.com/apache/cassandra/blob/9a432418f2277c40a1fe4b64049688d6354ecdca/test/burn/org/apache/cassandra/utils/memory/LongBufferPoolTest.java#L276-L284] where, if threads exit after doneThreads is sampled, the assumptions mentioned in the comment are violated. I haven't assigned or posted a change because I'm still looking at some other weirdness around this test and trying to understand how it was intended to work. If anyone else wants to take a look and corroborate or just take the ticket, it's fine by me. > org.apache.cassandra.utils.memory.LongBufferPoolTest - tests are flaky > -- > > Key: CASSANDRA-16681 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16681 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.0, 4.0-rc > > > Jenkins history: > [https://jenkins-cm4.apache.org/job/Cassandra-4.0/50/testReport/junit/org.apache.cassandra.utils.memory/LongBufferPoolTest/testPoolAllocateWithRecyclePartially/history/] > Fails being run in a loop in CircleCI: > https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/844/workflows/945011f4-00ac-4678-89f6-5c0db0a40169/jobs/5008 > -- 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
[jira] [Commented] (CASSANDRA-16581) Failure to execute queries should emit a KPI other than read timeout/unavailable so it can be alerted/tracked
[
https://issues.apache.org/jira/browse/CASSANDRA-16581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17347867#comment-17347867
]
David Capwell commented on CASSANDRA-16581:
---
[~samt]
FrameEncoder change is
{code}
public void write(ChannelHandlerContext ctx, Object msg, ChannelPromise
promise) throws Exception
{
if (!(msg instanceof Payload))
-throw new IllegalStateException("Unexpected type: " + msg);
+{
+ctx.write(msg, promise);
+return;
+}
{code}
This isn't a leftover from debugging, its from the fact that we no longer
support it as the v5 logic uses the more lower level APIs (such as
ChannelInboundHandlerAdapter); the higher level APIs pass through objects which
do not match the type. Here is an example from v4
{code}
public static class ProtocolEncoder extends MessageToMessageEncoder
{code}
MessageToMessageEncoder has the following
https://github.com/netty/netty/blob/4.1/codec/src/main/java/io/netty/handler/codec/MessageToMessageEncoder.java#L84-L100
{code}
if (acceptOutboundMessage(msg)) {
...
} else {
ctx.write(msg, promise);
}
{code}
I use this in the simple client to send arbitrary payloads to validate server
behavior.
ProtocolVersion - made the change; back porting now
> Failure to execute queries should emit a KPI other than read
> timeout/unavailable so it can be alerted/tracked
> -
>
> Key: CASSANDRA-16581
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16581
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client, Observability/Metrics
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0-rc
>
>
> When we are unable to parse a message we do not have a way to detect this
> from a monitoring point of view so can get into situations where we believe
> the database is fine but the clients are on-fire. This case popped up in the
> 2.1 to 3.0 upgrade as paging state wasn’t mixed-mode safe.
--
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
[jira] [Comment Edited] (CASSANDRA-16581) Failure to execute queries should emit a KPI other than read timeout/unavailable so it can be alerted/tracked
[
https://issues.apache.org/jira/browse/CASSANDRA-16581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17347867#comment-17347867
]
David Capwell edited comment on CASSANDRA-16581 at 5/19/21, 9:12 PM:
-
[~samt]
FrameEncoder change is
{code}
public void write(ChannelHandlerContext ctx, Object msg, ChannelPromise
promise) throws Exception
{
if (!(msg instanceof Payload))
-throw new IllegalStateException("Unexpected type: " + msg);
+{
+ctx.write(msg, promise);
+return;
+}
{code}
This isn't a leftover from debugging, its from the fact that we no longer
support it as the v5 logic uses the more lower level APIs (such as
ChannelInboundHandlerAdapter); the higher level APIs pass through objects which
do not match the type. Here is an example from v4
{code}
public static class ProtocolEncoder extends MessageToMessageEncoder
{code}
MessageToMessageEncoder has the following
https://github.com/netty/netty/blob/4.1/codec/src/main/java/io/netty/handler/codec/MessageToMessageEncoder.java#L84-L100
{code}
if (acceptOutboundMessage(msg)) {
...
} else {
ctx.write(msg, promise);
}
{code}
I use this in the simple client to send arbitrary payloads to validate server
behavior.
ProtocolVersion - made the change
was (Author: dcapwell):
[~samt]
FrameEncoder change is
{code}
public void write(ChannelHandlerContext ctx, Object msg, ChannelPromise
promise) throws Exception
{
if (!(msg instanceof Payload))
-throw new IllegalStateException("Unexpected type: " + msg);
+{
+ctx.write(msg, promise);
+return;
+}
{code}
This isn't a leftover from debugging, its from the fact that we no longer
support it as the v5 logic uses the more lower level APIs (such as
ChannelInboundHandlerAdapter); the higher level APIs pass through objects which
do not match the type. Here is an example from v4
{code}
public static class ProtocolEncoder extends MessageToMessageEncoder
{code}
MessageToMessageEncoder has the following
https://github.com/netty/netty/blob/4.1/codec/src/main/java/io/netty/handler/codec/MessageToMessageEncoder.java#L84-L100
{code}
if (acceptOutboundMessage(msg)) {
...
} else {
ctx.write(msg, promise);
}
{code}
I use this in the simple client to send arbitrary payloads to validate server
behavior.
ProtocolVersion - made the change; back porting now
> Failure to execute queries should emit a KPI other than read
> timeout/unavailable so it can be alerted/tracked
> -
>
> Key: CASSANDRA-16581
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16581
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client, Observability/Metrics
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0-rc
>
>
> When we are unable to parse a message we do not have a way to detect this
> from a monitoring point of view so can get into situations where we believe
> the database is fine but the clients are on-fire. This case popped up in the
> 2.1 to 3.0 upgrade as paging state wasn’t mixed-mode safe.
--
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
[jira] [Assigned] (CASSANDRA-16573) CQLSH copy defaults appear to be incorrect on website
[
https://issues.apache.org/jira/browse/CASSANDRA-16573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Houser reassigned CASSANDRA-16573:
Assignee: Brian Houser
> CQLSH copy defaults appear to be incorrect on website
> -
>
> Key: CASSANDRA-16573
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16573
> Project: Cassandra
> Issue Type: Bug
> Components: Documentation/Website
>Reporter: Brian Houser
>Assignee: Brian Houser
>Priority: Normal
>
> The documentation on the website for the defaults of CQLSH appear to be
> incorrect and contain numerous errors (at least for the latest and greatest)
> For this page:
> [https://cassandra.apache.org/doc/latest/tools/cqlsh.html]
> {{MINBATCHSIZE}} is listed as defaulting to 2. Code says this is 10.
> https://github.com/apache/cassandra/blob/trunk/pylib/cqlshlib/copyutil.py#L355
> Chunksize says 1000, actually set to 5000.
> https://github.com/apache/cassandra/blob/trunk/pylib/cqlshlib/copyutil.py#L352
> NumProcessis is also off...
> "NUMPROCESSES
> The number of child worker processes to create for COPY tasks. Defaults to a
> max of 4 for COPY FROM and 16 for COPY TO. However, at most (num_cores - 1)
> processes will be created."
> Default is the number of cores -1 or 16 which ever is smaller, and you can
> set this value to anything. See the following code
> https://github.com/apache/cassandra/blob/trunk/pylib/cqlshlib/copyutil.py#L361
> https://github.com/apache/cassandra/blob/trunk/pylib/cqlshlib/copyutil.py#L407
>
>
>
--
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
[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=17347732#comment-17347732 ] Ekaterina Dimitrova edited comment on CASSANDRA-16670 at 5/19/21, 7:55 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 on a failure. 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 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. > 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-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16679) HintedHandoffAddRemoveNodesTest is failing
[ https://issues.apache.org/jira/browse/CASSANDRA-16679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17347838#comment-17347838 ] Ekaterina Dimitrova edited comment on CASSANDRA-16679 at 5/19/21, 7:32 PM: --- First observations - this test fails only when the whole class is run. Running on its own it succeeds 500 runs. Also, the original python DTest looks good in Jenkins. I am wondering whether it is not in-jvm issue. This reminds me of CASSANDRA-16598 where there is a suspicion that the node didn't really go down //CC [~blerer] as he is tackling CASSANDRA-16598 was (Author: e.dimitrova): First observations - this test fails only when the whole class is run. Running on its own it succeeds 500 runs. Also, the original python DTest looks good in Jenkins. I am wondering whether it is not in-jvm issue. This reminds me of CASSANDRA-16598 where there is a suspicion that the node didn't really go down > HintedHandoffAddRemoveNodesTest is failing > -- > > Key: CASSANDRA-16679 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16679 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.0-rc > > > https://ci-cassandra.apache.org/job/Cassandra-devbranch/785/testReport/junit/org.apache.cassandra.distributed.test/HintedHandoffAddRemoveNodesTest/shouldStreamHintsDuringDecommission/ > Java 8 > [https://app.circleci.com/pipelines/github/adelapena/cassandra/464/workflows/888e47fb-e432-47f2-97df-c34a0d33753a/jobs/4104] > > and Java 11 > > [https://app.circleci.com/pipelines/github/adelapena/cassandra/464/workflows/ce0f0690-e488-4b5b-ab82-ce92a2f336d8/jobs/4105] -- 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
[jira] [Commented] (CASSANDRA-16679) HintedHandoffAddRemoveNodesTest is failing
[ https://issues.apache.org/jira/browse/CASSANDRA-16679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17347838#comment-17347838 ] Ekaterina Dimitrova commented on CASSANDRA-16679: - First observations - this test fails only when the whole class is run. Running on its own it succeeds 500 runs. Also, the original python DTest looks good in Jenkins. I am wondering whether it is not in-jvm issue. This reminds me of CASSANDRA-16598 where there is a suspicion that the node didn't really go down > HintedHandoffAddRemoveNodesTest is failing > -- > > Key: CASSANDRA-16679 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16679 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.0-rc > > > https://ci-cassandra.apache.org/job/Cassandra-devbranch/785/testReport/junit/org.apache.cassandra.distributed.test/HintedHandoffAddRemoveNodesTest/shouldStreamHintsDuringDecommission/ > Java 8 > [https://app.circleci.com/pipelines/github/adelapena/cassandra/464/workflows/888e47fb-e432-47f2-97df-c34a0d33753a/jobs/4104] > > and Java 11 > > [https://app.circleci.com/pipelines/github/adelapena/cassandra/464/workflows/ce0f0690-e488-4b5b-ab82-ce92a2f336d8/jobs/4105] -- 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
[jira] [Updated] (CASSANDRA-16681) org.apache.cassandra.utils.memory.LongBufferPoolTest - tests are flaky
[ https://issues.apache.org/jira/browse/CASSANDRA-16681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-16681: Fix Version/s: 4.0-rc 4.0 > org.apache.cassandra.utils.memory.LongBufferPoolTest - tests are flaky > -- > > Key: CASSANDRA-16681 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16681 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.0, 4.0-rc > > > Jenkins history: > [https://jenkins-cm4.apache.org/job/Cassandra-4.0/50/testReport/junit/org.apache.cassandra.utils.memory/LongBufferPoolTest/testPoolAllocateWithRecyclePartially/history/] > Fails being run in a loop in CircleCI: > https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/844/workflows/945011f4-00ac-4678-89f6-5c0db0a40169/jobs/5008 > -- 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
[jira] [Updated] (CASSANDRA-16681) org.apache.cassandra.utils.memory.LongBufferPoolTest - tests are flaky
[ https://issues.apache.org/jira/browse/CASSANDRA-16681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-16681: Bug Category: Parent values: Degradation(12984) Complexity: Normal Component/s: CI Discovered By: Unit Test Severity: Normal Status: Open (was: Triage Needed) > org.apache.cassandra.utils.memory.LongBufferPoolTest - tests are flaky > -- > > Key: CASSANDRA-16681 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16681 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Ekaterina Dimitrova >Priority: Normal > > Jenkins history: > [https://jenkins-cm4.apache.org/job/Cassandra-4.0/50/testReport/junit/org.apache.cassandra.utils.memory/LongBufferPoolTest/testPoolAllocateWithRecyclePartially/history/] > Fails being run in a loop in CircleCI: > https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/844/workflows/945011f4-00ac-4678-89f6-5c0db0a40169/jobs/5008 > -- 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
[jira] [Updated] (CASSANDRA-16681) org.apache.cassandra.utils.memory.LongBufferPoolTest - tests are flaky
[ https://issues.apache.org/jira/browse/CASSANDRA-16681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-16681: Description: Jenkins history: [https://jenkins-cm4.apache.org/job/Cassandra-4.0/50/testReport/junit/org.apache.cassandra.utils.memory/LongBufferPoolTest/testPoolAllocateWithRecyclePartially/history/] Fails being run in a loop in CircleCI: https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/844/workflows/945011f4-00ac-4678-89f6-5c0db0a40169/jobs/5008 was: Jenkins history: [https://jenkins-cm4.apache.org/job/Cassandra-4.0/50/testReport/junit/org.apache.cassandra.utils.memory/LongBufferPoolTest/testPoolAllocateWithRecyclePartially/history/] Fails being run in a loop in CircleCI: > org.apache.cassandra.utils.memory.LongBufferPoolTest - tests are flaky > -- > > Key: CASSANDRA-16681 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16681 > Project: Cassandra > Issue Type: Bug >Reporter: Ekaterina Dimitrova >Priority: Normal > > Jenkins history: > [https://jenkins-cm4.apache.org/job/Cassandra-4.0/50/testReport/junit/org.apache.cassandra.utils.memory/LongBufferPoolTest/testPoolAllocateWithRecyclePartially/history/] > Fails being run in a loop in CircleCI: > https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/844/workflows/945011f4-00ac-4678-89f6-5c0db0a40169/jobs/5008 > -- 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
[jira] [Created] (CASSANDRA-16681) org.apache.cassandra.utils.memory.LongBufferPoolTest - tests are flaky
Ekaterina Dimitrova created CASSANDRA-16681: --- Summary: org.apache.cassandra.utils.memory.LongBufferPoolTest - tests are flaky Key: CASSANDRA-16681 URL: https://issues.apache.org/jira/browse/CASSANDRA-16681 Project: Cassandra Issue Type: Bug Reporter: Ekaterina Dimitrova Jenkins history: [https://jenkins-cm4.apache.org/job/Cassandra-4.0/50/testReport/junit/org.apache.cassandra.utils.memory/LongBufferPoolTest/testPoolAllocateWithRecyclePartially/history/] Fails being run in a loop in CircleCI: -- 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
[cassandra] branch trunk updated: Ninja: fix incorrect import for guava lib in row util
This is an automated email from the ASF dual-hosted git repository. ifesdjeen pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git The following commit(s) were added to refs/heads/trunk by this push: new 9a43241 Ninja: fix incorrect import for guava lib in row util 9a43241 is described below commit 9a432418f2277c40a1fe4b64049688d6354ecdca Author: Alex Petrov AuthorDate: Wed May 19 18:40:13 2021 +0200 Ninja: fix incorrect import for guava lib in row util --- test/distributed/org/apache/cassandra/distributed/impl/RowUtil.java | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/test/distributed/org/apache/cassandra/distributed/impl/RowUtil.java b/test/distributed/org/apache/cassandra/distributed/impl/RowUtil.java index 847287d..1702b55 100644 --- a/test/distributed/org/apache/cassandra/distributed/impl/RowUtil.java +++ b/test/distributed/org/apache/cassandra/distributed/impl/RowUtil.java @@ -25,10 +25,10 @@ import java.util.Iterator; import java.util.List; import com.google.common.collect.Iterators; +import com.google.common.collect.Lists; import com.datastax.driver.core.ResultSet; import com.datastax.driver.core.Row; -import com.google.monitoring.runtime.instrumentation.common.collect.Lists; import org.apache.cassandra.cql3.ColumnSpecification; import org.apache.cassandra.cql3.UntypedResultSet; import org.apache.cassandra.distributed.api.QueryResults; - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16679) HintedHandoffAddRemoveNodesTest is failing
[ https://issues.apache.org/jira/browse/CASSANDRA-16679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17347770#comment-17347770 ] Ekaterina Dimitrova commented on CASSANDRA-16679: - CC [~maedhroz] - just FYI > HintedHandoffAddRemoveNodesTest is failing > -- > > Key: CASSANDRA-16679 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16679 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.0-rc > > > https://ci-cassandra.apache.org/job/Cassandra-devbranch/785/testReport/junit/org.apache.cassandra.distributed.test/HintedHandoffAddRemoveNodesTest/shouldStreamHintsDuringDecommission/ > Java 8 > [https://app.circleci.com/pipelines/github/adelapena/cassandra/464/workflows/888e47fb-e432-47f2-97df-c34a0d33753a/jobs/4104] > > and Java 11 > > [https://app.circleci.com/pipelines/github/adelapena/cassandra/464/workflows/ce0f0690-e488-4b5b-ab82-ce92a2f336d8/jobs/4105] -- 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
[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=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-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16670) Flaky ViewComplexTest and InsertUpdateIfConditionTest
[ https://issues.apache.org/jira/browse/CASSANDRA-16670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17347732#comment-17347732 ] Ekaterina Dimitrova commented on CASSANDRA-16670: - 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-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-16680) TimeWindowCompactionStrategyTest flaky
[ https://issues.apache.org/jira/browse/CASSANDRA-16680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andres de la Peña reassigned CASSANDRA-16680: - Assignee: Andres de la Peña > TimeWindowCompactionStrategyTest flaky > -- > > Key: CASSANDRA-16680 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16680 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Andres de la Peña >Priority: Normal > Fix For: 4.0-rc > > > Seen in Jenkins: > https://ci-cassandra.apache.org/job/Cassandra-devbranch/785/ > Failed two times with the multiplexer > [https://app.circleci.com/pipelines/github/adelapena/cassandra/461/workflows/7a837b82-c0d1-4e10-8932-c5908d2585de/jobs/4114] -- 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
[jira] [Updated] (CASSANDRA-16680) TimeWindowCompactionStrategyTest flaky
[ https://issues.apache.org/jira/browse/CASSANDRA-16680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-16680: Fix Version/s: 4.0-rc > TimeWindowCompactionStrategyTest flaky > -- > > Key: CASSANDRA-16680 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16680 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.0-rc > > > Seen in Jenkins: > https://ci-cassandra.apache.org/job/Cassandra-devbranch/785/ > Failed two times with the multiplexer > [https://app.circleci.com/pipelines/github/adelapena/cassandra/461/workflows/7a837b82-c0d1-4e10-8932-c5908d2585de/jobs/4114] -- 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
[jira] [Updated] (CASSANDRA-16680) TimeWindowCompactionStrategyTest flaky
[ https://issues.apache.org/jira/browse/CASSANDRA-16680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-16680: Bug Category: Parent values: Degradation(12984) Complexity: Normal Component/s: CI Discovered By: Unit Test Severity: Normal Status: Open (was: Triage Needed) > TimeWindowCompactionStrategyTest flaky > -- > > Key: CASSANDRA-16680 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16680 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Ekaterina Dimitrova >Priority: Normal > > Seen in Jenkins: > https://ci-cassandra.apache.org/job/Cassandra-devbranch/785/ > Failed two times with the multiplexer > [https://app.circleci.com/pipelines/github/adelapena/cassandra/461/workflows/7a837b82-c0d1-4e10-8932-c5908d2585de/jobs/4114] -- 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
[jira] [Created] (CASSANDRA-16680) TimeWindowCompactionStrategyTest flaky
Ekaterina Dimitrova created CASSANDRA-16680: --- Summary: TimeWindowCompactionStrategyTest flaky Key: CASSANDRA-16680 URL: https://issues.apache.org/jira/browse/CASSANDRA-16680 Project: Cassandra Issue Type: Bug Reporter: Ekaterina Dimitrova Seen in Jenkins: https://ci-cassandra.apache.org/job/Cassandra-devbranch/785/ Failed two times with the multiplexer [https://app.circleci.com/pipelines/github/adelapena/cassandra/461/workflows/7a837b82-c0d1-4e10-8932-c5908d2585de/jobs/4114] -- 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
[jira] [Updated] (CASSANDRA-16679) HintedHandoffAddRemoveNodesTest is failing
[ https://issues.apache.org/jira/browse/CASSANDRA-16679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-16679: Fix Version/s: 4.0-rc > HintedHandoffAddRemoveNodesTest is failing > -- > > Key: CASSANDRA-16679 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16679 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.0-rc > > > https://ci-cassandra.apache.org/job/Cassandra-devbranch/785/testReport/junit/org.apache.cassandra.distributed.test/HintedHandoffAddRemoveNodesTest/shouldStreamHintsDuringDecommission/ > Java 8 > [https://app.circleci.com/pipelines/github/adelapena/cassandra/464/workflows/888e47fb-e432-47f2-97df-c34a0d33753a/jobs/4104] > > and Java 11 > > [https://app.circleci.com/pipelines/github/adelapena/cassandra/464/workflows/ce0f0690-e488-4b5b-ab82-ce92a2f336d8/jobs/4105] -- 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
[jira] [Updated] (CASSANDRA-16679) HintedHandoffAddRemoveNodesTest is failing
[ https://issues.apache.org/jira/browse/CASSANDRA-16679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-16679: Description: https://ci-cassandra.apache.org/job/Cassandra-devbranch/785/testReport/junit/org.apache.cassandra.distributed.test/HintedHandoffAddRemoveNodesTest/shouldStreamHintsDuringDecommission/ Java 8 [https://app.circleci.com/pipelines/github/adelapena/cassandra/464/workflows/888e47fb-e432-47f2-97df-c34a0d33753a/jobs/4104] and Java 11 [https://app.circleci.com/pipelines/github/adelapena/cassandra/464/workflows/ce0f0690-e488-4b5b-ab82-ce92a2f336d8/jobs/4105] was: Java 8 [https://app.circleci.com/pipelines/github/adelapena/cassandra/464/workflows/888e47fb-e432-47f2-97df-c34a0d33753a/jobs/4104] and Java 11 [https://app.circleci.com/pipelines/github/adelapena/cassandra/464/workflows/ce0f0690-e488-4b5b-ab82-ce92a2f336d8/jobs/4105] > HintedHandoffAddRemoveNodesTest is failing > -- > > Key: CASSANDRA-16679 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16679 > Project: Cassandra > Issue Type: Bug >Reporter: Ekaterina Dimitrova >Priority: Normal > > https://ci-cassandra.apache.org/job/Cassandra-devbranch/785/testReport/junit/org.apache.cassandra.distributed.test/HintedHandoffAddRemoveNodesTest/shouldStreamHintsDuringDecommission/ > Java 8 > [https://app.circleci.com/pipelines/github/adelapena/cassandra/464/workflows/888e47fb-e432-47f2-97df-c34a0d33753a/jobs/4104] > > and Java 11 > > [https://app.circleci.com/pipelines/github/adelapena/cassandra/464/workflows/ce0f0690-e488-4b5b-ab82-ce92a2f336d8/jobs/4105] -- 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
[jira] [Updated] (CASSANDRA-16679) HintedHandoffAddRemoveNodesTest is failing
[ https://issues.apache.org/jira/browse/CASSANDRA-16679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-16679: Bug Category: Parent values: Degradation(12984) Complexity: Normal Component/s: CI Discovered By: User Report Severity: Normal Assignee: Ekaterina Dimitrova Status: Open (was: Triage Needed) > HintedHandoffAddRemoveNodesTest is failing > -- > > Key: CASSANDRA-16679 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16679 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > > https://ci-cassandra.apache.org/job/Cassandra-devbranch/785/testReport/junit/org.apache.cassandra.distributed.test/HintedHandoffAddRemoveNodesTest/shouldStreamHintsDuringDecommission/ > Java 8 > [https://app.circleci.com/pipelines/github/adelapena/cassandra/464/workflows/888e47fb-e432-47f2-97df-c34a0d33753a/jobs/4104] > > and Java 11 > > [https://app.circleci.com/pipelines/github/adelapena/cassandra/464/workflows/ce0f0690-e488-4b5b-ab82-ce92a2f336d8/jobs/4105] -- 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
[jira] [Created] (CASSANDRA-16679) HintedHandoffAddRemoveNodesTest is failing
Ekaterina Dimitrova created CASSANDRA-16679: --- Summary: HintedHandoffAddRemoveNodesTest is failing Key: CASSANDRA-16679 URL: https://issues.apache.org/jira/browse/CASSANDRA-16679 Project: Cassandra Issue Type: Bug Reporter: Ekaterina Dimitrova Java 8 [https://app.circleci.com/pipelines/github/adelapena/cassandra/464/workflows/888e47fb-e432-47f2-97df-c34a0d33753a/jobs/4104] and Java 11 [https://app.circleci.com/pipelines/github/adelapena/cassandra/464/workflows/ce0f0690-e488-4b5b-ab82-ce92a2f336d8/jobs/4105] -- 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
[jira] [Updated] (CASSANDRA-16678) ConnectionTest is flaky
[
https://issues.apache.org/jira/browse/CASSANDRA-16678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-16678:
Description:
Failure observed:
[https://ci-cassandra.apache.org/job/Cassandra-devbranch/785/testReport/junit/org.apache.cassandra.net/ConnectionTest/testMessageDeliveryOnReconnect_compression/]
3/100 failures in {{ConnectionTest observed in the new multiplexer, Java 8}}:
[https://app.circleci.com/pipelines/github/adelapena/cassandra/460/workflows/cf7dcec6-612c-45d1-8471-623bde481dca/jobs/4069]
And 2/100 with Java 11:
[https://app.circleci.com/pipelines/github/adelapena/cassandra/460/workflows/b750cd38-0263-4b5e-9bb8-a8be98214378/jobs/4065]
was:
Failure observed:
[https://ci-cassandra.apache.org/job/Cassandra-devbranch/785/testReport/junit/org.apache.cassandra.net/ConnectionTest/testMessageDeliveryOnReconnect_compression/]
3/100 failures in {{ConnectionTest observed in the new multiplexer}}:
[https://app.circleci.com/pipelines/github/adelapena/cassandra/460/workflows/cf7dcec6-612c-45d1-8471-623bde481dca/jobs/4069]
> ConnectionTest is flaky
> ---
>
> Key: CASSANDRA-16678
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16678
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: Ekaterina Dimitrova
>Priority: Normal
>
> Failure observed:
> [https://ci-cassandra.apache.org/job/Cassandra-devbranch/785/testReport/junit/org.apache.cassandra.net/ConnectionTest/testMessageDeliveryOnReconnect_compression/]
>
> 3/100 failures in {{ConnectionTest observed in the new multiplexer, Java 8}}:
> [https://app.circleci.com/pipelines/github/adelapena/cassandra/460/workflows/cf7dcec6-612c-45d1-8471-623bde481dca/jobs/4069]
> And 2/100 with Java 11:
> [https://app.circleci.com/pipelines/github/adelapena/cassandra/460/workflows/b750cd38-0263-4b5e-9bb8-a8be98214378/jobs/4065]
--
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
[jira] [Updated] (CASSANDRA-16678) ConnectionTest is flaky
[
https://issues.apache.org/jira/browse/CASSANDRA-16678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-16678:
-
Resolution: Fixed
Status: Resolved (was: Open)
> ConnectionTest is flaky
> ---
>
> Key: CASSANDRA-16678
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16678
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: Ekaterina Dimitrova
>Priority: Normal
>
> Failure observed:
> [https://ci-cassandra.apache.org/job/Cassandra-devbranch/785/testReport/junit/org.apache.cassandra.net/ConnectionTest/testMessageDeliveryOnReconnect_compression/]
>
> 3/100 failures in {{ConnectionTest observed in the new multiplexer}}:
> [https://app.circleci.com/pipelines/github/adelapena/cassandra/460/workflows/cf7dcec6-612c-45d1-8471-623bde481dca/jobs/4069]
--
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
[jira] [Updated] (CASSANDRA-16678) ConnectionTest is flaky
[
https://issues.apache.org/jira/browse/CASSANDRA-16678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-16678:
Bug Category: Parent values: Degradation(12984)
Complexity: Normal
Component/s: Test/dtest/java
Discovered By: User Report
Severity: Normal
Status: Open (was: Triage Needed)
> ConnectionTest is flaky
> ---
>
> Key: CASSANDRA-16678
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16678
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: Ekaterina Dimitrova
>Priority: Normal
>
> Failure observed:
> [https://ci-cassandra.apache.org/job/Cassandra-devbranch/785/testReport/junit/org.apache.cassandra.net/ConnectionTest/testMessageDeliveryOnReconnect_compression/]
>
> 3/100 failures in {{ConnectionTest observed in the new multiplexer}}:
> [https://app.circleci.com/pipelines/github/adelapena/cassandra/460/workflows/cf7dcec6-612c-45d1-8471-623bde481dca/jobs/4069]
--
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
[jira] [Created] (CASSANDRA-16678) ConnectionTest is flaky
Ekaterina Dimitrova created CASSANDRA-16678:
---
Summary: ConnectionTest is flaky
Key: CASSANDRA-16678
URL: https://issues.apache.org/jira/browse/CASSANDRA-16678
Project: Cassandra
Issue Type: Bug
Reporter: Ekaterina Dimitrova
Failure observed:
[https://ci-cassandra.apache.org/job/Cassandra-devbranch/785/testReport/junit/org.apache.cassandra.net/ConnectionTest/testMessageDeliveryOnReconnect_compression/]
3/100 failures in {{ConnectionTest observed in the new multiplexer}}:
[https://app.circleci.com/pipelines/github/adelapena/cassandra/460/workflows/cf7dcec6-612c-45d1-8471-623bde481dca/jobs/4069]
--
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
[jira] [Updated] (CASSANDRA-16677) Fix flaky ConnectionTest.testMessageDeliveryOnReconnect
[ https://issues.apache.org/jira/browse/CASSANDRA-16677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-16677: - Bug Category: Parent values: Code(13163) Complexity: Normal Component/s: Messaging/Internode Discovered By: Unit Test Severity: Normal Status: Open (was: Triage Needed) > Fix flaky ConnectionTest.testMessageDeliveryOnReconnect > --- > > Key: CASSANDRA-16677 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16677 > Project: Cassandra > Issue Type: Bug > Components: Messaging/Internode >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > > https://ci-cassandra.apache.org/job/Cassandra-devbranch/785/testReport/junit/org.apache.cassandra.net/ConnectionTest/testMessageDeliveryOnReconnect_compression/ > https://app.circleci.com/pipelines/github/adelapena/cassandra/460/workflows/cf7dcec6-612c-45d1-8471-623bde481dca/jobs/4069 > https://app.circleci.com/pipelines/github/adelapena/cassandra/460/workflows/b750cd38-0263-4b5e-9bb8-a8be98214378/jobs/4065 -- 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
[jira] [Assigned] (CASSANDRA-16677) Fix flaky ConnectionTest.testMessageDeliveryOnReconnect
[ https://issues.apache.org/jira/browse/CASSANDRA-16677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams reassigned CASSANDRA-16677: Assignee: Brandon Williams > Fix flaky ConnectionTest.testMessageDeliveryOnReconnect > --- > > Key: CASSANDRA-16677 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16677 > Project: Cassandra > Issue Type: Bug >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > > https://ci-cassandra.apache.org/job/Cassandra-devbranch/785/testReport/junit/org.apache.cassandra.net/ConnectionTest/testMessageDeliveryOnReconnect_compression/ > https://app.circleci.com/pipelines/github/adelapena/cassandra/460/workflows/cf7dcec6-612c-45d1-8471-623bde481dca/jobs/4069 > https://app.circleci.com/pipelines/github/adelapena/cassandra/460/workflows/b750cd38-0263-4b5e-9bb8-a8be98214378/jobs/4065 -- 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
[jira] [Created] (CASSANDRA-16677) Fix flaky ConnectionTest.testMessageDeliveryOnReconnect
Brandon Williams created CASSANDRA-16677: Summary: Fix flaky ConnectionTest.testMessageDeliveryOnReconnect Key: CASSANDRA-16677 URL: https://issues.apache.org/jira/browse/CASSANDRA-16677 Project: Cassandra Issue Type: Bug Reporter: Brandon Williams https://ci-cassandra.apache.org/job/Cassandra-devbranch/785/testReport/junit/org.apache.cassandra.net/ConnectionTest/testMessageDeliveryOnReconnect_compression/ https://app.circleci.com/pipelines/github/adelapena/cassandra/460/workflows/cf7dcec6-612c-45d1-8471-623bde481dca/jobs/4069 https://app.circleci.com/pipelines/github/adelapena/cassandra/460/workflows/b750cd38-0263-4b5e-9bb8-a8be98214378/jobs/4065 -- 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
[jira] [Updated] (CASSANDRA-16564) BLOG - Contribute to 4.0
[ https://issues.apache.org/jira/browse/CASSANDRA-16564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-16564: Status: Ready to Commit (was: Review In Progress) > BLOG - Contribute to 4.0 > > > Key: CASSANDRA-16564 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16564 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Low > > As GSoC and the World Party are approaching Melissa Logan asked me to help > her with a blog post she has drafted for new contributors. > The plan is to update it later when the onboarding process is revised. -- 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
[jira] [Updated] (CASSANDRA-16564) BLOG - Contribute to 4.0
[ https://issues.apache.org/jira/browse/CASSANDRA-16564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-16564: Test and Documentation Plan: Ended up never using this ticket for communicating the efforts as we agreed initially. I was informed the tutorial is already published [here |https://opensource.com/article/21/5/apache-cassandra] was: Ended up never using this ticket. Tutorial published [here |https://opensource.com/article/21/5/apache-cassandra] > BLOG - Contribute to 4.0 > > > Key: CASSANDRA-16564 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16564 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Low > Fix For: 4.0-rc2 > > > As GSoC and the World Party are approaching Melissa Logan asked me to help > her with a blog post she has drafted for new contributors. > The plan is to update it later when the onboarding process is revised. -- 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
[jira] [Updated] (CASSANDRA-16564) BLOG - Contribute to 4.0
[ https://issues.apache.org/jira/browse/CASSANDRA-16564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-16564: Reviewers: Berenguer Blasi, Ekaterina Dimitrova Status: Review In Progress (was: Patch Available) > BLOG - Contribute to 4.0 > > > Key: CASSANDRA-16564 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16564 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Low > > As GSoC and the World Party are approaching Melissa Logan asked me to help > her with a blog post she has drafted for new contributors. > The plan is to update it later when the onboarding process is revised. -- 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
[jira] [Updated] (CASSANDRA-16564) BLOG - Contribute to 4.0
[ https://issues.apache.org/jira/browse/CASSANDRA-16564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-16564: Test and Documentation Plan: Ended up never using this ticket. Tutorial published [here |https://opensource.com/article/21/5/apache-cassandra] Status: Patch Available (was: In Progress) > BLOG - Contribute to 4.0 > > > Key: CASSANDRA-16564 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16564 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Low > > As GSoC and the World Party are approaching Melissa Logan asked me to help > her with a blog post she has drafted for new contributors. > The plan is to update it later when the onboarding process is revised. -- 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
[jira] [Updated] (CASSANDRA-16564) BLOG - Contribute to 4.0
[ https://issues.apache.org/jira/browse/CASSANDRA-16564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-16564: Fix Version/s: 4.0-rc2 Source Control Link: https://opensource.com/article/21/5/apache-cassandra Resolution: Fixed Status: Resolved (was: Ready to Commit) > BLOG - Contribute to 4.0 > > > Key: CASSANDRA-16564 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16564 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Low > Fix For: 4.0-rc2 > > > As GSoC and the World Party are approaching Melissa Logan asked me to help > her with a blog post she has drafted for new contributors. > The plan is to update it later when the onboarding process is revised. -- 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
[jira] [Updated] (CASSANDRA-16657) Flaky TestPaxos
[
https://issues.apache.org/jira/browse/CASSANDRA-16657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-16657:
Since Version: (was: 4.0-rc1)
> Flaky TestPaxos
> ---
>
> Key: CASSANDRA-16657
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16657
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Berenguer Blasi
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-rc2, 4.0, 4.0.x
>
>
> During testing for some other ticket I found in a test run
> [this|https://ci-cassandra.apache.org/job/Cassandra-devbranch/736/testReport/junit/dtest-novnode.paxos_test/TestPaxos/test_cluster_availability/]
> paxos failure
> {noformat}
> Error Message
> cassandra.Unavailable: Error from server: code=1000 [Unavailable exception]
> message="Cannot achieve consistency level SERIAL" info={'consistency':
> 'SERIAL', 'required_replicas': 1, 'alive_replicas': 0}
> Stacktrace
> self =
> @pytest.mark.no_vnodes
> def test_cluster_availability(self):
> # Warning, a change in partitioner or a change in CCM token allocation
> # may require the partition keys of these inserts to be changed.
> # This must not use vnodes as it relies on assumed token values.
>
> session = self.prepare(nodes=3)
> session.execute("CREATE TABLE test (k int PRIMARY KEY, v int)")
> session.execute("INSERT INTO test (k, v) VALUES (0, 0) IF NOT EXISTS")
>
> self.cluster.nodelist()[2].stop()
> session.execute("INSERT INTO test (k, v) VALUES (1, 1) IF NOT EXISTS")
>
> self.cluster.nodelist()[1].stop()
> session.execute("INSERT INTO test (k, v) VALUES (3, 2) IF NOT EXISTS")
>
> self.cluster.nodelist()[1].start()
> session.execute("INSERT INTO test (k, v) VALUES (5, 5) IF NOT EXISTS")
>
> self.cluster.nodelist()[2].start()
> > session.execute("INSERT INTO test (k, v) VALUES (6, 6) IF NOT EXISTS")
> paxos_test.py:83:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> ../venv/src/cassandra-driver/cassandra/cluster.py:2618: in execute
> return self.execute_async(query, parameters, trace, custom_payload,
> timeout, execution_profile, paging_state, host, execute_as).result()
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> self = coordinator_host=127.0.0.2:9042>
> def result(self):
> """
> Return the final result or raise an Exception if errors were
> encountered. If the final result or error has not been set
> yet, this method will block until it is set, or the timeout
> set for the request expires.
>
> Timeout is specified in the Session request execution functions.
> If the timeout is exceeded, an :exc:`cassandra.OperationTimedOut`
> will be raised.
> This is a client-side timeout. For more information
> about server-side coordinator timeouts, see
> :class:`.policies.RetryPolicy`.
>
> Example usage::
>
> >>> future = session.execute_async("SELECT * FROM mycf")
> >>> # do other stuff...
>
> >>> try:
> ... rows = future.result()
> ... for row in rows:
> ... ... # process results
> ... except Exception:
> ... log.exception("Operation failed:")
>
> """
> self._event.wait()
> if self._final_result is not _NOT_SET:
> return ResultSet(self, self._final_result)
> else:
> > raise self._final_exception
> E cassandra.Unavailable: Error from server: code=1000 [Unavailable
> exception] message="Cannot achieve consistency level SERIAL"
> info={'consistency': 'SERIAL', 'required_replicas': 1, 'alive_replicas': 0}
> ../venv/src/cassandra-driver/cassandra/cluster.py:4894: Unavailable
> {noformat}
--
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
[jira] [Updated] (CASSANDRA-16657) Flaky TestPaxos
[
https://issues.apache.org/jira/browse/CASSANDRA-16657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-16657:
Fix Version/s: (was: 4.0-rc)
4.0.x
4.0
4.0-rc2
Since Version: 4.0-rc1
Source Control Link:
https://github.com/apache/cassandra-dtest/commit/e94e930d2c1de6b7b6824d163e0c42f6b96ba492
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
> Flaky TestPaxos
> ---
>
> Key: CASSANDRA-16657
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16657
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Berenguer Blasi
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-rc2, 4.0, 4.0.x
>
>
> During testing for some other ticket I found in a test run
> [this|https://ci-cassandra.apache.org/job/Cassandra-devbranch/736/testReport/junit/dtest-novnode.paxos_test/TestPaxos/test_cluster_availability/]
> paxos failure
> {noformat}
> Error Message
> cassandra.Unavailable: Error from server: code=1000 [Unavailable exception]
> message="Cannot achieve consistency level SERIAL" info={'consistency':
> 'SERIAL', 'required_replicas': 1, 'alive_replicas': 0}
> Stacktrace
> self =
> @pytest.mark.no_vnodes
> def test_cluster_availability(self):
> # Warning, a change in partitioner or a change in CCM token allocation
> # may require the partition keys of these inserts to be changed.
> # This must not use vnodes as it relies on assumed token values.
>
> session = self.prepare(nodes=3)
> session.execute("CREATE TABLE test (k int PRIMARY KEY, v int)")
> session.execute("INSERT INTO test (k, v) VALUES (0, 0) IF NOT EXISTS")
>
> self.cluster.nodelist()[2].stop()
> session.execute("INSERT INTO test (k, v) VALUES (1, 1) IF NOT EXISTS")
>
> self.cluster.nodelist()[1].stop()
> session.execute("INSERT INTO test (k, v) VALUES (3, 2) IF NOT EXISTS")
>
> self.cluster.nodelist()[1].start()
> session.execute("INSERT INTO test (k, v) VALUES (5, 5) IF NOT EXISTS")
>
> self.cluster.nodelist()[2].start()
> > session.execute("INSERT INTO test (k, v) VALUES (6, 6) IF NOT EXISTS")
> paxos_test.py:83:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> ../venv/src/cassandra-driver/cassandra/cluster.py:2618: in execute
> return self.execute_async(query, parameters, trace, custom_payload,
> timeout, execution_profile, paging_state, host, execute_as).result()
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> self = coordinator_host=127.0.0.2:9042>
> def result(self):
> """
> Return the final result or raise an Exception if errors were
> encountered. If the final result or error has not been set
> yet, this method will block until it is set, or the timeout
> set for the request expires.
>
> Timeout is specified in the Session request execution functions.
> If the timeout is exceeded, an :exc:`cassandra.OperationTimedOut`
> will be raised.
> This is a client-side timeout. For more information
> about server-side coordinator timeouts, see
> :class:`.policies.RetryPolicy`.
>
> Example usage::
>
> >>> future = session.execute_async("SELECT * FROM mycf")
> >>> # do other stuff...
>
> >>> try:
> ... rows = future.result()
> ... for row in rows:
> ... ... # process results
> ... except Exception:
> ... log.exception("Operation failed:")
>
> """
> self._event.wait()
> if self._final_result is not _NOT_SET:
> return ResultSet(self, self._final_result)
> else:
> > raise self._final_exception
> E cassandra.Unavailable: Error from server: code=1000 [Unavailable
> exception] message="Cannot achieve consistency level SERIAL"
> info={'consistency': 'SERIAL', 'required_replicas': 1, 'alive_replicas': 0}
> ../venv/src/cassandra-driver/cassandra/cluster.py:4894: Unavailable
> {noformat}
--
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
[jira] [Updated] (CASSANDRA-16657) Flaky TestPaxos
[
https://issues.apache.org/jira/browse/CASSANDRA-16657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-16657:
Status: Ready to Commit (was: Review In Progress)
> Flaky TestPaxos
> ---
>
> Key: CASSANDRA-16657
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16657
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Berenguer Blasi
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-rc
>
>
> During testing for some other ticket I found in a test run
> [this|https://ci-cassandra.apache.org/job/Cassandra-devbranch/736/testReport/junit/dtest-novnode.paxos_test/TestPaxos/test_cluster_availability/]
> paxos failure
> {noformat}
> Error Message
> cassandra.Unavailable: Error from server: code=1000 [Unavailable exception]
> message="Cannot achieve consistency level SERIAL" info={'consistency':
> 'SERIAL', 'required_replicas': 1, 'alive_replicas': 0}
> Stacktrace
> self =
> @pytest.mark.no_vnodes
> def test_cluster_availability(self):
> # Warning, a change in partitioner or a change in CCM token allocation
> # may require the partition keys of these inserts to be changed.
> # This must not use vnodes as it relies on assumed token values.
>
> session = self.prepare(nodes=3)
> session.execute("CREATE TABLE test (k int PRIMARY KEY, v int)")
> session.execute("INSERT INTO test (k, v) VALUES (0, 0) IF NOT EXISTS")
>
> self.cluster.nodelist()[2].stop()
> session.execute("INSERT INTO test (k, v) VALUES (1, 1) IF NOT EXISTS")
>
> self.cluster.nodelist()[1].stop()
> session.execute("INSERT INTO test (k, v) VALUES (3, 2) IF NOT EXISTS")
>
> self.cluster.nodelist()[1].start()
> session.execute("INSERT INTO test (k, v) VALUES (5, 5) IF NOT EXISTS")
>
> self.cluster.nodelist()[2].start()
> > session.execute("INSERT INTO test (k, v) VALUES (6, 6) IF NOT EXISTS")
> paxos_test.py:83:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> ../venv/src/cassandra-driver/cassandra/cluster.py:2618: in execute
> return self.execute_async(query, parameters, trace, custom_payload,
> timeout, execution_profile, paging_state, host, execute_as).result()
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> self = coordinator_host=127.0.0.2:9042>
> def result(self):
> """
> Return the final result or raise an Exception if errors were
> encountered. If the final result or error has not been set
> yet, this method will block until it is set, or the timeout
> set for the request expires.
>
> Timeout is specified in the Session request execution functions.
> If the timeout is exceeded, an :exc:`cassandra.OperationTimedOut`
> will be raised.
> This is a client-side timeout. For more information
> about server-side coordinator timeouts, see
> :class:`.policies.RetryPolicy`.
>
> Example usage::
>
> >>> future = session.execute_async("SELECT * FROM mycf")
> >>> # do other stuff...
>
> >>> try:
> ... rows = future.result()
> ... for row in rows:
> ... ... # process results
> ... except Exception:
> ... log.exception("Operation failed:")
>
> """
> self._event.wait()
> if self._final_result is not _NOT_SET:
> return ResultSet(self, self._final_result)
> else:
> > raise self._final_exception
> E cassandra.Unavailable: Error from server: code=1000 [Unavailable
> exception] message="Cannot achieve consistency level SERIAL"
> info={'consistency': 'SERIAL', 'required_replicas': 1, 'alive_replicas': 0}
> ../venv/src/cassandra-driver/cassandra/cluster.py:4894: Unavailable
> {noformat}
--
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
[jira] [Commented] (CASSANDRA-16657) Flaky TestPaxos
[
https://issues.apache.org/jira/browse/CASSANDRA-16657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17347665#comment-17347665
]
Ekaterina Dimitrova commented on CASSANDRA-16657:
-
Comment addressed, thanks!
1000 successful runs:
[Java
8|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/838/workflows/53ce0b4f-25c3-40d7-a5e1-c9d4ad03dcbc/jobs/4972]
| [Java
11|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/838/workflows/0fc0909a-c4b4-41af-9f36-6f9c491f0e4b/jobs/4968]
Patch committed [here
|https://github.com/apache/cassandra-dtest/commit/e94e930d2c1de6b7b6824d163e0c42f6b96ba492],
thanks
> Flaky TestPaxos
> ---
>
> Key: CASSANDRA-16657
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16657
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Berenguer Blasi
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-rc
>
>
> During testing for some other ticket I found in a test run
> [this|https://ci-cassandra.apache.org/job/Cassandra-devbranch/736/testReport/junit/dtest-novnode.paxos_test/TestPaxos/test_cluster_availability/]
> paxos failure
> {noformat}
> Error Message
> cassandra.Unavailable: Error from server: code=1000 [Unavailable exception]
> message="Cannot achieve consistency level SERIAL" info={'consistency':
> 'SERIAL', 'required_replicas': 1, 'alive_replicas': 0}
> Stacktrace
> self =
> @pytest.mark.no_vnodes
> def test_cluster_availability(self):
> # Warning, a change in partitioner or a change in CCM token allocation
> # may require the partition keys of these inserts to be changed.
> # This must not use vnodes as it relies on assumed token values.
>
> session = self.prepare(nodes=3)
> session.execute("CREATE TABLE test (k int PRIMARY KEY, v int)")
> session.execute("INSERT INTO test (k, v) VALUES (0, 0) IF NOT EXISTS")
>
> self.cluster.nodelist()[2].stop()
> session.execute("INSERT INTO test (k, v) VALUES (1, 1) IF NOT EXISTS")
>
> self.cluster.nodelist()[1].stop()
> session.execute("INSERT INTO test (k, v) VALUES (3, 2) IF NOT EXISTS")
>
> self.cluster.nodelist()[1].start()
> session.execute("INSERT INTO test (k, v) VALUES (5, 5) IF NOT EXISTS")
>
> self.cluster.nodelist()[2].start()
> > session.execute("INSERT INTO test (k, v) VALUES (6, 6) IF NOT EXISTS")
> paxos_test.py:83:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> ../venv/src/cassandra-driver/cassandra/cluster.py:2618: in execute
> return self.execute_async(query, parameters, trace, custom_payload,
> timeout, execution_profile, paging_state, host, execute_as).result()
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> self = coordinator_host=127.0.0.2:9042>
> def result(self):
> """
> Return the final result or raise an Exception if errors were
> encountered. If the final result or error has not been set
> yet, this method will block until it is set, or the timeout
> set for the request expires.
>
> Timeout is specified in the Session request execution functions.
> If the timeout is exceeded, an :exc:`cassandra.OperationTimedOut`
> will be raised.
> This is a client-side timeout. For more information
> about server-side coordinator timeouts, see
> :class:`.policies.RetryPolicy`.
>
> Example usage::
>
> >>> future = session.execute_async("SELECT * FROM mycf")
> >>> # do other stuff...
>
> >>> try:
> ... rows = future.result()
> ... for row in rows:
> ... ... # process results
> ... except Exception:
> ... log.exception("Operation failed:")
>
> """
> self._event.wait()
> if self._final_result is not _NOT_SET:
> return ResultSet(self, self._final_result)
> else:
> > raise self._final_exception
> E cassandra.Unavailable: Error from server: code=1000 [Unavailable
> exception] message="Cannot achieve consistency level SERIAL"
> info={'consistency': 'SERIAL', 'required_replicas': 1, 'alive_replicas': 0}
> ../venv/src/cassandra-driver/cassandra/cluster.py:4894: Unavailable
> {noformat}
--
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
[cassandra-dtest] branch trunk updated: Fix paxos_test::test_cluster_availability authored by Ekaterina Dimitrova; reviewed by Berenguer Blasi for CASSANDRA-16657
This is an automated email from the ASF dual-hosted git repository.
edimitrova pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra-dtest.git
The following commit(s) were added to refs/heads/trunk by this push:
new e94e930 Fix paxos_test::test_cluster_availability authored by
Ekaterina Dimitrova; reviewed by Berenguer Blasi for CASSANDRA-16657
e94e930 is described below
commit e94e930d2c1de6b7b6824d163e0c42f6b96ba492
Author: Ekaterina Dimitrova
AuthorDate: Mon May 17 19:53:04 2021 -0400
Fix paxos_test::test_cluster_availability
authored by Ekaterina Dimitrova; reviewed by Berenguer Blasi for
CASSANDRA-16657
---
paxos_test.py | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/paxos_test.py b/paxos_test.py
index 6d03654..457b74f 100644
--- a/paxos_test.py
+++ b/paxos_test.py
@@ -67,19 +67,21 @@ class TestPaxos(Tester):
# This must not use vnodes as it relies on assumed token values.
session = self.prepare(nodes=3)
+node2 = self.cluster.nodelist()[1]
+node3 = self.cluster.nodelist()[2]
session.execute("CREATE TABLE test (k int PRIMARY KEY, v int)")
session.execute("INSERT INTO test (k, v) VALUES (0, 0) IF NOT EXISTS")
-self.cluster.nodelist()[2].stop()
+node3.stop()
session.execute("INSERT INTO test (k, v) VALUES (1, 1) IF NOT EXISTS")
-self.cluster.nodelist()[1].stop()
+node2.stop()
session.execute("INSERT INTO test (k, v) VALUES (3, 2) IF NOT EXISTS")
-self.cluster.nodelist()[1].start()
+node2.start(wait_for_binary_proto = True)
session.execute("INSERT INTO test (k, v) VALUES (5, 5) IF NOT EXISTS")
-self.cluster.nodelist()[2].start()
+node3.start(wait_for_binary_proto = True)
session.execute("INSERT INTO test (k, v) VALUES (6, 6) IF NOT EXISTS")
def test_contention_multi_iterations(self):
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16670) Flaky ViewComplexTest and InsertUpdateIfConditionTest
[ https://issues.apache.org/jira/browse/CASSANDRA-16670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-16670: Reviewers: Ekaterina Dimitrova, Ekaterina Dimitrova (was: Ekaterina Dimitrova) Ekaterina Dimitrova, Ekaterina Dimitrova Status: Review In Progress (was: Patch Available) > 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-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16657) Flaky TestPaxos
[
https://issues.apache.org/jira/browse/CASSANDRA-16657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-16657:
Reviewers: Berenguer Blasi, Ekaterina Dimitrova (was: Berenguer Blasi)
Status: Review In Progress (was: Patch Available)
> Flaky TestPaxos
> ---
>
> Key: CASSANDRA-16657
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16657
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Berenguer Blasi
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-rc
>
>
> During testing for some other ticket I found in a test run
> [this|https://ci-cassandra.apache.org/job/Cassandra-devbranch/736/testReport/junit/dtest-novnode.paxos_test/TestPaxos/test_cluster_availability/]
> paxos failure
> {noformat}
> Error Message
> cassandra.Unavailable: Error from server: code=1000 [Unavailable exception]
> message="Cannot achieve consistency level SERIAL" info={'consistency':
> 'SERIAL', 'required_replicas': 1, 'alive_replicas': 0}
> Stacktrace
> self =
> @pytest.mark.no_vnodes
> def test_cluster_availability(self):
> # Warning, a change in partitioner or a change in CCM token allocation
> # may require the partition keys of these inserts to be changed.
> # This must not use vnodes as it relies on assumed token values.
>
> session = self.prepare(nodes=3)
> session.execute("CREATE TABLE test (k int PRIMARY KEY, v int)")
> session.execute("INSERT INTO test (k, v) VALUES (0, 0) IF NOT EXISTS")
>
> self.cluster.nodelist()[2].stop()
> session.execute("INSERT INTO test (k, v) VALUES (1, 1) IF NOT EXISTS")
>
> self.cluster.nodelist()[1].stop()
> session.execute("INSERT INTO test (k, v) VALUES (3, 2) IF NOT EXISTS")
>
> self.cluster.nodelist()[1].start()
> session.execute("INSERT INTO test (k, v) VALUES (5, 5) IF NOT EXISTS")
>
> self.cluster.nodelist()[2].start()
> > session.execute("INSERT INTO test (k, v) VALUES (6, 6) IF NOT EXISTS")
> paxos_test.py:83:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> ../venv/src/cassandra-driver/cassandra/cluster.py:2618: in execute
> return self.execute_async(query, parameters, trace, custom_payload,
> timeout, execution_profile, paging_state, host, execute_as).result()
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> self = coordinator_host=127.0.0.2:9042>
> def result(self):
> """
> Return the final result or raise an Exception if errors were
> encountered. If the final result or error has not been set
> yet, this method will block until it is set, or the timeout
> set for the request expires.
>
> Timeout is specified in the Session request execution functions.
> If the timeout is exceeded, an :exc:`cassandra.OperationTimedOut`
> will be raised.
> This is a client-side timeout. For more information
> about server-side coordinator timeouts, see
> :class:`.policies.RetryPolicy`.
>
> Example usage::
>
> >>> future = session.execute_async("SELECT * FROM mycf")
> >>> # do other stuff...
>
> >>> try:
> ... rows = future.result()
> ... for row in rows:
> ... ... # process results
> ... except Exception:
> ... log.exception("Operation failed:")
>
> """
> self._event.wait()
> if self._final_result is not _NOT_SET:
> return ResultSet(self, self._final_result)
> else:
> > raise self._final_exception
> E cassandra.Unavailable: Error from server: code=1000 [Unavailable
> exception] message="Cannot achieve consistency level SERIAL"
> info={'consistency': 'SERIAL', 'required_replicas': 1, 'alive_replicas': 0}
> ../venv/src/cassandra-driver/cassandra/cluster.py:4894: Unavailable
> {noformat}
--
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
[jira] [Commented] (CASSANDRA-16637) LongLeveledCompactionStrategyCQLTest.stressTestCompactionStrategyManager fails
[
https://issues.apache.org/jira/browse/CASSANDRA-16637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17347641#comment-17347641
]
Ekaterina Dimitrova commented on CASSANDRA-16637:
-
I think we might miss different type of failure or further regression if we
completely skip it, I will defer the decision to [~marcuse]. I guess it also
depends on when he will have the time to work on the patch.
> LongLeveledCompactionStrategyCQLTest.stressTestCompactionStrategyManager fails
> --
>
> Key: CASSANDRA-16637
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16637
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Compaction/LCS
>Reporter: Adam Holmberg
>Assignee: Marcus Eriksson
>Priority: Normal
> Fix For: 4.0.x
>
>
> Test is failing occasionally as follows:
> {noformat}
> Caused by: java.lang.AssertionError: Got unexpected overlap in level 3
> at
> org.apache.cassandra.db.compaction.LeveledGenerations.addAll(LeveledGenerations.java:161)
> at
> org.apache.cassandra.db.compaction.LeveledManifest.addSSTables(LeveledManifest.java:131)
> at
> org.apache.cassandra.db.compaction.LeveledCompactionStrategy.addSSTable(LeveledCompactionStrategy.java:365)
> at
> org.apache.cassandra.db.compaction.CompactionStrategyManager.startup(CompactionStrategyManager.java:312)
> at
> org.apache.cassandra.db.compaction.CompactionStrategyManager.reload(CompactionStrategyManager.java:532)
> at
> org.apache.cassandra.db.compaction.CompactionStrategyManager.maybeReloadDiskBoundaries(CompactionStrategyManager.java:495)
> at
> org.apache.cassandra.db.compaction.CompactionStrategyManager.handleNotification(CompactionStrategyManager.java:743)
> at org.apache.cassandra.db.lifecycle.Tracker.notify(Tracker.java:508)
> at
> org.apache.cassandra.db.lifecycle.Tracker.notifyDiscarded(Tracker.java:502)
> at
> org.apache.cassandra.db.lifecycle.Tracker.replaceFlushed(Tracker.java:373)
> at
> org.apache.cassandra.db.ColumnFamilyStore.replaceFlushed(ColumnFamilyStore.java:1592)
> at
> org.apache.cassandra.db.ColumnFamilyStore$Flush.flushMemtable(ColumnFamilyStore.java:1194)
> at
> org.apache.cassandra.db.ColumnFamilyStore$Flush.run(ColumnFamilyStore.java:1075)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> {noformat}
> [Recent
> ci|https://ci-cassandra.apache.org/job/Cassandra-trunk/476/testReport/junit/org.apache.cassandra.db.compaction/LongLeveledCompactionStrategyCQLTest/stressTestCompactionStrategyManager/]
--
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
[jira] [Updated] (CASSANDRA-16581) Failure to execute queries should emit a KPI other than read timeout/unavailable so it can be alerted/tracked
[
https://issues.apache.org/jira/browse/CASSANDRA-16581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sam Tunnicliffe updated CASSANDRA-16581:
Status: Changes Suggested (was: Review In Progress)
Thanks, looks good to me except for a couple of minor things.
h3. ProtocolVersion
I'd suggest renaming {{DSE_VERSIONS}} to something like
{{KNOWN_INVALID_VERSIONS}}
h3. FrameEncoder
This change seems wrong, if we receive anything other than a {{Payload}} here,
it's an error. Is this some leftover debugging perhaps?
> Failure to execute queries should emit a KPI other than read
> timeout/unavailable so it can be alerted/tracked
> -
>
> Key: CASSANDRA-16581
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16581
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client, Observability/Metrics
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0-rc
>
>
> When we are unable to parse a message we do not have a way to detect this
> from a monitoring point of view so can get into situations where we believe
> the database is fine but the clients are on-fire. This case popped up in the
> 2.1 to 3.0 upgrade as paging state wasn’t mixed-mode safe.
--
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
[jira] [Commented] (CASSANDRA-16672) Retag ccm
[
https://issues.apache.org/jira/browse/CASSANDRA-16672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17347611#comment-17347611
]
Berenguer Blasi commented on CASSANDRA-16672:
-
Results are a bit noisy... I think I'll run them against circle to
doublecheck...
> Retag ccm
> -
>
> Key: CASSANDRA-16672
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16672
> Project: Cassandra
> Issue Type: Task
> Components: Test/dtest/python
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0-rc2, 4.0, 3.0.x, 3.11.x, 4.x
>
>
> CCM repro's trunk is several commits ahead from {{cassandra-test}} tag.
> Probably an oversight but retagging needs CI to be ran just to make sure
> nothing broke in between.
--
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
[jira] [Updated] (CASSANDRA-16668) Intermittent failure of SEPExecutorTest.changingMaxWorkersMeetsConcurrencyGoalsTest caused by race condition when shrinking maximum pool size to zero
[
https://issues.apache.org/jira/browse/CASSANDRA-16668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-16668:
--
Reviewers: Andres de la Peña, Jon Meredith (was: Jon Meredith)
> Intermittent failure of
> SEPExecutorTest.changingMaxWorkersMeetsConcurrencyGoalsTest caused by race
> condition when shrinking maximum pool size to zero
> -
>
> Key: CASSANDRA-16668
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16668
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Other
>Reporter: Matt Fleming
>Assignee: Matt Fleming
>Priority: Normal
> Fix For: 4.0-rc
>
>
> A difficult-to-hit race condition exists in
> changingMaxWorkersMeetsConcurrencyGoalsTest when changing the maximum pool
> size from 0 -> 4 which results in the test failing like so:
> {{junit.framework.AssertionFailedError: Test tasks did not hit max
> concurrency goal expected: but
> was:junit.framework.AssertionFailedError: Test tasks did not hit max
> concurrency goal expected: but was: at
> org.apache.cassandra.concurrent.SEPExecutorTest.assertMaxTaskConcurrency(SEPExecutorTest.java:198)
> at
> org.apache.cassandra.concurrent.SEPExecutorTest.changingMaxWorkersMeetsConcurrencyGoalsTest(SEPExecutorTest.java:132)}}
> I can hit this issue maybe 2/3 times for every 100 invocations of the unit
> test.
> The issue that causes the failure is that if tasks are still enqueued when
> the maximum pool size is set to zero and if all of the SEPWorker threads
> enter the STOP state before the pool size is bumped to 4, then no SEPWorker
> threads will be spun up to service the task queue. This causes the above
> error.
> Why don't we spin up SEPWorker threads when enqueing tasks? Because of the
> guard logic in addTask:
> [https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/concurrent/SEPExecutor.java#L113,L121]
> In this scenario taskPermits will not be zero (because we have tasks on the
> queue) so we never call {{maybeStartSpinningWorker()}}.
> A trick to make this issue much easier to hit is to insert a
> {{Thread.sleep(500)}} immediately after setting the pool size to zero. This
> has the effect of guaranteeing that all SEPWorker threads will be STOP'd
> before enqueueing more work.
> Here's a fix that attempts to spin up an SEPWorker whenever we grow the
> number of work permits:
> https://github.com/mfleming/cassandra/commit/071516d29e41da9924af24e8002822d3c6af0e01
--
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
[jira] [Comment Edited] (CASSANDRA-16672) Retag ccm
[
https://issues.apache.org/jira/browse/CASSANDRA-16672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17346588#comment-17346588
]
Berenguer Blasi edited comment on CASSANDRA-16672 at 5/19/21, 9:46 AM:
---
CI runs:
- Trunk: https://ci-cassandra.apache.org/job/Cassandra-devbranch/780/
- 4.0 https://ci-cassandra.apache.org/job/Cassandra-devbranch/785/
- 3.11 https://ci-cassandra.apache.org/job/Cassandra-devbranch/786/
- 3.0 https://ci-cassandra.apache.org/job/Cassandra-devbranch/787/
was (Author: bereng):
CI runs:
- Trunk: https://ci-cassandra.apache.org/job/Cassandra-devbranch/780/
- 4.0 https://ci-cassandra.apache.org/job/Cassandra-devbranch/785/
- 3.11 tbd
- 3.0 tbd
> Retag ccm
> -
>
> Key: CASSANDRA-16672
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16672
> Project: Cassandra
> Issue Type: Task
> Components: Test/dtest/python
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0-rc2, 4.0, 3.0.x, 3.11.x, 4.x
>
>
> CCM repro's trunk is several commits ahead from {{cassandra-test}} tag.
> Probably an oversight but retagging needs CI to be ran just to make sure
> nothing broke in between.
--
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
[jira] [Updated] (CASSANDRA-16670) Flaky ViewComplexTest and InsertUpdateIfConditionTest
[ https://issues.apache.org/jira/browse/CASSANDRA-16670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berenguer Blasi updated CASSANDRA-16670: Fix Version/s: 4.x 4.0 4.0-rc2 > 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-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16670) Flaky ViewComplexTest and InsertUpdateIfConditionTest
[ https://issues.apache.org/jira/browse/CASSANDRA-16670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berenguer Blasi updated CASSANDRA-16670: Test and Documentation Plan: See PR Status: Patch Available (was: In Progress) > 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 > > *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-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16672) Retag ccm
[
https://issues.apache.org/jira/browse/CASSANDRA-16672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17346588#comment-17346588
]
Berenguer Blasi edited comment on CASSANDRA-16672 at 5/19/21, 7:30 AM:
---
CI runs:
- Trunk: https://ci-cassandra.apache.org/job/Cassandra-devbranch/780/
- 4.0 https://ci-cassandra.apache.org/job/Cassandra-devbranch/785/
- 3.11 tbd
- 3.0 tbd
was (Author: bereng):
CI runs:
- Trunk: https://ci-cassandra.apache.org/job/Cassandra-devbranch/780/
- 4.0 tbd
- 3.11 tbd
- 3.0 tbd
> Retag ccm
> -
>
> Key: CASSANDRA-16672
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16672
> Project: Cassandra
> Issue Type: Task
> Components: Test/dtest/python
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0-rc2, 4.0, 3.0.x, 3.11.x, 4.x
>
>
> CCM repro's trunk is several commits ahead from {{cassandra-test}} tag.
> Probably an oversight but retagging needs CI to be ran just to make sure
> nothing broke in between.
--
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
[jira] [Commented] (CASSANDRA-16670) Flaky ViewComplexTest and InsertUpdateIfConditionTest
[
https://issues.apache.org/jira/browse/CASSANDRA-16670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17347335#comment-17347335
]
Berenguer Blasi commented on CASSANDRA-16670:
-
I added a fix for {{InsertUpdateIfConditionTest}} also for convenience. With
that one we can either move to the {{long}} section or raise timeout. I have
mixed thoughts about it as it's fast locally so I don't have a strong
preference...
> 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
>
> *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-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16670) Flaky ViewComplexTest and InsertUpdateIfConditionTest
[ https://issues.apache.org/jira/browse/CASSANDRA-16670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berenguer Blasi updated CASSANDRA-16670: Description: *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. was:Flaky [test|https://ci-cassandra.apache.org/job/Cassandra-4.0/43/testReport/junit/org.apache.cassandra.cql3/ViewComplexTest/testPartialDeleteSelectedColumnWithoutFlush_3_/] > 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 > > *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-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16676) Flaky InsertUpdateIfConditionTest
[ https://issues.apache.org/jira/browse/CASSANDRA-16676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berenguer Blasi updated CASSANDRA-16676: Source Control Link: See CASSANDRA-16670 Resolution: Fixed Status: Resolved (was: Ready to Commit) > Flaky InsertUpdateIfConditionTest > - > > Key: CASSANDRA-16676 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16676 > Project: Cassandra > Issue Type: Task > Components: Test/unit >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.0-rc2, 4.0, 4.x > > > Flaky > [InsertUpdateIfConditionTest|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_/] -- 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
[jira] [Updated] (CASSANDRA-16670) Flaky ViewComplexTest and InsertUpdateIfConditionTest
[ https://issues.apache.org/jira/browse/CASSANDRA-16670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berenguer Blasi updated CASSANDRA-16670: Summary: Flaky ViewComplexTest and InsertUpdateIfConditionTest (was: Flaky ViewComplexTest) > 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 > > Flaky > [test|https://ci-cassandra.apache.org/job/Cassandra-4.0/43/testReport/junit/org.apache.cassandra.cql3/ViewComplexTest/testPartialDeleteSelectedColumnWithoutFlush_3_/] -- 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
[jira] [Updated] (CASSANDRA-16676) Flaky InsertUpdateIfConditionTest
[ https://issues.apache.org/jira/browse/CASSANDRA-16676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berenguer Blasi updated CASSANDRA-16676: Reviewers: Berenguer Blasi Status: Review In Progress (was: Patch Available) > Flaky InsertUpdateIfConditionTest > - > > Key: CASSANDRA-16676 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16676 > Project: Cassandra > Issue Type: Task > Components: Test/unit >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.0-rc2, 4.0, 4.x > > > Flaky > [InsertUpdateIfConditionTest|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_/] -- 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
[jira] [Updated] (CASSANDRA-16676) Flaky InsertUpdateIfConditionTest
[ https://issues.apache.org/jira/browse/CASSANDRA-16676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berenguer Blasi updated CASSANDRA-16676: Status: Ready to Commit (was: Review In Progress) > Flaky InsertUpdateIfConditionTest > - > > Key: CASSANDRA-16676 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16676 > Project: Cassandra > Issue Type: Task > Components: Test/unit >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.0-rc2, 4.0, 4.x > > > Flaky > [InsertUpdateIfConditionTest|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_/] -- 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
[jira] [Updated] (CASSANDRA-16676) Flaky InsertUpdateIfConditionTest
[ https://issues.apache.org/jira/browse/CASSANDRA-16676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berenguer Blasi updated CASSANDRA-16676: Test and Documentation Plan: See CASSANDRA-16670 Status: Patch Available (was: In Progress) > Flaky InsertUpdateIfConditionTest > - > > Key: CASSANDRA-16676 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16676 > Project: Cassandra > Issue Type: Task > Components: Test/unit >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.0-rc2, 4.0, 4.x > > > Flaky > [InsertUpdateIfConditionTest|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_/] -- 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
[jira] [Updated] (CASSANDRA-16676) Flaky InsertUpdateIfConditionTest
[ https://issues.apache.org/jira/browse/CASSANDRA-16676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berenguer Blasi updated CASSANDRA-16676: Fix Version/s: 4.x 4.0 4.0-rc2 > Flaky InsertUpdateIfConditionTest > - > > Key: CASSANDRA-16676 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16676 > Project: Cassandra > Issue Type: Task > Components: Test/unit >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.0-rc2, 4.0, 4.x > > > Flaky > [InsertUpdateIfConditionTest|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_/] -- 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
[jira] [Updated] (CASSANDRA-16676) Flaky InsertUpdateIfConditionTest
[ https://issues.apache.org/jira/browse/CASSANDRA-16676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berenguer Blasi updated CASSANDRA-16676: Change Category: Quality Assurance Complexity: Normal Status: Open (was: Triage Needed) > Flaky InsertUpdateIfConditionTest > - > > Key: CASSANDRA-16676 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16676 > Project: Cassandra > Issue Type: Task > Components: Test/unit >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > > Flaky > [InsertUpdateIfConditionTest|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_/] -- 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
[jira] [Created] (CASSANDRA-16676) Flaky InsertUpdateIfConditionTest
Berenguer Blasi created CASSANDRA-16676: --- Summary: Flaky InsertUpdateIfConditionTest Key: CASSANDRA-16676 URL: https://issues.apache.org/jira/browse/CASSANDRA-16676 Project: Cassandra Issue Type: Task Components: Test/unit Reporter: Berenguer Blasi Assignee: Berenguer Blasi Flaky [InsertUpdateIfConditionTest|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_/] -- 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
