[jira] [Commented] (CASSANDRA-16758) Flaky ClientResourceLimitsTest
[
https://issues.apache.org/jira/browse/CASSANDRA-16758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17371023#comment-17371023
]
Berenguer Blasi commented on CASSANDRA-16758:
-
Andres is OOO but back tomorrow so I'd rather wait for him to be around than
hijack his PR in case he had some outstanding work we're not aware of.
> Flaky ClientResourceLimitsTest
> --
>
> Key: CASSANDRA-16758
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16758
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0-rc2, 4.0, 4.0.x
>
>
> Flaky
> [ClientResourceLimitsTest|https://ci-cassandra.apache.org/job/Cassandra-4.0.0/35/testReport/junit/org.apache.cassandra.transport/ClientResourceLimitsTest/testBackPressureWhenEndpointLimitExceeded_cdc/]
> {noformat}
> Error Message
> Timed out after waiting 5 seconds for paused connections metric to increment
> due to backpressure expected:<11> but was:<24>
> Stacktrace
> junit.framework.AssertionFailedError: Timed out after waiting 5 seconds for
> paused connections metric to increment due to backpressure expected:<11> but
> was:<24>
> at org.apache.cassandra.Util.spinAssertEquals(Util.java:610)
> at
> org.apache.cassandra.transport.ClientResourceLimitsTest.backPressureTest(ClientResourceLimitsTest.java:218)
> at
> org.apache.cassandra.transport.ClientResourceLimitsTest.testBackPressureWhenEndpointLimitExceeded(ClientResourceLimitsTest.java:179)
> Standard Output
> INFO [main] 2021-06-22 01:56:41,489 YamlConfigurationLoader.java:93 -
> Configuration location:
> file:home/cassandra/cassandra/build/test/cassandra.cdc.yaml
> DEBUG [main] 2021-06-22 01:56:41,491 YamlConfigurationLoader.java:112 -
> Loading settings from
> file:home/cassandra/cassandra/build/test/cassandra.cdc.yaml
> DEBUG [main] 2021-06-22 01:56:41,551 InternalLoggerFactory.java:63 - Using
> SLF4J as the default logging framework
> DEBUG [main] 2021-06-22 01:56:41,565 PlatformDependent0.java:417 - -D
> ...[truncated 765272 chars]...
> org.apache.cassandra.transport.SimpleClient.execute(SimpleClient.java:275)
> at
> org.apache.cassandra.transport.ClientResourceLimitsTest.lambda$testQueryUpdatesConcurrentMetricsUpdate$11(ClientResourceLimitsTest.java:352)
> at java.lang.Thread.run(Thread.java:748)
> DEBUG [Test Cluster-nio-worker-0] 2021-06-22 01:57:08,353 Slf4JLogger.java:81
> - Freed 24 thread-local buffer(s) from thread: Test Cluster-nio-worker-0
> INFO [main] 2021-06-22 01:57:08,364 Server.java:171 - Stop listening for CQL
> clients
> {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-16621) Replace spinAsserts code with Awaitility code
[
https://issues.apache.org/jira/browse/CASSANDRA-16621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17371021#comment-17371021
]
Berenguer Blasi commented on CASSANDRA-16621:
-
Hi [~djanand],
your PR has base {{trunk}} but if you intend to fix from 4.0.x upwards you'd
need to make {{4.0}} the base. Also can you include some CI please?
> Replace spinAsserts code with Awaitility code
> -
>
> Key: CASSANDRA-16621
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16621
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Berenguer Blasi
>Priority: Normal
> Labels: low-hanging-fruit
> Fix For: 4.0.x
>
>
> Currently spinAsserts does a similar thing to Awaitility which is being used
> more and more. We have now 2 ways of doing the same thing so it would be good
> to consolidate
--
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-16621) Replace spinAsserts code with Awaitility code
[ https://issues.apache.org/jira/browse/CASSANDRA-16621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17371016#comment-17371016 ] Jogesh Anand commented on CASSANDRA-16621: -- The change seems reasonable and attaching a PR. Can someone please review ? > Replace spinAsserts code with Awaitility code > - > > Key: CASSANDRA-16621 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16621 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Berenguer Blasi >Priority: Normal > Labels: low-hanging-fruit > Fix For: 4.0.x > > > Currently spinAsserts does a similar thing to Awaitility which is being used > more and more. We have now 2 ways of doing the same thing so it would be good > to consolidate -- 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-16764) Compaction repeatedly fails validateReallocation exception
[
https://issues.apache.org/jira/browse/CASSANDRA-16764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17370973#comment-17370973
]
Richard Hesse commented on CASSANDRA-16764:
---
[~dcapwell] we've deleted the bad object, but the error is still being thrown
on compaction. I guess it will take a while for the tombstone process to make
its way through? Or is this something that will require some manual commands to
recover from? Thanks again for your help and quick response!
> Compaction repeatedly fails validateReallocation exception
> --
>
> Key: CASSANDRA-16764
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16764
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Compaction/LCS
>Reporter: Richard Hesse
>Priority: Normal
>
> I have a few nodes in my ring that are stuck repeatedly trying to compact the
> same tables over and over again. I've run through the usual trick of rolling
> restarts, and it doesn't seem to help. This exception is logged on the nodes:
> {code}
> ERROR [CompactionExecutor:6] 2021-06-25 20:28:30,001 CassandraDaemon.java:244
> - Exception in thread Thread[CompactionExecutor:6,1,main]
> java.lang.RuntimeException: null
> at
> org.apache.cassandra.io.util.DataOutputBuffer.validateReallocation(DataOutputBuffer.java:134)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.io.util.DataOutputBuffer.calculateNewSize(DataOutputBuffer.java:152)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.io.util.DataOutputBuffer.expandToFit(DataOutputBuffer.java:159)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.io.util.DataOutputBuffer.doFlush(DataOutputBuffer.java:119)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.io.util.BufferedDataOutputStreamPlus.write(BufferedDataOutputStreamPlus.java:132)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.io.util.BufferedDataOutputStreamPlus.write(BufferedDataOutputStreamPlus.java:151)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.utils.ByteBufferUtil.writeWithVIntLength(ByteBufferUtil.java:296)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.db.marshal.AbstractType.writeValue(AbstractType.java:426)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.db.ClusteringPrefix$Serializer.serializeValuesWithoutSize(ClusteringPrefix.java:323)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.db.Clustering$Serializer.serialize(Clustering.java:131)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.db.ClusteringPrefix$Serializer.serialize(ClusteringPrefix.java:266)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.db.Serializers$NewFormatSerializer.serialize(Serializers.java:167)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.db.Serializers$NewFormatSerializer.serialize(Serializers.java:154)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.io.sstable.IndexInfo$Serializer.serialize(IndexInfo.java:103)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.io.sstable.IndexInfo$Serializer.serialize(IndexInfo.java:82)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.db.ColumnIndex.addIndexBlock(ColumnIndex.java:216)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at org.apache.cassandra.db.ColumnIndex.add(ColumnIndex.java:264)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.db.ColumnIndex.buildRowIndex(ColumnIndex.java:111)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.io.sstable.format.big.BigTableWriter.append(BigTableWriter.java:173)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.io.sstable.SSTableRewriter.append(SSTableRewriter.java:136)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.db.compaction.writers.MaxSSTableSizeWriter.realAppend(MaxSSTableSizeWriter.java:98)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.db.compaction.writers.CompactionAwareWriter.append(CompactionAwareWriter.java:143)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.db.compaction.CompactionTask.runMayThrow(CompactionTask.java:204)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:85)
>
[jira] [Commented] (CASSANDRA-16714) Fix org.apache.cassandra.utils.SlidingTimeRateTest.testConcurrentUpdateAndGet
[ https://issues.apache.org/jira/browse/CASSANDRA-16714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17370969#comment-17370969 ] Ekaterina Dimitrova commented on CASSANDRA-16714: - I took a quick look on the patch and I think that should work and lead to deterministic behavior. I just pushed CI run and the test in a loop 10 000 times with your patch [here|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1012/workflows/7ddcc619-9bf1-40af-a781-3fc541cfa187] I will finish my review tomorrow. > Fix org.apache.cassandra.utils.SlidingTimeRateTest.testConcurrentUpdateAndGet > - > > Key: CASSANDRA-16714 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16714 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Ekaterina Dimitrova >Assignee: Aleksandr Sorokoumov >Priority: Normal > Fix For: 3.11.x > > > Fix org.apache.cassandra.utils.SlidingTimeRateTest.testConcurrentUpdateAndGet > in Cassandra 3.11 > [https://jenkins-cm4.apache.org/job/Cassandra-3.11/174/testReport/junit/org.apache.cassandra.utils/SlidingTimeRateTest/testConcurrentUpdateAndGet_cdc/] > We should also propagate the fix to 4.0 where the utility class and the tests > also exist but they are not currently in use so to remove the noise the tests > are currently skipped from running at the moment. For reference - > CASSANDRA-16713 > -- 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-16714) Fix org.apache.cassandra.utils.SlidingTimeRateTest.testConcurrentUpdateAndGet
[ https://issues.apache.org/jira/browse/CASSANDRA-16714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-16714: Reviewers: Ekaterina Dimitrova, Ekaterina Dimitrova (was: Ekaterina Dimitrova) Ekaterina Dimitrova, Ekaterina Dimitrova Status: Review In Progress (was: Patch Available) > Fix org.apache.cassandra.utils.SlidingTimeRateTest.testConcurrentUpdateAndGet > - > > Key: CASSANDRA-16714 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16714 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Ekaterina Dimitrova >Assignee: Aleksandr Sorokoumov >Priority: Normal > Fix For: 3.11.x > > > Fix org.apache.cassandra.utils.SlidingTimeRateTest.testConcurrentUpdateAndGet > in Cassandra 3.11 > [https://jenkins-cm4.apache.org/job/Cassandra-3.11/174/testReport/junit/org.apache.cassandra.utils/SlidingTimeRateTest/testConcurrentUpdateAndGet_cdc/] > We should also propagate the fix to 4.0 where the utility class and the tests > also exist but they are not currently in use so to remove the noise the tests > are currently skipped from running at the moment. For reference - > CASSANDRA-16713 > -- 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-14893) Backport CASSANDRA-10508 to 3.0 branch
[ https://issues.apache.org/jira/browse/CASSANDRA-14893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-14893: - Reviewers: Brandon Williams Status: Review In Progress (was: Patch Available) > Backport CASSANDRA-10508 to 3.0 branch > -- > > Key: CASSANDRA-14893 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14893 > Project: Cassandra > Issue Type: Improvement > Components: Messaging/Internode >Reporter: Tommy Stendahl >Assignee: Tommy Stendahl >Priority: Normal > > With CASSANDRA-10508 we removed the hard coded SSL protocols and in favor of > the jvm default values in th 3.x branch. When reading through that jira it > looks like it was never considered to do the same change in the 3.0 branch > but the reasoning for the change seams just as valid for 3.0. And the issue > with CASSANDRA-14842 when upgrading 3.0.x->4.0 would not have happened. -- 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-14893) Backport CASSANDRA-10508 to 3.0 branch
[ https://issues.apache.org/jira/browse/CASSANDRA-14893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17370950#comment-17370950 ] Brandon Williams commented on CASSANDRA-14893: -- [Jenkins|https://ci-cassandra.apache.org/job/Cassandra-devbranch/882/] doesn't seem to have any related failures, +1. > Backport CASSANDRA-10508 to 3.0 branch > -- > > Key: CASSANDRA-14893 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14893 > Project: Cassandra > Issue Type: Improvement > Components: Messaging/Internode >Reporter: Tommy Stendahl >Assignee: Tommy Stendahl >Priority: Normal > > With CASSANDRA-10508 we removed the hard coded SSL protocols and in favor of > the jvm default values in th 3.x branch. When reading through that jira it > looks like it was never considered to do the same change in the 3.0 branch > but the reasoning for the change seams just as valid for 3.0. And the issue > with CASSANDRA-14842 when upgrading 3.0.x->4.0 would not have happened. -- 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-16764) Compaction repeatedly fails validateReallocation exception
[
https://issues.apache.org/jira/browse/CASSANDRA-16764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17370928#comment-17370928
]
Richard Hesse commented on CASSANDRA-16764:
---
Looking at the heap dump, there's definitely some application level garbage
that made its way in there. Yep, it's a 2GB column value.
> Compaction repeatedly fails validateReallocation exception
> --
>
> Key: CASSANDRA-16764
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16764
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Compaction/LCS
>Reporter: Richard Hesse
>Priority: Normal
>
> I have a few nodes in my ring that are stuck repeatedly trying to compact the
> same tables over and over again. I've run through the usual trick of rolling
> restarts, and it doesn't seem to help. This exception is logged on the nodes:
> {code}
> ERROR [CompactionExecutor:6] 2021-06-25 20:28:30,001 CassandraDaemon.java:244
> - Exception in thread Thread[CompactionExecutor:6,1,main]
> java.lang.RuntimeException: null
> at
> org.apache.cassandra.io.util.DataOutputBuffer.validateReallocation(DataOutputBuffer.java:134)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.io.util.DataOutputBuffer.calculateNewSize(DataOutputBuffer.java:152)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.io.util.DataOutputBuffer.expandToFit(DataOutputBuffer.java:159)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.io.util.DataOutputBuffer.doFlush(DataOutputBuffer.java:119)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.io.util.BufferedDataOutputStreamPlus.write(BufferedDataOutputStreamPlus.java:132)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.io.util.BufferedDataOutputStreamPlus.write(BufferedDataOutputStreamPlus.java:151)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.utils.ByteBufferUtil.writeWithVIntLength(ByteBufferUtil.java:296)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.db.marshal.AbstractType.writeValue(AbstractType.java:426)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.db.ClusteringPrefix$Serializer.serializeValuesWithoutSize(ClusteringPrefix.java:323)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.db.Clustering$Serializer.serialize(Clustering.java:131)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.db.ClusteringPrefix$Serializer.serialize(ClusteringPrefix.java:266)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.db.Serializers$NewFormatSerializer.serialize(Serializers.java:167)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.db.Serializers$NewFormatSerializer.serialize(Serializers.java:154)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.io.sstable.IndexInfo$Serializer.serialize(IndexInfo.java:103)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.io.sstable.IndexInfo$Serializer.serialize(IndexInfo.java:82)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.db.ColumnIndex.addIndexBlock(ColumnIndex.java:216)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at org.apache.cassandra.db.ColumnIndex.add(ColumnIndex.java:264)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.db.ColumnIndex.buildRowIndex(ColumnIndex.java:111)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.io.sstable.format.big.BigTableWriter.append(BigTableWriter.java:173)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.io.sstable.SSTableRewriter.append(SSTableRewriter.java:136)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.db.compaction.writers.MaxSSTableSizeWriter.realAppend(MaxSSTableSizeWriter.java:98)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.db.compaction.writers.CompactionAwareWriter.append(CompactionAwareWriter.java:143)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.db.compaction.CompactionTask.runMayThrow(CompactionTask.java:204)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:85)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:61)
>
[jira] [Commented] (CASSANDRA-14930) decommission may cause timeout because messaging backlog is cleared
[
https://issues.apache.org/jira/browse/CASSANDRA-14930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17370869#comment-17370869
]
Brandon Williams commented on CASSANDRA-14930:
--
||Jenkins||
|[3.0|https://ci-cassandra.apache.org/job/Cassandra-devbranch/879/]|
|[3.11|https://ci-cassandra.apache.org/job/Cassandra-devbranch/880/]|
Failures for 3.0 look unrelated, same for 3.11 most of which are known from
CASSANDRA-16770.
+1
> decommission may cause timeout because messaging backlog is cleared
>
>
> Key: CASSANDRA-14930
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14930
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Coordination, Legacy/Core
>Reporter: Zhao Yang
>Assignee: Zhao Yang
>Priority: Normal
> Fix For: 3.0.x, 3.11.x
>
>
> On a 3-node cluster with RF=2, decommissioning a node may cause quorum write
> timeout because messaging backlog to decommissioned node is cleared via
> {{Gossiper#removeEndpoint() -> OutboundTcpConnection#closeSocket()}}.
> (Timeout is less likely to happen with RF=3, because we can afford one less
> response)
> {code:java}
> What happened:
> 1. [WriteStage] before the leaving node is removed from tokenmetadata, the
> write endpoints are generated ( leaving endpoint is included )
> 2. [GossipStage] the leaving node is removed from tokenmetadata, no more
> future write handler will include leaving endpoints
> 3. [WriteStage] write handlers sends messages to messaging-service backlog
> 4. [GossipStage] messaging-service backlog is cleared, messages are not sent
> and connection closed
> 5. [WriteStage] write time out
> {code}
> |patch|
> |[3.0|https://github.com/jasonstack/cassandra/commits/decommission_timeout_3.0]|
> |[3.11|https://github.com/jasonstack/cassandra/commits/decommission_timeout_3.11]|
> We can avoid it by delaying to destroy messaging connection so that messages
> are sent and responded. This patch also avoids reopening already closed
> connection on {{MessagingService#convict()}}.
> New messaging framework rewrite in {{Trunk}} avoids the issues by not
> clearing messaging backlog.
--
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-14930) decommission may cause timeout because messaging backlog is cleared
[
https://issues.apache.org/jira/browse/CASSANDRA-14930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-14930:
-
Reviewers: Brandon Williams, Brandon Williams (was: Brandon Williams)
Brandon Williams, Brandon Williams
Status: Review In Progress (was: Patch Available)
> decommission may cause timeout because messaging backlog is cleared
>
>
> Key: CASSANDRA-14930
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14930
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Coordination, Legacy/Core
>Reporter: Zhao Yang
>Assignee: Zhao Yang
>Priority: Normal
> Fix For: 3.0.x, 3.11.x
>
>
> On a 3-node cluster with RF=2, decommissioning a node may cause quorum write
> timeout because messaging backlog to decommissioned node is cleared via
> {{Gossiper#removeEndpoint() -> OutboundTcpConnection#closeSocket()}}.
> (Timeout is less likely to happen with RF=3, because we can afford one less
> response)
> {code:java}
> What happened:
> 1. [WriteStage] before the leaving node is removed from tokenmetadata, the
> write endpoints are generated ( leaving endpoint is included )
> 2. [GossipStage] the leaving node is removed from tokenmetadata, no more
> future write handler will include leaving endpoints
> 3. [WriteStage] write handlers sends messages to messaging-service backlog
> 4. [GossipStage] messaging-service backlog is cleared, messages are not sent
> and connection closed
> 5. [WriteStage] write time out
> {code}
> |patch|
> |[3.0|https://github.com/jasonstack/cassandra/commits/decommission_timeout_3.0]|
> |[3.11|https://github.com/jasonstack/cassandra/commits/decommission_timeout_3.11]|
> We can avoid it by delaying to destroy messaging connection so that messages
> are sent and responded. This patch also avoids reopening already closed
> connection on {{MessagingService#convict()}}.
> New messaging framework rewrite in {{Trunk}} avoids the issues by not
> clearing messaging backlog.
--
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-16764) Compaction repeatedly fails validateReallocation exception
[
https://issues.apache.org/jira/browse/CASSANDRA-16764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17370845#comment-17370845
]
Richard Hesse commented on CASSANDRA-16764:
---
[~dcapwell] Thanks for the quick response! The clustering key is ASCII text of
a URI path. I guess we had some customers pick some long ones. I'll try to grab
a heap dump later tonight.
> Compaction repeatedly fails validateReallocation exception
> --
>
> Key: CASSANDRA-16764
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16764
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Compaction/LCS
>Reporter: Richard Hesse
>Priority: Normal
>
> I have a few nodes in my ring that are stuck repeatedly trying to compact the
> same tables over and over again. I've run through the usual trick of rolling
> restarts, and it doesn't seem to help. This exception is logged on the nodes:
> {code}
> ERROR [CompactionExecutor:6] 2021-06-25 20:28:30,001 CassandraDaemon.java:244
> - Exception in thread Thread[CompactionExecutor:6,1,main]
> java.lang.RuntimeException: null
> at
> org.apache.cassandra.io.util.DataOutputBuffer.validateReallocation(DataOutputBuffer.java:134)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.io.util.DataOutputBuffer.calculateNewSize(DataOutputBuffer.java:152)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.io.util.DataOutputBuffer.expandToFit(DataOutputBuffer.java:159)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.io.util.DataOutputBuffer.doFlush(DataOutputBuffer.java:119)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.io.util.BufferedDataOutputStreamPlus.write(BufferedDataOutputStreamPlus.java:132)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.io.util.BufferedDataOutputStreamPlus.write(BufferedDataOutputStreamPlus.java:151)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.utils.ByteBufferUtil.writeWithVIntLength(ByteBufferUtil.java:296)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.db.marshal.AbstractType.writeValue(AbstractType.java:426)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.db.ClusteringPrefix$Serializer.serializeValuesWithoutSize(ClusteringPrefix.java:323)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.db.Clustering$Serializer.serialize(Clustering.java:131)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.db.ClusteringPrefix$Serializer.serialize(ClusteringPrefix.java:266)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.db.Serializers$NewFormatSerializer.serialize(Serializers.java:167)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.db.Serializers$NewFormatSerializer.serialize(Serializers.java:154)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.io.sstable.IndexInfo$Serializer.serialize(IndexInfo.java:103)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.io.sstable.IndexInfo$Serializer.serialize(IndexInfo.java:82)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.db.ColumnIndex.addIndexBlock(ColumnIndex.java:216)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at org.apache.cassandra.db.ColumnIndex.add(ColumnIndex.java:264)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.db.ColumnIndex.buildRowIndex(ColumnIndex.java:111)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.io.sstable.format.big.BigTableWriter.append(BigTableWriter.java:173)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.io.sstable.SSTableRewriter.append(SSTableRewriter.java:136)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.db.compaction.writers.MaxSSTableSizeWriter.realAppend(MaxSSTableSizeWriter.java:98)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.db.compaction.writers.CompactionAwareWriter.append(CompactionAwareWriter.java:143)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.db.compaction.CompactionTask.runMayThrow(CompactionTask.java:204)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:85)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
>
[jira] [Updated] (CASSANDRA-16738) Remediate Cassandra 3.11.10 JAR dependency vulnerability - org.yaml_snakeyaml
[ https://issues.apache.org/jira/browse/CASSANDRA-16738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Gomez updated CASSANDRA-16738: - Fix Version/s: 3.11.x > Remediate Cassandra 3.11.10 JAR dependency vulnerability - org.yaml_snakeyaml > - > > Key: CASSANDRA-16738 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16738 > Project: Cassandra > Issue Type: Improvement > Components: Dependencies >Reporter: Daniel Gomez >Priority: Normal > Fix For: 3.11.x > > > A JAR dependency is flagged in Cassandra 3.11.10 as having vulnerabilities > that have been fixed in newer releases. The following is the Cassandra > 3.11.10 source tree for their JAR dependencies: > [https://github.com/apache/cassandra/tree/181a4969290f1c756089b2993a638fe403bc1314/lib] > . > JAR *org.yaml_snakeyaml* version *1.11* has the following vulnerability and > is fixed in version *1.26*. Recommendation is to upgrade to version *2.29* or > greater. > > ||id||cvss||desc||link||packageName||packageVersion||severity||status||vecStr|| > |CVE-2017-18640|7.5|The Alias feature in SnakeYAML 1.18 allows entity > expansion during a load operation, a related issue to > CVE-2003-1564.|https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2017-18640|org.yaml_snakeyaml|1.11|high|fixed > in 1.26|CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H| > > A possible fix strategy is to simply update the JAR to their newest version. > * See [https://mvnrepository.com/artifact/org.yaml/snakeyaml/1.29] -- 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-16734) Remediate Cassandra 3.11.10 JAR dependency vulnerabilities
[ https://issues.apache.org/jira/browse/CASSANDRA-16734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Gomez updated CASSANDRA-16734: - Fix Version/s: 3.11.x > Remediate Cassandra 3.11.10 JAR dependency vulnerabilities > --- > > Key: CASSANDRA-16734 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16734 > Project: Cassandra > Issue Type: Improvement > Components: Dependencies >Reporter: Daniel Gomez >Priority: Normal > Fix For: 3.11.x > > > Several JAR dependencies are flagged in Cassandra 3.11.10 as having > vulnerabilities that have been fixed in newer releases. > The following is the Cassandra 3.11.10 source tree for their JAR > dependencies: > [https://github.com/apache/cassandra/tree/181a4969290f1c756089b2993a638fe403bc1314/lib] > A possible fix strategy is to simply update the JARs to their newest version. > See the JAR files available for each vulnerable library: > * See > [https://mvnrepository.com/artifact/com.fasterxml.jackson.core/jackson-databind/2.9.10.8] > * See [https://mvnrepository.com/artifact/io.netty/netty-all/4.1.65.Final] > * See > [https://mvnrepository.com/artifact/org.apache.thrift/libthrift/0.9.3-1] > * See > [https://mvnrepository.com/artifact/com.thinkaurelius.thrift/thrift-server/0.3.9] > * See [https://mvnrepository.com/artifact/com.google.guava/guava/30.1.1-jre] > * See [https://mvnrepository.com/artifact/ch.qos.logback/logback-core/1.2.3] > * See [https://mvnrepository.com/artifact/org.yaml/snakeyaml/1.29] > * See [https://mvnrepository.com/artifact/commons-codec/commons-codec/1.15] -- 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-16739) Remediate Cassandra 3.11.10 JAR dependency vulnerability - org.apache.thrift_libthrift
[ https://issues.apache.org/jira/browse/CASSANDRA-16739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Gomez updated CASSANDRA-16739: - Fix Version/s: 3.11.x > Remediate Cassandra 3.11.10 JAR dependency vulnerability - > org.apache.thrift_libthrift > -- > > Key: CASSANDRA-16739 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16739 > Project: Cassandra > Issue Type: Improvement > Components: Dependencies >Reporter: Daniel Gomez >Priority: Normal > Fix For: 3.11.x > > > A JAR dependency is flagged in Cassandra 3.11.10 as having vulnerabilities > that have been fixed in newer releases. The following is the Cassandra > 3.11.10 source tree for their JAR dependencies: > [https://github.com/apache/cassandra/tree/181a4969290f1c756089b2993a638fe403bc1314/lib] > . > JAR *org.apache.thrift_libthrift* version *0.9.2* has the following > vulnerability and is fixed in version *0.9.3-1*. Recommendation is to upgrade > to version *0.9.3-1* or greater. > > ||id||cvss||desc||link||packageName||packageVersion||severity||status||vecStr|| > |CVE-2016-5397|8.8|The Apache Thrift Go client library exposed the potential > during code generation for command injection due to using an external > formatting tool. Affected Apache Thrift 0.9.3 and older, Fixed in Apache > Thrift > 0.10.0.|https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2016-5397|org.apache.thrift_libthrift|0.9.2|high|.|CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H| > |CVE-2018-1320|7.5|Apache Thrift Java client library versions 0.5.0 through > 0.11.0 can bypass SASL negotiation isComplete validation in the > org.apache.thrift.transport.TSaslTransport class. An assert used to determine > if the SASL handshake had successfully completed could be disabled in > production settings making the validation > incomplete.|https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2018-1320|org.apache.thrift_libthrift|0.9.2|high|.|CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N| > |CVE-2019-0205|7.5|In Apache Thrift all versions up to and including 0.12.0, > a server or client may run into an endless loop when feed with specific input > data. Because the issue had already been partially fixed in version 0.11.0, > depending on the installed version it affects only certain language > bindings.|https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2019-0205|org.apache.thrift_libthrift|0.9.2|high|.|CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H| > > A possible fix strategy is to simply update the JAR to their newest version. > * See > [https://mvnrepository.com/artifact/org.apache.thrift/libthrift/0.9.3-1] -- 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-16740) Remediate Cassandra 3.11.10 JAR dependency vulnerability - ch.qos.logback_logback-core
[ https://issues.apache.org/jira/browse/CASSANDRA-16740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Gomez updated CASSANDRA-16740: - Fix Version/s: 3.11.x > Remediate Cassandra 3.11.10 JAR dependency vulnerability - > ch.qos.logback_logback-core > -- > > Key: CASSANDRA-16740 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16740 > Project: Cassandra > Issue Type: Improvement > Components: Dependencies >Reporter: Daniel Gomez >Priority: Normal > Fix For: 3.11.x > > > A JAR dependency is flagged in Cassandra 3.11.10 as having vulnerabilities > that have been fixed in newer releases. The following is the Cassandra > 3.11.10 source tree for their JAR dependencies: > [https://github.com/apache/cassandra/tree/181a4969290f1c756089b2993a638fe403bc1314/lib] > . > JAR *ch.qos.logback_logback-core* version *1.1.3* has the following > vulnerability and is fixed in version *1.2.0*. Recommendation is to upgrade > to version *1.2.3* or greater. > > ||id||cvss||desc||link||packageName||packageVersion||severity||status||vecStr|| > |CVE-2017-5929|9.8|QOS.ch Logback before 1.2.0 has a serialization > vulnerability affecting the SocketServer and ServerSocketReceiver > components.|https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2017-5929|ch.qos.logback_logback-core|1.1.3|critical|fixed > in 1.2.0|CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H| > A possible fix strategy is to simply update the JAR to their newest version. > * See [https://mvnrepository.com/artifact/ch.qos.logback/logback-core/1.2.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-16737) ALTER ... ADD can increase the number of SSTables being read
[
https://issues.apache.org/jira/browse/CASSANDRA-16737?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-16737:
Description:
With the following SSTables:
{code:java}
CREATE TABLE my_table (pk int, ck int, v1 int, PRIMARY KEY(pk, ck))
INSERT INTO my_table (pk, ck, v1) VALUES (1, 1, 1) USING TIMESTAMP 1000;
--> flush()
INSERT INTO my_table (pk, ck, v1) VALUES (1, 1, 2) USING TIMESTAMP 2000;
--> flush()
INSERT INTO my_table (pk, ck, v1) VALUES (1, 1, 3) USING TIMESTAMP 3000
--> flush()
{code}
the following query:
{code:java}
SELECT pk, ck, v1 FROM my_table WHERE pk = 1 AND ck = 1{code}
will only read the third SSTable.
If we add a column to the table (e.g. {{ALTER TABLE my_table ADD v2 int}}) and
rerun the query, the query will read the 3 SSTables.
The reason for this behavior is due to the fact that C* is trying to read all
the {{fetched}} columns to ensure that it will return a row if at least one of
its column is non null.
In practice for CQL tables, C* does not need to fetch all columns if the row
contains a primary key liveness as it is enough to guaranty that the row
exists. By consequence, even after the addition of the new column C* should
read only the third SSTable.
was:
With the following SSTables:
{code}
CREATE TABLE my_table (pk int, ck int, v1 int, PRIMARY KEY(pk, ck))
INSERT INTO my_table (pk, ck, v1) VALUES (1, 1, 1) USING TIMESTAMP 1000;
--> flush
INSERT INTO my_table (pk, ck, v1) VALUES (1, 1, 2) USING TIMESTAMP 2000;
--> flush()
INSERT INTO my_table (pk, ck, v1) VALUES (1, 1, 3) USING TIMESTAMP 3000
--> flush()
{code}
the following query:
{code}SELECT pk, ck, v1 FROM my_table WHERE pk = 1 AND ck = 1{code}
will only read the third SSTable.
If we add a column to the table (e.g. {{ALTER TABLE my_table ADD v2 int}}) and
rerun the query, the query will read the 3 SSTables.
The reason for this behavior is due to the fact that C* is trying to read all
the {{fetched}} columns to ensure that it will return a row if at least one of
its column is non null.
In practice for CQL tables, C* does not need to fetch all columns if the row
contains a primary key liveness as it is enough to guaranty that the row
exists. By consequence, even after the addition of the new column C* should
read only the third SSTable.
> ALTER ... ADD can increase the number of SSTables being read
>
>
> Key: CASSANDRA-16737
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16737
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Semantics
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 3.11.x, 4.0.x
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> With the following SSTables:
> {code:java}
> CREATE TABLE my_table (pk int, ck int, v1 int, PRIMARY KEY(pk, ck))
> INSERT INTO my_table (pk, ck, v1) VALUES (1, 1, 1) USING TIMESTAMP 1000;
> --> flush()
> INSERT INTO my_table (pk, ck, v1) VALUES (1, 1, 2) USING TIMESTAMP 2000;
> --> flush()
> INSERT INTO my_table (pk, ck, v1) VALUES (1, 1, 3) USING TIMESTAMP 3000
> --> flush()
> {code}
> the following query:
> {code:java}
> SELECT pk, ck, v1 FROM my_table WHERE pk = 1 AND ck = 1{code}
> will only read the third SSTable.
> If we add a column to the table (e.g. {{ALTER TABLE my_table ADD v2 int}})
> and rerun the query, the query will read the 3 SSTables.
> The reason for this behavior is due to the fact that C* is trying to read all
> the {{fetched}} columns to ensure that it will return a row if at least one
> of its column is non null.
> In practice for CQL tables, C* does not need to fetch all columns if the row
> contains a primary key liveness as it is enough to guaranty that the row
> exists. By consequence, even after the addition of the new column C* should
> read only the third SSTable.
--
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-16737) ALTER ... ADD can increase the number of SSTables being read
[
https://issues.apache.org/jira/browse/CASSANDRA-16737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17370787#comment-17370787
]
Ekaterina Dimitrova edited comment on CASSANDRA-16737 at 6/28/21, 6:41 PM:
---
I wanted to help here so I will take a look but [~jlewandowski] -and-
[~adelapena] might also want to look at it as they were reviewing the previous
ticket. Also, I am going on vacation on Wednesday so no need to be pending on
me in case we don't finish working on it async tomorrow.
EDIT: It was [~maedhroz] reviewing the previous one, [~jlewandowski] and
[~adelapena] looked at a different one, my bad.
was (Author: e.dimitrova):
I wanted to help here so I will take a look but [~jlewandowski] and
[~adelapena] might also want to look at it as they were reviewing the previous
ticket. Also, I am going on vacation on Wednesday so no need to be pending on
me in case we don't finish working on it async tomorrow.
> ALTER ... ADD can increase the number of SSTables being read
>
>
> Key: CASSANDRA-16737
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16737
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Semantics
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 3.11.x, 4.0.x
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> With the following SSTables:
> {code}
> CREATE TABLE my_table (pk int, ck int, v1 int, PRIMARY KEY(pk, ck))
> INSERT INTO my_table (pk, ck, v1) VALUES (1, 1, 1) USING TIMESTAMP 1000;
> --> flush
> INSERT INTO my_table (pk, ck, v1) VALUES (1, 1, 2) USING TIMESTAMP 2000;
> --> flush()
> INSERT INTO my_table (pk, ck, v1) VALUES (1, 1, 3) USING TIMESTAMP 3000
> --> flush()
> {code}
> the following query:
> {code}SELECT pk, ck, v1 FROM my_table WHERE pk = 1 AND ck = 1{code}
> will only read the third SSTable.
> If we add a column to the table (e.g. {{ALTER TABLE my_table ADD v2 int}})
> and rerun the query, the query will read the 3 SSTables.
> The reason for this behavior is due to the fact that C* is trying to read all
> the {{fetched}} columns to ensure that it will return a row if at least one
> of its column is non null.
> In practice for CQL tables, C* does not need to fetch all columns if the row
> contains a primary key liveness as it is enough to guaranty that the row
> exists. By consequence, even after the addition of the new column C* should
> read only the third SSTable.
--
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-16737) ALTER ... ADD can increase the number of SSTables being read
[
https://issues.apache.org/jira/browse/CASSANDRA-16737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17370787#comment-17370787
]
Ekaterina Dimitrova commented on CASSANDRA-16737:
-
I wanted to help here so I will take a look but [~jlewandowski] and
[~adelapena] might also want to look at it as they were reviewing the previous
ticket. Also, I am going on vacation on Wednesday so no need to be pending on
me in case we don't finish working on it async tomorrow.
> ALTER ... ADD can increase the number of SSTables being read
>
>
> Key: CASSANDRA-16737
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16737
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Semantics
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 3.11.x, 4.0.x
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> With the following SSTables:
> {code}
> CREATE TABLE my_table (pk int, ck int, v1 int, PRIMARY KEY(pk, ck))
> INSERT INTO my_table (pk, ck, v1) VALUES (1, 1, 1) USING TIMESTAMP 1000;
> --> flush
> INSERT INTO my_table (pk, ck, v1) VALUES (1, 1, 2) USING TIMESTAMP 2000;
> --> flush()
> INSERT INTO my_table (pk, ck, v1) VALUES (1, 1, 3) USING TIMESTAMP 3000
> --> flush()
> {code}
> the following query:
> {code}SELECT pk, ck, v1 FROM my_table WHERE pk = 1 AND ck = 1{code}
> will only read the third SSTable.
> If we add a column to the table (e.g. {{ALTER TABLE my_table ADD v2 int}})
> and rerun the query, the query will read the 3 SSTables.
> The reason for this behavior is due to the fact that C* is trying to read all
> the {{fetched}} columns to ensure that it will return a row if at least one
> of its column is non null.
> In practice for CQL tables, C* does not need to fetch all columns if the row
> contains a primary key liveness as it is enough to guaranty that the row
> exists. By consequence, even after the addition of the new column C* should
> read only the third SSTable.
--
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-16737) ALTER ... ADD can increase the number of SSTables being read
[
https://issues.apache.org/jira/browse/CASSANDRA-16737?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-16737:
Reviewers: Ekaterina Dimitrova, Ekaterina Dimitrova (was: Ekaterina
Dimitrova)
Ekaterina Dimitrova, Ekaterina Dimitrova
Status: Review In Progress (was: Patch Available)
> ALTER ... ADD can increase the number of SSTables being read
>
>
> Key: CASSANDRA-16737
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16737
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Semantics
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 3.11.x, 4.0.x
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> With the following SSTables:
> {code}
> CREATE TABLE my_table (pk int, ck int, v1 int, PRIMARY KEY(pk, ck))
> INSERT INTO my_table (pk, ck, v1) VALUES (1, 1, 1) USING TIMESTAMP 1000;
> --> flush
> INSERT INTO my_table (pk, ck, v1) VALUES (1, 1, 2) USING TIMESTAMP 2000;
> --> flush()
> INSERT INTO my_table (pk, ck, v1) VALUES (1, 1, 3) USING TIMESTAMP 3000
> --> flush()
> {code}
> the following query:
> {code}SELECT pk, ck, v1 FROM my_table WHERE pk = 1 AND ck = 1{code}
> will only read the third SSTable.
> If we add a column to the table (e.g. {{ALTER TABLE my_table ADD v2 int}})
> and rerun the query, the query will read the 3 SSTables.
> The reason for this behavior is due to the fact that C* is trying to read all
> the {{fetched}} columns to ensure that it will return a row if at least one
> of its column is non null.
> In practice for CQL tables, C* does not need to fetch all columns if the row
> contains a primary key liveness as it is enough to guaranty that the row
> exists. By consequence, even after the addition of the new column C* should
> read only the third SSTable.
--
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-16764) Compaction repeatedly fails validateReallocation exception
[
https://issues.apache.org/jira/browse/CASSANDRA-16764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17370776#comment-17370776
]
David Capwell commented on CASSANDRA-16764:
---
this is what I see in the code
{code}
static final int MAX_ARRAY_SIZE = Integer.MAX_VALUE - 8;
...
long validateReallocation(long newSize)
{
int saturatedSize = saturatedArraySizeCast(newSize);
if (saturatedSize <= capacity())
throw new RuntimeException();
return saturatedSize;
}
{code}
this is called by
{code}
long calculateNewSize(long count)
{
long capacity = capacity();
//Both sides of this max expression need to use long arithmetic to
avoid integer overflow
//count and capacity are longs so that ensures it right now.
long newSize = capacity + count;
//For large buffers don't double, increase by 50%
if (capacity > 1024L * 1024L * DOUBLING_THRESHOLD)
newSize = Math.max((capacity * 3L) / 2L, newSize);
else
newSize = Math.max(capacity * 2L, newSize);
return validateReallocation(newSize);
}
{code}
which is called by
{code}
protected void expandToFit(long count)
{
if (count <= 0)
return;
ByteBuffer newBuffer =
ByteBuffer.allocate(checkedArraySizeCast(calculateNewSize(count)));
buffer.flip();
newBuffer.put(buffer);
buffer = newBuffer;
}
{code}
This implies to me that the buffer is MAX_ARRAY_SIZE, at this point we are no
longer able to expand (should return a better error in this case). I say this
as calculateNewSize should not be able to return a value < capacity, so
saturatedArraySizeCast trimming to MAX_ARRAY_SIZE is what should trigger this.
If this is the case then it means the clustering key has a column larger than
{code:java}
Integer.MAX_VALUE - 8
{code}
bytes; what type is used for this table?
[~richardchesse] if you could take a look at a heap dump while this is
happening it would help see what's going on. If you have data ~
Integer.MAX_VALUE then I would expect other issues going on (such as GC issues).
> Compaction repeatedly fails validateReallocation exception
> --
>
> Key: CASSANDRA-16764
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16764
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Compaction/LCS
>Reporter: Richard Hesse
>Priority: Normal
>
> I have a few nodes in my ring that are stuck repeatedly trying to compact the
> same tables over and over again. I've run through the usual trick of rolling
> restarts, and it doesn't seem to help. This exception is logged on the nodes:
> {code}
> ERROR [CompactionExecutor:6] 2021-06-25 20:28:30,001 CassandraDaemon.java:244
> - Exception in thread Thread[CompactionExecutor:6,1,main]
> java.lang.RuntimeException: null
> at
> org.apache.cassandra.io.util.DataOutputBuffer.validateReallocation(DataOutputBuffer.java:134)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.io.util.DataOutputBuffer.calculateNewSize(DataOutputBuffer.java:152)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.io.util.DataOutputBuffer.expandToFit(DataOutputBuffer.java:159)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.io.util.DataOutputBuffer.doFlush(DataOutputBuffer.java:119)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.io.util.BufferedDataOutputStreamPlus.write(BufferedDataOutputStreamPlus.java:132)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.io.util.BufferedDataOutputStreamPlus.write(BufferedDataOutputStreamPlus.java:151)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.utils.ByteBufferUtil.writeWithVIntLength(ByteBufferUtil.java:296)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.db.marshal.AbstractType.writeValue(AbstractType.java:426)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.db.ClusteringPrefix$Serializer.serializeValuesWithoutSize(ClusteringPrefix.java:323)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.db.Clustering$Serializer.serialize(Clustering.java:131)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.db.ClusteringPrefix$Serializer.serialize(ClusteringPrefix.java:266)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.db.Serializers$NewFormatSerializer.serialize(Serializers.java:167)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.db.Serializers$NewFormatSerializer.serialize(Serializers.java:154)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
>
[jira] [Updated] (CASSANDRA-16764) Compaction repeatedly fails validateReallocation exception
[
https://issues.apache.org/jira/browse/CASSANDRA-16764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Capwell updated CASSANDRA-16764:
--
Description:
I have a few nodes in my ring that are stuck repeatedly trying to compact the
same tables over and over again. I've run through the usual trick of rolling
restarts, and it doesn't seem to help. This exception is logged on the nodes:
{code}
ERROR [CompactionExecutor:6] 2021-06-25 20:28:30,001 CassandraDaemon.java:244 -
Exception in thread Thread[CompactionExecutor:6,1,main]
java.lang.RuntimeException: null
at
org.apache.cassandra.io.util.DataOutputBuffer.validateReallocation(DataOutputBuffer.java:134)
~[apache-cassandra-3.11.10.jar:3.11.10]
at
org.apache.cassandra.io.util.DataOutputBuffer.calculateNewSize(DataOutputBuffer.java:152)
~[apache-cassandra-3.11.10.jar:3.11.10]
at
org.apache.cassandra.io.util.DataOutputBuffer.expandToFit(DataOutputBuffer.java:159)
~[apache-cassandra-3.11.10.jar:3.11.10]
at
org.apache.cassandra.io.util.DataOutputBuffer.doFlush(DataOutputBuffer.java:119)
~[apache-cassandra-3.11.10.jar:3.11.10]
at
org.apache.cassandra.io.util.BufferedDataOutputStreamPlus.write(BufferedDataOutputStreamPlus.java:132)
~[apache-cassandra-3.11.10.jar:3.11.10]
at
org.apache.cassandra.io.util.BufferedDataOutputStreamPlus.write(BufferedDataOutputStreamPlus.java:151)
~[apache-cassandra-3.11.10.jar:3.11.10]
at
org.apache.cassandra.utils.ByteBufferUtil.writeWithVIntLength(ByteBufferUtil.java:296)
~[apache-cassandra-3.11.10.jar:3.11.10]
at
org.apache.cassandra.db.marshal.AbstractType.writeValue(AbstractType.java:426)
~[apache-cassandra-3.11.10.jar:3.11.10]
at
org.apache.cassandra.db.ClusteringPrefix$Serializer.serializeValuesWithoutSize(ClusteringPrefix.java:323)
~[apache-cassandra-3.11.10.jar:3.11.10]
at
org.apache.cassandra.db.Clustering$Serializer.serialize(Clustering.java:131)
~[apache-cassandra-3.11.10.jar:3.11.10]
at
org.apache.cassandra.db.ClusteringPrefix$Serializer.serialize(ClusteringPrefix.java:266)
~[apache-cassandra-3.11.10.jar:3.11.10]
at
org.apache.cassandra.db.Serializers$NewFormatSerializer.serialize(Serializers.java:167)
~[apache-cassandra-3.11.10.jar:3.11.10]
at
org.apache.cassandra.db.Serializers$NewFormatSerializer.serialize(Serializers.java:154)
~[apache-cassandra-3.11.10.jar:3.11.10]
at
org.apache.cassandra.io.sstable.IndexInfo$Serializer.serialize(IndexInfo.java:103)
~[apache-cassandra-3.11.10.jar:3.11.10]
at
org.apache.cassandra.io.sstable.IndexInfo$Serializer.serialize(IndexInfo.java:82)
~[apache-cassandra-3.11.10.jar:3.11.10]
at
org.apache.cassandra.db.ColumnIndex.addIndexBlock(ColumnIndex.java:216)
~[apache-cassandra-3.11.10.jar:3.11.10]
at org.apache.cassandra.db.ColumnIndex.add(ColumnIndex.java:264)
~[apache-cassandra-3.11.10.jar:3.11.10]
at
org.apache.cassandra.db.ColumnIndex.buildRowIndex(ColumnIndex.java:111)
~[apache-cassandra-3.11.10.jar:3.11.10]
at
org.apache.cassandra.io.sstable.format.big.BigTableWriter.append(BigTableWriter.java:173)
~[apache-cassandra-3.11.10.jar:3.11.10]
at
org.apache.cassandra.io.sstable.SSTableRewriter.append(SSTableRewriter.java:136)
~[apache-cassandra-3.11.10.jar:3.11.10]
at
org.apache.cassandra.db.compaction.writers.MaxSSTableSizeWriter.realAppend(MaxSSTableSizeWriter.java:98)
~[apache-cassandra-3.11.10.jar:3.11.10]
at
org.apache.cassandra.db.compaction.writers.CompactionAwareWriter.append(CompactionAwareWriter.java:143)
~[apache-cassandra-3.11.10.jar:3.11.10]
at
org.apache.cassandra.db.compaction.CompactionTask.runMayThrow(CompactionTask.java:204)
~[apache-cassandra-3.11.10.jar:3.11.10]
at
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
~[apache-cassandra-3.11.10.jar:3.11.10]
at
org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:85)
~[apache-cassandra-3.11.10.jar:3.11.10]
at
org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:61)
~[apache-cassandra-3.11.10.jar:3.11.10]
at
org.apache.cassandra.db.compaction.CompactionManager$BackgroundCompactionCandidate.run(CompactionManager.java:272)
~[apache-cassandra-3.11.10.jar:3.11.10]
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
~[na:1.8.0_292]
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
~[na:1.8.0_292]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
~[na:1.8.0_292]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
[na:1.8.0_292]
at
org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:84)
[jira] [Commented] (CASSANDRA-16758) Flaky ClientResourceLimitsTest
[
https://issues.apache.org/jira/browse/CASSANDRA-16758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17370737#comment-17370737
]
Caleb Rackliffe commented on CASSANDRA-16758:
-
+1 on the
[16758-4.0.0-review-caleb|https://github.com/adelapena/cassandra/compare/16758-4.0.0-review-caleb]
branch
> Flaky ClientResourceLimitsTest
> --
>
> Key: CASSANDRA-16758
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16758
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0-rc2, 4.0, 4.0.x
>
>
> Flaky
> [ClientResourceLimitsTest|https://ci-cassandra.apache.org/job/Cassandra-4.0.0/35/testReport/junit/org.apache.cassandra.transport/ClientResourceLimitsTest/testBackPressureWhenEndpointLimitExceeded_cdc/]
> {noformat}
> Error Message
> Timed out after waiting 5 seconds for paused connections metric to increment
> due to backpressure expected:<11> but was:<24>
> Stacktrace
> junit.framework.AssertionFailedError: Timed out after waiting 5 seconds for
> paused connections metric to increment due to backpressure expected:<11> but
> was:<24>
> at org.apache.cassandra.Util.spinAssertEquals(Util.java:610)
> at
> org.apache.cassandra.transport.ClientResourceLimitsTest.backPressureTest(ClientResourceLimitsTest.java:218)
> at
> org.apache.cassandra.transport.ClientResourceLimitsTest.testBackPressureWhenEndpointLimitExceeded(ClientResourceLimitsTest.java:179)
> Standard Output
> INFO [main] 2021-06-22 01:56:41,489 YamlConfigurationLoader.java:93 -
> Configuration location:
> file:home/cassandra/cassandra/build/test/cassandra.cdc.yaml
> DEBUG [main] 2021-06-22 01:56:41,491 YamlConfigurationLoader.java:112 -
> Loading settings from
> file:home/cassandra/cassandra/build/test/cassandra.cdc.yaml
> DEBUG [main] 2021-06-22 01:56:41,551 InternalLoggerFactory.java:63 - Using
> SLF4J as the default logging framework
> DEBUG [main] 2021-06-22 01:56:41,565 PlatformDependent0.java:417 - -D
> ...[truncated 765272 chars]...
> org.apache.cassandra.transport.SimpleClient.execute(SimpleClient.java:275)
> at
> org.apache.cassandra.transport.ClientResourceLimitsTest.lambda$testQueryUpdatesConcurrentMetricsUpdate$11(ClientResourceLimitsTest.java:352)
> at java.lang.Thread.run(Thread.java:748)
> DEBUG [Test Cluster-nio-worker-0] 2021-06-22 01:57:08,353 Slf4JLogger.java:81
> - Freed 24 thread-local buffer(s) from thread: Test Cluster-nio-worker-0
> INFO [main] 2021-06-22 01:57:08,364 Server.java:171 - Stop listening for CQL
> clients
> {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-16770) Avoid sending cdc column in serialization header to 3.0 nodes
[ https://issues.apache.org/jira/browse/CASSANDRA-16770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-16770: Test and Documentation Plan: dtest run Status: Patch Available (was: Open) https://github.com/krummas/cassandra/commits/marcuse/16770 dtest run: https://app.circleci.com/pipelines/github/krummas/cassandra?branch=marcuse%2Ffollowup_16735 - note that this is against a different [branch|https://github.com/krummas/cassandra/commit/472780c93a3e17509512a74c119d02c8ce9b1049], apparently our upgrade dtests don't run against the current branch - it clones the 3.11 repo and runs against that I'll also need to figure out why this doesn't affect 4.0 > Avoid sending cdc column in serialization header to 3.0 nodes > - > > Key: CASSANDRA-16770 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16770 > Project: Cassandra > Issue Type: Bug > Components: Cluster/Schema >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > > We try to not send the cdc column to any 3.0 nodes, but it is still there in > the SerializationHeader -- 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-16735) Adding columns via ALTER TABLE can generate corrupt sstables
[ https://issues.apache.org/jira/browse/CASSANDRA-16735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17370711#comment-17370711 ] Marcus Eriksson commented on CASSANDRA-16735: - thanks [~brandon.williams] https://issues.apache.org/jira/browse/CASSANDRA-16770 > Adding columns via ALTER TABLE can generate corrupt sstables > > > Key: CASSANDRA-16735 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16735 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Repair, Local/SSTable >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Fix For: 3.0.25, 3.11.11, 4.0-rc2 > > > This is similar to CASSANDRA-13004 and was caused by CASSANDRA-15899 > Basically the column placeholders introduced in 15899 can get read-repaired > in to the memtable and later flushed to disk and in some cases this can > conflict with the actual column (if the actual column is a collection for > example) and cause CorruptSSTableExceptions. > Fix is probably to just revert 15899, at least until if and when we find a > solution that we can rely on. Will post that + test next week. -- 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-16770) Avoid sending cdc column in serialization header to 3.0 nodes
[ https://issues.apache.org/jira/browse/CASSANDRA-16770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-16770: Bug Category: Parent values: Degradation(12984)Level 1 values: Other Exception(12998) Complexity: Normal Discovered By: DTest Severity: Normal Status: Open (was: Triage Needed) > Avoid sending cdc column in serialization header to 3.0 nodes > - > > Key: CASSANDRA-16770 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16770 > Project: Cassandra > Issue Type: Bug > Components: Cluster/Schema >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > > We try to not send the cdc column to any 3.0 nodes, but it is still there in > the SerializationHeader -- 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-16770) Avoid sending cdc column in serialization header to 3.0 nodes
Marcus Eriksson created CASSANDRA-16770: --- Summary: Avoid sending cdc column in serialization header to 3.0 nodes Key: CASSANDRA-16770 URL: https://issues.apache.org/jira/browse/CASSANDRA-16770 Project: Cassandra Issue Type: Bug Components: Cluster/Schema Reporter: Marcus Eriksson Assignee: Marcus Eriksson We try to not send the cdc column to any 3.0 nodes, but it is still there in the SerializationHeader -- 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-16766) Development docs are not upto to date
[
https://issues.apache.org/jira/browse/CASSANDRA-16766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-16766:
-
Change Category: Quality Assurance
Complexity: Low Hanging Fruit
Status: Open (was: Triage Needed)
> Development docs are not upto to date
> -
>
> Key: CASSANDRA-16766
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16766
> Project: Cassandra
> Issue Type: Improvement
> Components: Documentation/Website
>Reporter: Jogesh Anand
>Priority: Normal
> Labels: low-hanging-fruit
>
> The latest developers guide for unit testing isn't accurate
> [link|https://cassandra.apache.org/doc/latest/development/testing.html]
> For e.g
> {code:java}
> ant test -Dtest.name=
> {code}
> isn't valid. It's now
> {code:java}
> ant testsome -Dtest.name=
> {code}
> Similarly, we also have `ant long-testsome` & `ant burn-testsome` for e.g. I
> would be nice to have these documented as well for developers or users.
> AC:
> * The website accurately represents all testing scenarios present in
> build.xml or otherwise.
--
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-16768) Add user defined SSTables optoin for nodetool scrub
[ https://issues.apache.org/jira/browse/CASSANDRA-16768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-16768: - Change Category: Operability Complexity: Normal Component/s: Tool/sstable Fix Version/s: 3.11.x Status: Open (was: Triage Needed) > Add user defined SSTables optoin for nodetool scrub > --- > > Key: CASSANDRA-16768 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16768 > Project: Cassandra > Issue Type: Improvement > Components: Tool/sstable >Reporter: Scott Carey >Assignee: Scott Carey >Priority: Normal > Fix For: 3.11.x > > > nodetool scrub does not currently have an option to supply a user-defined > list of SSTables in the way that nodetool compact does. > This is a very big operational oversight. For example, if you have a > _single_ SSTable with a single corrupt block, you have to scrub the _entire_ > table in order to recover most of that table's data. On a large table (I > have an LCS table with 1.2TB) this takes _forever_ – to the point that we > decided that the best practice is to delete the entire file and repair the > range that the file contains, rather than scrub and repair only the range of > the bad blocks. > -- 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-16767) Add user defined SSTables option for nodetool garbagecollect
[ https://issues.apache.org/jira/browse/CASSANDRA-16767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-16767: - Change Category: Operability Complexity: Normal Component/s: Tool/sstable Fix Version/s: 3.11.x Status: Open (was: Triage Needed) > Add user defined SSTables option for nodetool garbagecollect > > > Key: CASSANDRA-16767 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16767 > Project: Cassandra > Issue Type: Improvement > Components: Tool/sstable >Reporter: Scott Carey >Assignee: Scott Carey >Priority: Normal > Fix For: 3.11.x > > > nodetool garbagecollect does not yet have an option to supply a user defined > list of SSTables to process. > This is unfortunate, because there are many cases where an operator would > know which subset of tables are in need of a garbagecollect. Perhaps with > STCS, one would choose to garbagecollect only the largest file. > With a large LCS table, it is typical that the highest levels have the most > overwritten data, and it may take a very long time to run a full > garbagecollect or full compaction, but a relatively short time to process a > smaller subset of SSTables. > -- 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-16769) Add an option to nodetool garbagecollect that collects only a fraction of the data
[ https://issues.apache.org/jira/browse/CASSANDRA-16769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-16769: - Change Category: Performance Complexity: Normal Component/s: Tool/sstable Fix Version/s: 3.11.x Status: Open (was: Triage Needed) > Add an option to nodetool garbagecollect that collects only a fraction of the > data > -- > > Key: CASSANDRA-16769 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16769 > Project: Cassandra > Issue Type: Improvement > Components: Tool/sstable >Reporter: Scott Carey >Assignee: Scott Carey >Priority: Normal > Fix For: 3.11.x > > > nodetool garbagecollect can currently only run across an entire table. > For a very large table, with many use cases, the most likely tables to be > full of 'garbage' are the oldest tables. With both LCS and STCS, the tables > with the lowest generation number are, under normal operation, going to have > the majority of data that is masked by a tombstone or overwritten. > In order to make 'nodetool garbagecollect' more useful for such large tables, > I propose that we add an option `--oldest-fraction` that takes a floating > point value between 0.00 and 1.00, and only runs 'garbagecollect' over the > oldest SSTables that cover at least that fraction of data. > This would mean, for insatnce, that if you ran this with `--oldest-fraction > 0.1` every week, that no table would be older than 10 weeks old, and there > would exist no data that has been overwritten, TTL'd, or deleted that was > originally written more than 10 weeks ago. > In my use case, the oldest LCS table is about 20 months old if the table > operates in steady-state on Cassandra 3.11.x, but only 5% of the data in > tables that age has not been overwritten. This breaks some of the performance > promise of LCS – if your last level is 50% filled with overwritten data, then > your chance of finding data only in that level is significantly less than > advertised. > 'nodetool compact' is extremely expensive, and not conducive to any sort of > incremental operation currently. But nodetool garbagecollect run on a > fraction of the oldest data would be. -- 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-16404) Provide a nodetool way of invalidating auth caches
[ https://issues.apache.org/jira/browse/CASSANDRA-16404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-16404: --- Reviewers: Benjamin Lerer > Provide a nodetool way of invalidating auth caches > -- > > Key: CASSANDRA-16404 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16404 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Authorization >Reporter: Sumanth Pasupuleti >Assignee: Alexey Zotov >Priority: Normal > Fix For: 4.x > > Time Spent: 0.5h > Remaining Estimate: 0h > > We currently have nodetool commands to invalidate certain caches like > KeyCache, RowCache and CounterCache. > Being able to invalidate auth caches as well can come in handy in situations > where, critical backend auth changes may need to be in effect right away for > all the connections, especially in configurations where cache validity is > chosen to be for a longer duration. An example can be that an authenticated > user "User1" is no longer authorized to access a table resource "table1" and > it is vital that this change is reflected right away, without having to wait > for cache expiry/refresh to trigger. -- 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-16737) ALTER ... ADD can increase the number of SSTables being read
[
https://issues.apache.org/jira/browse/CASSANDRA-16737?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-16737:
---
Test and Documentation Plan: The patch add several tests and relies on the
tests previously added in CASSANDRA-16671
Status: Patch Available (was: In Progress)
> ALTER ... ADD can increase the number of SSTables being read
>
>
> Key: CASSANDRA-16737
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16737
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Semantics
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 3.11.x, 4.0.x
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> With the following SSTables:
> {code}
> CREATE TABLE my_table (pk int, ck int, v1 int, PRIMARY KEY(pk, ck))
> INSERT INTO my_table (pk, ck, v1) VALUES (1, 1, 1) USING TIMESTAMP 1000;
> --> flush
> INSERT INTO my_table (pk, ck, v1) VALUES (1, 1, 2) USING TIMESTAMP 2000;
> --> flush()
> INSERT INTO my_table (pk, ck, v1) VALUES (1, 1, 3) USING TIMESTAMP 3000
> --> flush()
> {code}
> the following query:
> {code}SELECT pk, ck, v1 FROM my_table WHERE pk = 1 AND ck = 1{code}
> will only read the third SSTable.
> If we add a column to the table (e.g. {{ALTER TABLE my_table ADD v2 int}})
> and rerun the query, the query will read the 3 SSTables.
> The reason for this behavior is due to the fact that C* is trying to read all
> the {{fetched}} columns to ensure that it will return a row if at least one
> of its column is non null.
> In practice for CQL tables, C* does not need to fetch all columns if the row
> contains a primary key liveness as it is enough to guaranty that the row
> exists. By consequence, even after the addition of the new column C* should
> read only the third SSTable.
--
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-16737) ALTER ... ADD can increase the number of SSTables being read
[
https://issues.apache.org/jira/browse/CASSANDRA-16737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17370476#comment-17370476
]
Benjamin Lerer commented on CASSANDRA-16737:
|| Branche || CI ||
|[3.11|https://github.com/apache/cassandra/pull/1083] |
[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/172/workflows/73c2be44-4d53-4b4e-b073-98d461d318de]
|
|[4.0|https://github.com/apache/cassandra/pull/1084] |
[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/174/workflows/4305a452-286c-47c3-be7b-16a3556900d4],
[j11|https://app.circleci.com/pipelines/github/blerer/cassandra/174/workflows/9fd2044e-da79-40c5-be3f-bdbd84a9e2c7]
|
The patches rely on the fact that if a row has some primary key liveness then
the row is guaranty to exist even if some of the non-primary key columns are
deleted later on by deletions coming from other nodes. By consequence, when
reading SSTables in a time ordered way once C* find a row with a primary key
liveness and all the queried columns it can safely stop reading extra SSTables.
That approach will not work for {{COMPACT}} tables has they do not have a
primary key liveness information. Due to that for COMPACT tables C* will still
need to retrieve all the fetched columns to ensure that it can returns the
correct results.
That approach will also not work for scenarios where the row has been inserted
through only {{UPDATE}} statements as those statements do not set the primary
key liveness information.
> ALTER ... ADD can increase the number of SSTables being read
>
>
> Key: CASSANDRA-16737
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16737
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Semantics
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 3.11.x, 4.0.x
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> With the following SSTables:
> {code}
> CREATE TABLE my_table (pk int, ck int, v1 int, PRIMARY KEY(pk, ck))
> INSERT INTO my_table (pk, ck, v1) VALUES (1, 1, 1) USING TIMESTAMP 1000;
> --> flush
> INSERT INTO my_table (pk, ck, v1) VALUES (1, 1, 2) USING TIMESTAMP 2000;
> --> flush()
> INSERT INTO my_table (pk, ck, v1) VALUES (1, 1, 3) USING TIMESTAMP 3000
> --> flush()
> {code}
> the following query:
> {code}SELECT pk, ck, v1 FROM my_table WHERE pk = 1 AND ck = 1{code}
> will only read the third SSTable.
> If we add a column to the table (e.g. {{ALTER TABLE my_table ADD v2 int}})
> and rerun the query, the query will read the 3 SSTables.
> The reason for this behavior is due to the fact that C* is trying to read all
> the {{fetched}} columns to ensure that it will return a row if at least one
> of its column is non null.
> In practice for CQL tables, C* does not need to fetch all columns if the row
> contains a primary key liveness as it is enough to guaranty that the row
> exists. By consequence, even after the addition of the new column C* should
> read only the third SSTable.
--
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-16758) Flaky ClientResourceLimitsTest
[
https://issues.apache.org/jira/browse/CASSANDRA-16758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17370474#comment-17370474
]
Berenguer Blasi edited comment on CASSANDRA-16758 at 6/28/21, 7:52 AM:
---
I agree with you both filtering out driver noise is a superior solution. Also
if [~adelapena] managed to get 5K runs for the other failure lurking here then
I say +1 to everything after reviewing it and let [~adelapena] commit it.
There's no point in me duplicating the effort of building the same PR etc.
was (Author: bereng):
I agree with you both filtering out driver noise is a superior solution. Also
if [~adelapena] managed to get 5K runs for the other failure lurking here then
I say +1 to everything and let [~adelapena] commit it. There's no point in me
duplicating the effort of building the same PR etc.
> Flaky ClientResourceLimitsTest
> --
>
> Key: CASSANDRA-16758
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16758
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0-rc2, 4.0, 4.0.x
>
>
> Flaky
> [ClientResourceLimitsTest|https://ci-cassandra.apache.org/job/Cassandra-4.0.0/35/testReport/junit/org.apache.cassandra.transport/ClientResourceLimitsTest/testBackPressureWhenEndpointLimitExceeded_cdc/]
> {noformat}
> Error Message
> Timed out after waiting 5 seconds for paused connections metric to increment
> due to backpressure expected:<11> but was:<24>
> Stacktrace
> junit.framework.AssertionFailedError: Timed out after waiting 5 seconds for
> paused connections metric to increment due to backpressure expected:<11> but
> was:<24>
> at org.apache.cassandra.Util.spinAssertEquals(Util.java:610)
> at
> org.apache.cassandra.transport.ClientResourceLimitsTest.backPressureTest(ClientResourceLimitsTest.java:218)
> at
> org.apache.cassandra.transport.ClientResourceLimitsTest.testBackPressureWhenEndpointLimitExceeded(ClientResourceLimitsTest.java:179)
> Standard Output
> INFO [main] 2021-06-22 01:56:41,489 YamlConfigurationLoader.java:93 -
> Configuration location:
> file:home/cassandra/cassandra/build/test/cassandra.cdc.yaml
> DEBUG [main] 2021-06-22 01:56:41,491 YamlConfigurationLoader.java:112 -
> Loading settings from
> file:home/cassandra/cassandra/build/test/cassandra.cdc.yaml
> DEBUG [main] 2021-06-22 01:56:41,551 InternalLoggerFactory.java:63 - Using
> SLF4J as the default logging framework
> DEBUG [main] 2021-06-22 01:56:41,565 PlatformDependent0.java:417 - -D
> ...[truncated 765272 chars]...
> org.apache.cassandra.transport.SimpleClient.execute(SimpleClient.java:275)
> at
> org.apache.cassandra.transport.ClientResourceLimitsTest.lambda$testQueryUpdatesConcurrentMetricsUpdate$11(ClientResourceLimitsTest.java:352)
> at java.lang.Thread.run(Thread.java:748)
> DEBUG [Test Cluster-nio-worker-0] 2021-06-22 01:57:08,353 Slf4JLogger.java:81
> - Freed 24 thread-local buffer(s) from thread: Test Cluster-nio-worker-0
> INFO [main] 2021-06-22 01:57:08,364 Server.java:171 - Stop listening for CQL
> clients
> {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-16758) Flaky ClientResourceLimitsTest
[
https://issues.apache.org/jira/browse/CASSANDRA-16758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Berenguer Blasi updated CASSANDRA-16758:
Authors: Andres de la Peña, Berenguer Blasi, Caleb Rackliffe (was:
Berenguer Blasi)
> Flaky ClientResourceLimitsTest
> --
>
> Key: CASSANDRA-16758
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16758
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0-rc2, 4.0, 4.0.x
>
>
> Flaky
> [ClientResourceLimitsTest|https://ci-cassandra.apache.org/job/Cassandra-4.0.0/35/testReport/junit/org.apache.cassandra.transport/ClientResourceLimitsTest/testBackPressureWhenEndpointLimitExceeded_cdc/]
> {noformat}
> Error Message
> Timed out after waiting 5 seconds for paused connections metric to increment
> due to backpressure expected:<11> but was:<24>
> Stacktrace
> junit.framework.AssertionFailedError: Timed out after waiting 5 seconds for
> paused connections metric to increment due to backpressure expected:<11> but
> was:<24>
> at org.apache.cassandra.Util.spinAssertEquals(Util.java:610)
> at
> org.apache.cassandra.transport.ClientResourceLimitsTest.backPressureTest(ClientResourceLimitsTest.java:218)
> at
> org.apache.cassandra.transport.ClientResourceLimitsTest.testBackPressureWhenEndpointLimitExceeded(ClientResourceLimitsTest.java:179)
> Standard Output
> INFO [main] 2021-06-22 01:56:41,489 YamlConfigurationLoader.java:93 -
> Configuration location:
> file:home/cassandra/cassandra/build/test/cassandra.cdc.yaml
> DEBUG [main] 2021-06-22 01:56:41,491 YamlConfigurationLoader.java:112 -
> Loading settings from
> file:home/cassandra/cassandra/build/test/cassandra.cdc.yaml
> DEBUG [main] 2021-06-22 01:56:41,551 InternalLoggerFactory.java:63 - Using
> SLF4J as the default logging framework
> DEBUG [main] 2021-06-22 01:56:41,565 PlatformDependent0.java:417 - -D
> ...[truncated 765272 chars]...
> org.apache.cassandra.transport.SimpleClient.execute(SimpleClient.java:275)
> at
> org.apache.cassandra.transport.ClientResourceLimitsTest.lambda$testQueryUpdatesConcurrentMetricsUpdate$11(ClientResourceLimitsTest.java:352)
> at java.lang.Thread.run(Thread.java:748)
> DEBUG [Test Cluster-nio-worker-0] 2021-06-22 01:57:08,353 Slf4JLogger.java:81
> - Freed 24 thread-local buffer(s) from thread: Test Cluster-nio-worker-0
> INFO [main] 2021-06-22 01:57:08,364 Server.java:171 - Stop listening for CQL
> clients
> {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-16758) Flaky ClientResourceLimitsTest
[
https://issues.apache.org/jira/browse/CASSANDRA-16758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Berenguer Blasi updated CASSANDRA-16758:
Reviewers: Andres de la Peña, Berenguer Blasi, Caleb Rackliffe (was:
Andres de la Peña, Caleb Rackliffe)
> Flaky ClientResourceLimitsTest
> --
>
> Key: CASSANDRA-16758
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16758
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0-rc2, 4.0, 4.0.x
>
>
> Flaky
> [ClientResourceLimitsTest|https://ci-cassandra.apache.org/job/Cassandra-4.0.0/35/testReport/junit/org.apache.cassandra.transport/ClientResourceLimitsTest/testBackPressureWhenEndpointLimitExceeded_cdc/]
> {noformat}
> Error Message
> Timed out after waiting 5 seconds for paused connections metric to increment
> due to backpressure expected:<11> but was:<24>
> Stacktrace
> junit.framework.AssertionFailedError: Timed out after waiting 5 seconds for
> paused connections metric to increment due to backpressure expected:<11> but
> was:<24>
> at org.apache.cassandra.Util.spinAssertEquals(Util.java:610)
> at
> org.apache.cassandra.transport.ClientResourceLimitsTest.backPressureTest(ClientResourceLimitsTest.java:218)
> at
> org.apache.cassandra.transport.ClientResourceLimitsTest.testBackPressureWhenEndpointLimitExceeded(ClientResourceLimitsTest.java:179)
> Standard Output
> INFO [main] 2021-06-22 01:56:41,489 YamlConfigurationLoader.java:93 -
> Configuration location:
> file:home/cassandra/cassandra/build/test/cassandra.cdc.yaml
> DEBUG [main] 2021-06-22 01:56:41,491 YamlConfigurationLoader.java:112 -
> Loading settings from
> file:home/cassandra/cassandra/build/test/cassandra.cdc.yaml
> DEBUG [main] 2021-06-22 01:56:41,551 InternalLoggerFactory.java:63 - Using
> SLF4J as the default logging framework
> DEBUG [main] 2021-06-22 01:56:41,565 PlatformDependent0.java:417 - -D
> ...[truncated 765272 chars]...
> org.apache.cassandra.transport.SimpleClient.execute(SimpleClient.java:275)
> at
> org.apache.cassandra.transport.ClientResourceLimitsTest.lambda$testQueryUpdatesConcurrentMetricsUpdate$11(ClientResourceLimitsTest.java:352)
> at java.lang.Thread.run(Thread.java:748)
> DEBUG [Test Cluster-nio-worker-0] 2021-06-22 01:57:08,353 Slf4JLogger.java:81
> - Freed 24 thread-local buffer(s) from thread: Test Cluster-nio-worker-0
> INFO [main] 2021-06-22 01:57:08,364 Server.java:171 - Stop listening for CQL
> clients
> {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-16758) Flaky ClientResourceLimitsTest
[
https://issues.apache.org/jira/browse/CASSANDRA-16758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Berenguer Blasi updated CASSANDRA-16758:
Status: Ready to Commit (was: Review In Progress)
> Flaky ClientResourceLimitsTest
> --
>
> Key: CASSANDRA-16758
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16758
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0-rc2, 4.0, 4.0.x
>
>
> Flaky
> [ClientResourceLimitsTest|https://ci-cassandra.apache.org/job/Cassandra-4.0.0/35/testReport/junit/org.apache.cassandra.transport/ClientResourceLimitsTest/testBackPressureWhenEndpointLimitExceeded_cdc/]
> {noformat}
> Error Message
> Timed out after waiting 5 seconds for paused connections metric to increment
> due to backpressure expected:<11> but was:<24>
> Stacktrace
> junit.framework.AssertionFailedError: Timed out after waiting 5 seconds for
> paused connections metric to increment due to backpressure expected:<11> but
> was:<24>
> at org.apache.cassandra.Util.spinAssertEquals(Util.java:610)
> at
> org.apache.cassandra.transport.ClientResourceLimitsTest.backPressureTest(ClientResourceLimitsTest.java:218)
> at
> org.apache.cassandra.transport.ClientResourceLimitsTest.testBackPressureWhenEndpointLimitExceeded(ClientResourceLimitsTest.java:179)
> Standard Output
> INFO [main] 2021-06-22 01:56:41,489 YamlConfigurationLoader.java:93 -
> Configuration location:
> file:home/cassandra/cassandra/build/test/cassandra.cdc.yaml
> DEBUG [main] 2021-06-22 01:56:41,491 YamlConfigurationLoader.java:112 -
> Loading settings from
> file:home/cassandra/cassandra/build/test/cassandra.cdc.yaml
> DEBUG [main] 2021-06-22 01:56:41,551 InternalLoggerFactory.java:63 - Using
> SLF4J as the default logging framework
> DEBUG [main] 2021-06-22 01:56:41,565 PlatformDependent0.java:417 - -D
> ...[truncated 765272 chars]...
> org.apache.cassandra.transport.SimpleClient.execute(SimpleClient.java:275)
> at
> org.apache.cassandra.transport.ClientResourceLimitsTest.lambda$testQueryUpdatesConcurrentMetricsUpdate$11(ClientResourceLimitsTest.java:352)
> at java.lang.Thread.run(Thread.java:748)
> DEBUG [Test Cluster-nio-worker-0] 2021-06-22 01:57:08,353 Slf4JLogger.java:81
> - Freed 24 thread-local buffer(s) from thread: Test Cluster-nio-worker-0
> INFO [main] 2021-06-22 01:57:08,364 Server.java:171 - Stop listening for CQL
> clients
> {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-16758) Flaky ClientResourceLimitsTest
[
https://issues.apache.org/jira/browse/CASSANDRA-16758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17370474#comment-17370474
]
Berenguer Blasi commented on CASSANDRA-16758:
-
I agree with you both filtering out driver noise is a superior solution. Also
if [~adelapena] managed to get 5K runs for the other failure lurking here then
I say +1 to everything and let [~adelapena] commit it. There's no point in me
duplicating the effort of building the same PR etc.
> Flaky ClientResourceLimitsTest
> --
>
> Key: CASSANDRA-16758
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16758
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0-rc2, 4.0, 4.0.x
>
>
> Flaky
> [ClientResourceLimitsTest|https://ci-cassandra.apache.org/job/Cassandra-4.0.0/35/testReport/junit/org.apache.cassandra.transport/ClientResourceLimitsTest/testBackPressureWhenEndpointLimitExceeded_cdc/]
> {noformat}
> Error Message
> Timed out after waiting 5 seconds for paused connections metric to increment
> due to backpressure expected:<11> but was:<24>
> Stacktrace
> junit.framework.AssertionFailedError: Timed out after waiting 5 seconds for
> paused connections metric to increment due to backpressure expected:<11> but
> was:<24>
> at org.apache.cassandra.Util.spinAssertEquals(Util.java:610)
> at
> org.apache.cassandra.transport.ClientResourceLimitsTest.backPressureTest(ClientResourceLimitsTest.java:218)
> at
> org.apache.cassandra.transport.ClientResourceLimitsTest.testBackPressureWhenEndpointLimitExceeded(ClientResourceLimitsTest.java:179)
> Standard Output
> INFO [main] 2021-06-22 01:56:41,489 YamlConfigurationLoader.java:93 -
> Configuration location:
> file:home/cassandra/cassandra/build/test/cassandra.cdc.yaml
> DEBUG [main] 2021-06-22 01:56:41,491 YamlConfigurationLoader.java:112 -
> Loading settings from
> file:home/cassandra/cassandra/build/test/cassandra.cdc.yaml
> DEBUG [main] 2021-06-22 01:56:41,551 InternalLoggerFactory.java:63 - Using
> SLF4J as the default logging framework
> DEBUG [main] 2021-06-22 01:56:41,565 PlatformDependent0.java:417 - -D
> ...[truncated 765272 chars]...
> org.apache.cassandra.transport.SimpleClient.execute(SimpleClient.java:275)
> at
> org.apache.cassandra.transport.ClientResourceLimitsTest.lambda$testQueryUpdatesConcurrentMetricsUpdate$11(ClientResourceLimitsTest.java:352)
> at java.lang.Thread.run(Thread.java:748)
> DEBUG [Test Cluster-nio-worker-0] 2021-06-22 01:57:08,353 Slf4JLogger.java:81
> - Freed 24 thread-local buffer(s) from thread: Test Cluster-nio-worker-0
> INFO [main] 2021-06-22 01:57:08,364 Server.java:171 - Stop listening for CQL
> clients
> {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
