av9ash/GitBugs huggingface dataset:
Bug: Avoid memoizing the wrong min cluster version during upgrades
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 23/Jun/21 15:19
Resolved: 27/Jun/21 05:17

CASSANDRA-16525 avoids trying to calculate the cluster min version if gossiper is not enabled.

This makes us memoize the wrong version for up to a minute causing us to send 4.0-messages to 3.0 nodes, for example in [ColumnFilter|https://github.com/apache/cassandra/blob/05beda90a9206db165a3997a736ecb06f8dc695e/src/java/org/apache/cassandra/db/filter/ColumnFilter.java#L210]

This was discovered by python upgrade dtests, [here|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/993/workflows/2afef6f0-1356-41f6-93dc-5385ac19dca1/jobs/5977/tests#failed-test-0] after reverting CASSANDRA-15899 in CASSANDRA-16735
Bug: Flaky CassandraIndexTest
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 14/Apr/21 08:26
Resolved: 22/Apr/21 06:06

See failure [here|https://ci-cassandra.apache.org/job/Cassandra-trunk/436/testReport/junit/org.apache.cassandra.index.internal/CassandraIndexTest/indexCorrectlyMarkedAsBuildAndRemoved_cdc/]


{noformat}
Error Message

expected:<1> but was:<0>

Stacktrace

junit.framework.AssertionFailedError: expected:<1> but was:<0>
	at org.apache.cassandra.index.internal.CassandraIndexTest.indexCorrectlyMarkedAsBuildAndRemoved(CassandraIndexTest.java:588)
{noformat}
Bug: Remediate Cassandra 3.11.10 JAR dependency vulnerabilities 
Status: Resolved
Priority: Normal
Resolution: Invalid
Created: 11/Jun/21 17:00
Resolved: 11/Jun/21 18:51

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]
Bug: Fix test testIsrepairedArg - org.apache.cassandra.tools.SSTableRepairedAtSetterTest
Status: Resolved
Priority: Normal
Resolution: Duplicate
Created: 07/Apr/21 02:36
Resolved: 20/Apr/21 16:36

https://app.circleci.com/pipelines/github/dcapwell/cassandra/874/workflows/0b0a1e36-107a-43c7-815f-bf8e61d3028d/jobs/5227/tests

{code}
junit.framework.AssertionFailedError: [org.apache.cassandra.tools.SSTableRepairedAtSetter,
    --really-set,
    --is-repaired,
    /tmp/cassandra/build/test/cassandra/data/legacy_sstables/legacy_ma_simple/ma-1-big-Data.db]
exited with code -1
stderr:

java.lang.RuntimeException: java.nio.file.NoSuchFileException: /tmp/cassandra/build/test/cassandra/data/legacy_sstables/legacy_ma_simple/ma-1-big-Data.db
	at org.apache.cassandra.tools.ToolRunner.runClassAsTool(ToolRunner.java:102)
	at org.apache.cassandra.tools.ToolRunner$2.get(ToolRunner.java:249)
	at org.apache.cassandra.tools.ToolRunner$2.get(ToolRunner.java:245)
	at org.apache.cassandra.tools.ToolRunner.invokeSupplier(ToolRunner.java:305)
	at org.apache.cassandra.tools.ToolRunner.invokeClass(ToolRunner.java:253)
	at org.apache.cassandra.tools.ToolRunner.invokeClass(ToolRunner.java:235)
	at org.apache.cassandra.tools.SSTableRepairedAtSetterTest.testIsrepairedArg(SSTableRepairedAtSetterTest.java:81)
Caused by: java.nio.file.NoSuchFileException: /tmp/cassandra/build/test/cassandra/data/legacy_sstables/legacy_ma_simple/ma-1-big-Data.db
	at sun.nio.fs.UnixException.translateToIOException(UnixException.java:86)
	at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
	at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
	at sun.nio.fs.UnixFileAttributeViews$Basic.readAttributes(UnixFileAttributeViews.java:55)
	at sun.nio.fs.UnixFileSystemProvider.readAttributes(UnixFileSystemProvider.java:144)
	at sun.nio.fs.LinuxFileSystemProvider.readAttributes(LinuxFileSystemProvider.java:99)
	at java.nio.file.Files.readAttributes(Files.java:1737)
	at java.nio.file.Files.getLastModifiedTime(Files.java:2266)
	at org.apache.cassandra.tools.SSTableRepairedAtSetter.main(SSTableRepairedAtSetter.java:90)
	at org.apache.cassandra.tools.ToolRunner.runClassAsTool(ToolRunner.java:82)

stdout:

	at org.apache.cassandra.tools.ToolRunner$ToolResult.assertExitCode(ToolRunner.java:408)
	at org.apache.cassandra.tools.ToolRunner$ToolResult.assertOnExitCode(ToolRunner.java:402)
	at org.apache.cassandra.tools.ToolRunner$ToolResult.assertOnCleanExit(ToolRunner.java:450)
	at org.apache.cassandra.tools.SSTableRepairedAtSetterTest.testIsrepairedArg(SSTableRepairedAtSetterTest.java:85)
{code}
Bug: Fix flaky org.apache.cassandra.service.ActiveRepairServiceTest
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 12/Apr/21 13:19
Resolved: 22/Apr/21 13:10

https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/612/tests

{noformat}
junit.framework.AssertionFailedError: expected:<2> but was:<1>
	at org.apache.cassandra.service.ActiveRepairServiceTest.testQueueWhenPoolFullStrategy(ActiveRepairServiceTest.java:435)


Standard Output
INFO  [main] 2021-04-10 17:37:25,869 YamlConfigurationLoader.java:93 - Configuration location: file:////home/cassandra/cassandra/build/test/cassandra.compressed.yaml
DEBUG [main] 2021-04-10 17:37:25,872 YamlConfigurationLoader.java:112 - Loading settings from file:////home/cassandra/cassandra/build/test/cassandra.compressed.yaml
DEBUG [main] 2021-04-10 17:37:25,950 InternalLoggerFactory.java:63 - Using SLF4J as the default logging framework
DEBUG [main] 2021-04-10 17:37:25,968 PlatformDependent0
...[truncated 88170 chars]...
build/test/cassandra/data:62/system/local-7ad54392bcdd35a684174e047860b377/na_txn_flush_6c2ddd10-9a23-11eb-9207-35733cfe3fbb.log 
DEBUG [MemtableFlushWriter:1] 2021-04-10 17:37:29,454 ColumnFamilyStore.java:1197 - Flushed to [BigTableReader(path='/home/cassandra/cassandra/build/test/cassandra/data:62/system/local-7ad54392bcdd35a684174e047860b377/na-15-big-Data.db')] (1 sstables, 4.943KiB), biggest 4.943KiB, smallest 4.943KiB
DEBUG [main] 2021-04-10 17:37:29,456 StorageService.java:1617 - NORMAL
{noformat}
Bug: Flaky DirectoriesTest.testSecondaryIndexDirectories
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 23/Apr/21 09:59
Resolved: 06/May/21 08:06

See failure [here|https://ci-cassandra.apache.org/job/Cassandra-trunk/462/testReport/junit/org.apache.cassandra.db/DirectoriesTest/testSecondaryIndexDirectories_cdc/]

{noformat}
Error Message

expected:<1619094213489> but was:<1619094213485>

Stacktrace

junit.framework.AssertionFailedError: expected:<1619094213489> but was:<1619094213485>
	at org.apache.cassandra.db.DirectoriesTest.testSecondaryIndexDirectories(DirectoriesTest.java:216)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
{noformat}
Bug: Flaky StorageServiceServerTest
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 07/Apr/21 07:47
Resolved: 13/Apr/21 09:34

Failing on [ci-cass|https://ci-cassandra.apache.org/job/Cassandra-trunk/411/testReport/junit/org.apache.cassandra.service/StorageServiceServerTest/testLocalPrimaryRangeForEndpointWithNetworkTopologyStrategy_compression/]
Bug: Flaky TestTransientReplicationRing.test_move_backwards_and_cleanup
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 30/Apr/21 07:29
Resolved: 17/May/21 09:05

Failure [here|https://ci-cassandra.apache.org/job/Cassandra-trunk/472/testReport/junit/dtest-novnode.transient_replication_ring_test/TestTransientReplicationRing/test_move_backwards_and_cleanup/]


{noformat}
Error Message

ccmlib.node.TimeoutError: 27 Apr 2021 00:01:00 [node4] after 90.11/90 seconds Missing: ['Starting listening for CQL clients'] not found in system.log: Tail: INFO  [main] 2021-04-26 23:59:22,590 YamlConfigura

Stacktrace

self = <transient_replication_ring_test.TestTransientReplicationRing object at 0x7f66c51ebd90>

    @flaky(max_runs=1)
    @pytest.mark.no_vnodes
    def test_move_backwards_and_cleanup(self):
        """Test moving a node backwards without moving past a neighbor token"""
        move_token = '00005'
        expected_after_move = [gen_expected(range(0, 6), range(31, 40)),
                               gen_expected(range(0, 21, 2)),
                               gen_expected(range(1, 6, 2), range(6, 31)),
                               gen_expected(range(7, 20, 2), range(21, 40))]
        expected_after_repair = [gen_expected(range(0, 6), range(31, 40)),
                                 gen_expected(range(0, 21)),
                                 gen_expected(range(6, 31)),
                                 gen_expected(range(21, 40))]
>       self.move_test(move_token, expected_after_move, expected_after_repair)

transient_replication_ring_test.py:333: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
transient_replication_ring_test.py:235: in move_test
    node4.start(wait_for_binary_proto=True)
transient_replication_ring_test.py:50: in new_start
    return old_start(*args, **kwargs)
../venv/src/ccm/ccmlib/node.py:901: in start
    self.wait_for_binary_interface(from_mark=self.mark)
../venv/src/ccm/ccmlib/node.py:687: in wait_for_binary_interface
    self.watch_log_for("Starting listening for CQL clients", **kwargs)
../venv/src/ccm/ccmlib/node.py:588: in watch_log_for
    TimeoutError.raise_if_passed(start=start, timeout=timeout, node=self.name,
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

start = 1619481570.0236456, timeout = 90
msg = "Missing: ['Starting listening for CQL clients'] not found in system.log:\nTail: INFO  [main] 2021-04-26 23:59:22,590 YamlConfigura"
node = 'node4'

    @staticmethod
    def raise_if_passed(start, timeout, msg, node=None):
        if start + timeout < time.time():
>           raise TimeoutError.create(start, timeout, msg, node)
E           ccmlib.node.TimeoutError: 27 Apr 2021 00:01:00 [node4] after 90.11/90 seconds Missing: ['Starting listening for CQL clients'] not found in system.log:
E           Tail: INFO  [main] 2021-04-26 23:59:22,590 YamlConfigura

../venv/src/ccm/ccmlib/node.py:56: TimeoutError
{noformat}
Bug: Flaky LeaveAndBootstrapTest
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 24/May/21 06:26
Resolved: 15/Jun/21 19:55

Failing in a circle run [here|https://app.circleci.com/pipelines/github/bereng/cassandra/309/workflows/a645b956-dcd7-431e-b109-7857af3c523f/jobs/2937]

{noformat}
Testcase: testStateJumpToNormal(org.apache.cassandra.service.LeaveAndBootstrapTest):	Caused an ERROR
[junit-timeout] null
[junit-timeout] java.lang.NullPointerException
[junit-timeout] 	at org.apache.cassandra.service.StorageService.updatePeerInfo(StorageService.java:2418)
[junit-timeout] 	at org.apache.cassandra.service.StorageService.handleStateNormal(StorageService.java:2756)
[junit-timeout] 	at org.apache.cassandra.service.StorageService.onChange(StorageService.java:2299)
[junit-timeout] 	at org.apache.cassandra.Util.createInitialRing(Util.java:236)
[junit-timeout] 	at org.apache.cassandra.service.LeaveAndBootstrapTest.testStateJumpToNormal(LeaveAndBootstrapTest.java:550)
{noformat}
Bug: Fix flaky StreamingMetricsTest.testMetricsWithRebuildAndStreamingToTwoNodes
Status: Resolved
Priority: Normal
Resolution: Duplicate
Created: 30/Apr/21 14:37
Resolved: 30/Apr/21 14:41

{noformat}
junit.framework.AssertionFailedError: [The amount of files received by node2 from node3 is not the expected one. [expected: 5, actual: 6]] expected:<[5]L> but was:<[6]L>
	at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
	at org.apache.cassandra.distributed.test.metrics.StreamingMetricsTest.lambda$checkDataReceived$e7abd6ea$1(StreamingMetricsTest.java:356)
	at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
	at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
	at java.base/java.lang.Thread.run(Thread.java:834)
{noformat}

Also:

{noformat}
junit.framework.AssertionFailedError: [The amount of files received by node1 from node2 is not the expected one. [expected: 3, actual: 4]] expected:<[3]L> but was:<[4]L>
	at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
	at org.apache.cassandra.distributed.test.metrics.StreamingMetricsTest.lambda$checkDataReceived$e7abd6ea$1(StreamingMetricsTest.java:356)
	at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
	at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
	at java.base/java.lang.Thread.run(Thread.java:834)
{noformat}

https://ci-cassandra.apache.org/job/Cassandra-devbranch/716/
Bug: Fix  org.apache.cassandra.distributed.test.FqlReplayDDLExclusionTest.test
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 07/Jun/21 16:54
Resolved: 09/Jun/21 14:40

It failed a few times in Jenkins lately. Example:

[https://jenkins-cm4.apache.org/job/Cassandra-4.0.0/12/testReport/junit/org.apache.cassandra.distributed.test/FqlReplayDDLExclusionTest/test/]
{code:java}
Error Message
Expected: [[1]] Actual: []

Stacktrace
junit.framework.AssertionFailedError: Expected: [[1]] Actual: [] at org.apache.cassandra.distributed.shared.AssertUtils.assertRows(AssertUtils.java:58) at org.apache.cassandra.distributed.test.FqlReplayDDLExclusionTest.test(FqlReplayDDLExclusionTest.java:102)
{code}
I was also able to reproduce it locally on the latest 4.0.0 so I believe it is worth it to be checked. 

//CC [~stefan.miklosovic] and [~bereng] as I see you two are the only people who worked on that test up to now so If you have any thoughts to share, as usual, that will be highly appreciated :)
Bug: NativeLibrary#getProcessID() does not handle `UnsatisfiedLinkError`
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 08/Apr/21 18:30
Resolved: 30/Jul/21 12:05

NativeLibrary#getProcessID() does not handle `UnsatisfiedLinkError` (derived from Error, not Exception) as the other native methods do. Therefore, it can never return -1 when it fails for this reason, and can break callers that would otherwise be able to handle the situation gracefully. Most other methods in the class do this, but this one is missing the handling of this error.
Bug: The dependencies in the Cassandra DEB package prevent installation on Ubuntu 20.04+
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 15/Apr/21 10:44
Resolved: 16/Jun/21 18:54

The DEB package for Cassandra has a dependency on 'python >= 2.7'.

In Ubuntu 18.04 there is a package called 'python' which installs python2.7.

This package has been removed in Ubuntu 20.04 so the dependency cannot be satisified.

 

Proposed solution:

Change the dependency 'python >= 2.7' to something like 'python2 >= 2.7 OR python3 >= 3.6'.
Bug: Preserve Query Performance with ClusteringIndexNamesFilter After Running DROP COMPACT STORAGE
Status: Open
Priority: Normal
Created: 18/May/21 18:00

Before the completion of CASSANDRA-16226, upgrading a cluster from 2.1 to 3.0 with compact tables could cause a significant regression in the latency of reads using ClusteringIndexNamesFilter. The details are described in that Jira, but in short, 3.0+ did not skip SSTables it should have during reads, because it thought (wrongly) there might be primary key liveness information in SSTables for compact tables.

CASSANDRA-16226 addressed this behavior for still-compact tables, and also maintained it after DROP COMPACT STORAGE was run. However, it also allowed tables that were never compact to drop rows from query results if they contained no live non-key columns, which is only a normal behavior for compact tables. This is addressed in CASSANDRA-16671 by reverting the bits of the logic from CASSANDRA-16226 that deal with formerly compact tables where DROP COMPACT STORAGE has been run, in the interest of unblocking the 4.0 release and making sure strictly compact and strictly non-compact tables are queried properly and construct properly formed results.

This goal of this issue is to safely restore the performance of formerly compact tables, which necessarily contain ambiguous primary key liveness info. Roughly, the idea is that we record in a system table (and pull into TableMetadata) the time when DROP COMPACT STORAGE is executed. If a time exists for a table, we can treat it as being formerly compact, and ignore primary key liveness info for determining row completeness in SinglePartitionReadCommand#isComplete(). Otherwise, the normal rules for never-compact tables will apply, avoiding any regression in the scenario described by CASSANDRA-16671.

This would obviously not be helpful in the case where a user has already dropped compact storage, but it may logically be the best we can do, given we cannot correctly reconstruct liveness info for SSTables created while a table was compact (i.e. there is no way to tell INSERT and UPDATE apart for those). Especially if CASSANDRA-16671 moves in the direction of disabling DROP COMPACT STORAGE by default, I would also propose that we do this only for 4.0+.
Bug: WEBSITE - June 2021 updates
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 04/Jun/21 23:16
Resolved: 18/Jun/21 10:37

Sharing a batch of HTML updates to be made to the website that includes:
 * Added 2 blog posts
 * Added folder with 2 images to img/blog for Cassandra and Kubernetes SIG update
 * Added Hornet logo and Cassandra Kubernetes SIG image
 * Added new Case Study for Hornet
 * Added 40 items to Ecosystem page including Cassandra Cloud Offerings, Cassandra Tools, Cassandra Kubernetes Operators, and Developer Frameworks
 * Updated blog site
 * Updated Instagram logo
 * Updated Community Spotlights on the homepage
Bug: Exception thrown by custom QueryHandler constructor is ignored
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 28/May/21 15:15
Resolved: 07/Jul/21 16:50

When a exception is thrown during the instantiation of the _cassandra.custom_query_handler_class,_ depending on the exception thrown cassandra will simply log an info message and proceed with the bootstraping with the standard _QueryHandler_ as a fallback measure: [https://github.com/apache/cassandra/blob/cassandra-3.11.10/src/java/org/apache/cassandra/service/ClientState.java#L107|https://github.com/apache/cassandra/blob/3b553d8e13dbdbe59119de9c917d9aacc440741e/src/java/org/apache/cassandra/service/ClientState.java#L104]

The end-user will never know if the custom _QueryHandler_ is actually registered or not, unless he notices the info message on the logs.

Ideally, the message should be logged as error and JVM should stop as it cannot proceed according with the user expected configuration.

*Scenario*:

In our scenario, we have a custom _QueryHandler_ that receives specific configuration, and we throw a _ConfigurationException_ at instantiation time in case of any invalid config value. It is expected that cassandra stop the bootstraping instead of skipping the QH.
Bug: Fix org.apache.cassandra.utils.SlidingTimeRateTest.testConcurrentUpdateAndGet
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 04/Jun/21 22:51
Resolved: 07/Jul/21 18:10

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
Bug: Flaky ClientResourceLimitsTest
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 23/Jun/21 08:08
Resolved: 30/Jun/21 11:32

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}
Bug: Consistency Level ALL_MINUS_ONE
Status: Resolved
Priority: Normal
Resolution: Duplicate
Created: 30/Jun/21 14:20
Resolved: 30/Jun/21 14:28

We have an application that is deployed in a variety of Cassandra cluster configurations using RF=3. We'd like to be able to always tolerate a single node being down. We write data into the cluster using consistency level TWO.

We would like to add ConsistencyLevel.ALL_MINUS_ONE to more clearly express our desire for relatively strong consistency. EACH_QUORUM is not enough but CL.ALL has unacceptable availability.