av9ash/GitBugs huggingface dataset:
Bug: flaky test testWriteUnknownResult- org.apache.cassandra.distributed.test.CasWriteTest
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 30/Mar/20 15:21
Resolved: 20/May/20 04:32

Failure observed in: https://app.circleci.com/pipelines/github/newkek/cassandra/33/workflows/54007cf7-4424-4ec1-9655-665f6044e6d1/jobs/187/tests

{noformat}
testWriteUnknownResult - org.apache.cassandra.distributed.test.CasWriteTest
junit.framework.AssertionFailedError: Expecting cause to be CasWriteUncertainException
	at org.apache.cassandra.distributed.test.CasWriteTest.testWriteUnknownResult(CasWriteTest.java:257)
	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: When a LZ4 stream is corrupted it could cause the JVM to crash
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 07/Feb/20 01:08
Resolved: 11/Feb/20 17:08

This is a spin off of CASSANDRA-15313 and  CASSANDRA-15299

This was found when lz4 sees compressed data (not all, but happens) which is corrupted; in some cases the JVM crashes producing the following

{code}
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGBUS (0xa) at pc=0x0000000110d46ad1, pid=86555, tid=0x0000000000001103
#
# JRE version: OpenJDK Runtime Environment (8.0_222-b10) (build 1.8.0_222-b10)
# Java VM: OpenJDK 64-Bit Server VM (25.222-b10 mixed mode bsd-amd64 compressed oops)
# Problematic frame:
# C  [liblz4-java2766366422904460658.dylib+0x3ad1]  LZ4_decompress_fast+0xf1
#
# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# /Users/davidcapwell/src/github/apache/cassandra/hs_err_pid86555.log
{code}
Bug: Add AssertJ test dependency
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 11/Mar/20 14:46
Resolved: 02/Apr/20 19:24

See [proposal|https://lists.apache.org/thread.html/rc562ec47578d0ae6f346ba9e3d7469c1cd3f8b521a72ddcb2accc47b%40%3Cdev.cassandra.apache.org%3E].

The goal is to add [AssertJ|https://assertj.github.io/doc/] to the test framework to allow for more comprehensible and easier to write tests.
Bug: Refactor repair coordinator so errors are consistent
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 11/Feb/20 00:33
Resolved: 01/Apr/20 06:59

This is to split the change in CASSANDRA-15399 so the refactor is isolated out.

Currently the repair coordinator special cases the exit cases at each call site; this makes it so that errors can be inconsistent and there are cases where proper complete isn't done (proper notifications, and forgetting to update ActiveRepairService).

[Circle CI|https://circleci.com/gh/dcapwell/cassandra/tree/bug%2FrepairCoordinatorJmxConsistency]
Bug: add mick's second (RSA) gpg key to the project's KEYS file
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 30/Jan/20 09:41
Resolved: 30/Jan/20 15:50

Following on from CASSANDRA-15360... 

The signing RPMs with `rpmsign` during the release process requires a RSA key. So my existing DSA key from 15360 does not work with `rpmsign`

The patch adds my gpg public key to the project's KEYS file found at https://dist.apache.org/repos/dist/release/cassandra/KEYS

My gpg public key here has the fingerprint
 A4C4 65FE A0C5 5256 1A39  2A61 E913 35D7 7E3E 87CB
Bug: Testcase: testSubrangeCompaction(org.apache.cassandra.db.compaction.CancelCompactionsTest):	FAILED
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 27/Mar/20 17:47
Resolved: 10/Apr/20 13:53

The following test failure was observed:
[junit-timeout] Testcase: testSubrangeCompaction(org.apache.cassandra.db.compaction.CancelCompactionsTest):	FAILED
[junit-timeout] expected:<4> but was:<5>
[junit-timeout] junit.framework.AssertionFailedError: expected:<4> but was:<5>
[junit-timeout] 	at org.apache.cassandra.db.compaction.CancelCompactionsTest.testSubrangeCompaction(CancelCompactionsTest.java:190)

Java 8
Bug: in-jvm dtest upgrade tests don't support 4.0 versioning
Status: Resolved
Priority: Normal
Resolution: Duplicate
Created: 07/Jan/20 18:27
Resolved: 16/Jan/20 21:14

The current 4.0 versioning has a tag to denote that 4.0 isn’t in public release yet (currently beta3).  dtest does version parsing which is much more restive and doesn’t support preRelease tags (like the client version parsing does), so skips the 4.0 jar.  This then leads to a exception while running the upgrade tests
 
{code}
java.lang.RuntimeException: No v4 versions found
	at org.apache.cassandra.distributed.impl.Versions.lambda$getLatest$2(Versions.java:166)
	at java.util.Optional.orElseThrow(Optional.java:290)
	at org.apache.cassandra.distributed.impl.Versions.getLatest(Versions.java:166)
	at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
	at java.util.Spliterators$ArraySpliterator.forEachRemaining(Spliterators.java:948)
	at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:482)
	at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:472)
	at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:546)
	at java.util.stream.AbstractPipeline.evaluateToArrayNode(AbstractPipeline.java:260)
	at java.util.stream.ReferencePipeline.toArray(ReferencePipeline.java:505)
	at org.apache.cassandra.distributed.upgrade.UpgradeTestBase$TestCase.upgrade(UpgradeTestBase.java:92)
	at org.apache.cassandra.distributed.upgrade.UpgradeTest.upgradeTest(UpgradeTest.java:35)
{code}
Bug: Fix flakey test - org.apache.cassandra.distributed.test.MessageForwardingTest mutationsForwardedToAllReplicasTest
Status: Resolved
Priority: Normal
Resolution: Duplicate
Created: 24/Jan/20 23:34
Resolved: 27/Jan/20 21:57

{code}
junit.framework.AssertionFailedError: /127.0.0.2 should have been randomized to forward messages
	at org.apache.cassandra.distributed.test.MessageForwardingTest.lambda$mutationsForwardedToAllReplicasTest$7(MessageForwardingTest.java:87)
	at java.base/java.util.HashMap.forEach(HashMap.java:1336)
	at org.apache.cassandra.distributed.test.MessageForwardingTest.mutationsForwardedToAllReplicasTest(MessageForwardingTest.java:87)
	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)
{code}
Bug: Message filtering should apply on the inboundSink in In-JVM dtest
Status: Resolved
Priority: Normal
Resolution: Duplicate
Created: 12/Feb/20 18:03
Resolved: 20/Apr/20 15:27

The message filtering mechanism in the in-jvm dtest helps to simulate network partition/delay. 
The problem of the current approach that adds all filters to the {{MessagingService#outboundSink}} is that a blocking filter blocks the following filters to be evaluated since there is only a single thread that evaluates them. It further blocks the other outing messages. The typical internode messaging pattern is that the coordinator node sends out multiple messages to other nodes upon receiving a query. The described blocking messages can happen quite often.
The problem can be solved by moving the message filtering to the {{MessagingService#inboundSink}}, so that each inbounding message is naturally filtered in parallel.
Bug: Create a deterministic in-jvm equivalent of dtest TestBootstrap.test_resumable_bootstrap
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 11/Mar/20 15:55
Resolved: 09/Apr/20 14:38

This ticket is a followup on CASSANDRA-15614 - fix flakey test TestBootstrap.test_resumable_bootstrap.

The dtest is not really fully deterministic.  In-jvm test might give a way for better control on the streaming failures.
Bug: Full Query Logging - New Feature
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 07/Jan/20 02:13
Resolved: 14/Feb/20 01:19

Added a page on Full Query logging, a new feature.
 [https://github.com/apache/cassandra/pull/404]

 

Related ticket: https://issues.apache.org/jira/browse/CASSANDRA-15971
Bug: DOC - Improve installation pages, include YUM procedure
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 02/Jan/20 04:13
Resolved: 09/Apr/20 23:09

h2. Background
The installation instructions are a little lacking. I'm proposing we add more explicit steps which are targeted towards users who are very new to Cassandra.

h2. Proposal
We can improve the installation pages with explicit instructions for the following:
* steps for installing older versions to match nodes in an existing cluster
* steps for installing RHEL/CentOS package with YUM

I am preparing a draft with details to follow.
Bug: Slow query logging emits incomplete predicates
Status: Resolved
Priority: Normal
Resolution: Duplicate
Created: 13/Jan/20 05:07
Resolved: 18/Jun/20 13:06

Using Apache Cassandra 3.11.2, defined a table like this:
 
_create table my_table(_
                 __                   _partition text,_
       __                   _clustering1 int,_
                  _clustering2 text,_
                  _data set<text>,_
                **                _*primary key (partition, clustering1, clustering2))*_
 
and configured slow queries threshold to 1ms in yaml to see how queries passed to cassandra. Query below:
 
_select * from my_table where partition='a' and clustering1= 1 and clustering2='b'_
 
would be like this in debug.log of cassandra:
 
_select * from my_table where partition='a' LIMIT 100>  (it means that the two cluster key restriction did not push down to storage engine and the whole partition been retrieved)_
 
but this query:
 
_select * from my_table where partition='a' and clustering1= 1_
 
_would be_
 
_select * from my_table where partition='a' and_ _clustering1= 1_ _LIMIT 100> (single cluster key been pushed down to storage engine)_
 
 
_So it seems to me that, we could not restrict multiple clustering keys in select because it would retrieve the whole partition ?!_
Bug: Slow query log indicates opposite LTE when GTE operator
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 14/Jan/20 23:21
Resolved: 11/May/20 11:20

Slow query log is indicating a '<=' when a ">=" operator was sent. This appears to be a logging only issue, but it threw off development for a day figuring this out. Please fix.

How to reproduce. Set slow query log timeout to 1 millisecond.

In cqlsh run

{noformat}
CREATE TABLE atable (
      .id text,
      timestamp timestamp,
      PRIMARY KEY ((id), timestamp)
 ) WITH CLUSTERING ORDER BY (timestamp DESC);
insert into atable (id, timestamp) VALUES ( '1',1);
insert into atable (id, timestamp) VALUES ( '2',2);
insert into atable (id, timestamp) VALUES ( '3',3);
insert into atable (id, timestamp) VALUES ( '4',4);
insert into atable (id, timestamp) VALUES ( '5',5);
insert into atable (id, timestamp) VALUES ( '6',6);
insert into atable (id, timestamp) VALUES ( '7',7);
insert into atable (id, timestamp) VALUES ( '8',8);
insert into atable (id, timestamp) VALUES ( '9',9);
insert into atable (id, timestamp) VALUES ( '10',10);
insert into atable (id, timestamp) VALUES ( '11',11);

select * from atable where timestamp >= '1970-01-01 00:00:00.006+0000' allow filtering;
{noformat}


In the logs it prints:

{noformat}
DEBUG 1 operations were slow in the last 5003 msecs:
<SELECT * FROM ks.atable WHERE timestamp <= 1970-01-01 00:00Z LIMIT 100>, time 7 msec - slow timeout 1 msec
{noformat}

But the query works appropriately and returns

{noformat}
 id | timestamp
----+---------------------------------
  6 | 1970-01-01 00:00:00.006000+0000
  7 | 1970-01-01 00:00:00.007000+0000
  9 | 1970-01-01 00:00:00.009000+0000
 10 | 1970-01-01 00:00:00.010000+0000
  8 | 1970-01-01 00:00:00.008000+0000
 11 | 1970-01-01 00:00:00.011000+0000

(6 rows)
{noformat}
Bug: Declarative Jenkins pipeline builds (and removing `ant test-all`)
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 10/Jan/20 09:20
Resolved: 21/Jan/20 18:16

*Declarative Jenkins pipeline*
Currently all the jenkins build jobs are generated by the DSL job from the cassandra-builds repository.
For a given branch, there are numerous builds: artifacts, unit tests, and dtests.
Using a (declarative) {{Jenkinsfile}} in-tree these builds can be put together into per-branch pipelines.

Per-branch pipelines will give a nicer UI (via blue ocean) and one place to look at test results for any branch and commit. From there we can post one complete test summary on commits back to the related jira ticket.

ref: https://lists.apache.org/thread.html/rc8d5a55142ea3bfb742e3347b8ea924946796bad03a1e089c8fb9ee7%40%3Cdev.cassandra.apache.org%3E

*Removing {{`ant test-all`}}*
Currently the test-all target does nothing but execute the test target.
This is because the test targets finishes with unit test failures.

As these jenkins jobs are automated here: https://github.com/apache/cassandra-builds/blob/master/jenkins-dsl/cassandra_job_dsl_seed.groovy#L44 ; it is easy enough to remove the "test-all" target, replacing it with separate jobs for 'stress-test', 'fqltool-test', and 'long-test'.
Bug: Update default for num_tokens from 256 to something more reasonable
Status: Resolved
Priority: Normal
Resolution: Duplicate
Created: 24/Jan/20 03:52
Resolved: 01/Jun/20 05:42

The default for num_tokens or the number of token ranges assigned to a node using virtual nodes is way too high.  256 token ranges makes repair painful.  Since it's a default, someone new to Cassandra won't know better and if left unchanged, they will have to live with it or perform a migration to a new datacenter with a lower number.

At the same time, going too low with the default allocation algorithm can hotspot nodes to have more tokens assigned than others.  There is a new token allocation algorithm introduced but it's not default.

The proposal of this ticket is to set the default to something more reasonable to align with best practices without using the new token algorithm or giving it specific token values as some do.  32 is a good compromise and is what the project uses in a lot of the tests that are done.

So generally it would be good to move to a more sane value and to align with testing so users are more confident that the defaults have a lot of testing behind them.

As discussed on the dev mailing list, we want to make sure this change to the default doesn't come as an unpleasant surprise to cluster operators.  For num_tokens specifically, if you were to upgrade to a version with the new default and the user didn't change it to the existing value, the node would not start, saying you can't change the num_tokens on an existing node.  So we will want to put a release note to indicate that when upgrading, make a note of the num_tokens change when looking at the new configuration.

Along with not being able to start nodes, which is fail-fast, there is the matter of adding new nodes to the cluster.  You can certainly add a new node to a cluster or datacenter with a different number of token ranges assigned.  It will give that node a different amount of data to be responsible for.  For example, if the nodes in a datacenter all have num_tokens=256 (current default) and you add a node to that datacenter with num_tokens=32 (new default), it will only claim 1/8th of the token ranges and data as the other nodes in that datacenter.  Fortunately, this is a property that is explicitly defined rather than implicit like some of the table settings.  Also most if not all operators will upgrade the existing nodes to that new version before trying to add a node with that new version.  So if there is a different number for num_tokens on the existing nodes, they'll be aware of it immediately.

In any case, this is a long proposal for what will be a small change in the cassandra.yaml and something in the release notes, that is, changing the default num_tokens value from 256 to 32.
Bug: Transient Replication: unable to insert data when the keyspace is configured with the SimpleStrategy
Status: Resolved
Priority: Normal
Resolution: Duplicate
Created: 27/Mar/20 15:05
Resolved: 14/May/20 17:36

An error is thrown then trying to insert data with the transient replication + SimpleStrategy configured.

Test case:
{code:java}
CREATE KEYSPACE test_tr WITH replication = {'class': 'SimpleStrategy', 'replication_factor': '3/1'};
CREATE TABLE test_tr.users (id int PRIMARY KEY, username text) with read_repair ='NONE';
INSERT INTO test_tr.users (id, username) VALUES (1, 'alan');{code}
 

traceback:
{code:java}
ERROR [Native-Transport-Requests-8] 2020-03-27 10:27:17,188 ErrorMessage.java:450 - Unexpected exception during request
java.lang.ClassCastException: org.apache.cassandra.locator.SimpleStrategy cannot be cast to org.apache.cassandra.locator.NetworkTopologyStrategy
	at org.apache.cassandra.db.ConsistencyLevel.eachQuorumForRead(ConsistencyLevel.java:103)
	at org.apache.cassandra.db.ConsistencyLevel.eachQuorumForWrite(ConsistencyLevel.java:112)
	at org.apache.cassandra.locator.ReplicaPlans$2.select(ReplicaPlans.java:409)
	at org.apache.cassandra.locator.ReplicaPlans.forWrite(ReplicaPlans.java:353)
	at org.apache.cassandra.locator.ReplicaPlans.forWrite(ReplicaPlans.java:348)
	at org.apache.cassandra.locator.ReplicaPlans.forWrite(ReplicaPlans.java:341)
	at org.apache.cassandra.locator.ReplicaPlans.forWrite(ReplicaPlans.java:330)
	at org.apache.cassandra.service.StorageProxy.performWrite(StorageProxy.java:1171)
	at org.apache.cassandra.service.StorageProxy.mutate(StorageProxy.java:713)
	at org.apache.cassandra.service.StorageProxy.mutateWithTriggers(StorageProxy.java:951)
	at org.apache.cassandra.cql3.statements.ModificationStatement.executeWithoutCondition(ModificationStatement.java:475)
	at org.apache.cassandra.cql3.statements.ModificationStatement.execute(ModificationStatement.java:453)
	at org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:216)
	at org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:247)
	at org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:233)
	at org.apache.cassandra.transport.messages.QueryMessage.execute(QueryMessage.java:108)
	at org.apache.cassandra.transport.Message$Request.execute(Message.java:253)
	at org.apache.cassandra.transport.Message$Dispatcher.processRequest(Message.java:725)
	at org.apache.cassandra.transport.Message$Dispatcher.lambda$channelRead0$0(Message.java:630)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
	at org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:165)
	at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:119)
	at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
	at java.lang.Thread.run(Thread.java:748)
 {code}
 

--> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/ConsistencyLevel.java#L103
Bug: Fix flaky test org.apache.cassandra.index.internal.CassandraIndexTest indexCorrectlyMarkedAsBuildAndRemoved
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 11/Feb/20 01:06
Resolved: 11/Mar/20 10:40

{code}
junit.framework.AssertionFailedError: Got more rows than expected. Expected 1 but got 4.
	at org.apache.cassandra.cql3.CQLTester.assertRows(CQLTester.java:1098)
	at org.apache.cassandra.index.internal.CassandraIndexTest.indexCorrectlyMarkedAsBuildAndRemoved(CassandraIndexTest.java:499)
	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)
{code}

The failure was seen on java 11.
Bug: Allow cassandra-diff to be run via in-jvm java code rather than only via spark-submit
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 08/Jan/20 15:47
Resolved: 14/Jan/20 10:02

It should be possible to run the cassandra-diff tool via java code, and run it multiple times within the same JVM, rather than only being able to execute it via spark-submit. Make the necessary changes to allow for this use-case.
Bug: Fix flaky test org.apache.cassandra.tools.StandaloneVerifierTest.testStandaloneVerifier_WithArgs
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 17/Feb/20 22:22
Resolved: 21/Feb/20 20:07

Failure was seen on java 8.
{code}
java.lang.NullPointerException
	at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
	at java.util.Spliterators$ArraySpliterator.forEachRemaining(Spliterators.java:948)
	at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:482)
	at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:472)
	at java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708)
	at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
	at java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:566)
	at org.apache.cassandra.tools.ToolsTester.assertNoUnexpectedThreadsStarted(ToolsTester.java:86)
	at org.apache.cassandra.tools.StandaloneVerifierTest.testStandaloneVerifier_WithArgs(StandaloneVerifierTest.java:45)
{code}
Bug: Lower the amount of garbage ChecksummingTransformerTest generates by reusing memory
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 06/Feb/20 22:25
Resolved: 07/Feb/20 01:56

When the test finds a issue and attempts to shrink, a ton of garbage is generated which cause the test to then fail with GC issues.  Since the test is a quick theories test, we can rewrite the generates to reuse memory rather than creating new objects for each iteration.  This will also let us move away from String which requires multiple copies in the test and gets rid of the getBytes() call which is dependent on the system its called on.

|[Circle CI|https://circleci.com/gh/dcapwell/cassandra/tree/quickTheoryMemory]|
Bug: Change io.compressor.LZ4Compressor to LZ4SafeDecompressor
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 07/Feb/20 21:36
Resolved: 30/Apr/20 15:26

CASSANDRA-15556 and related tickets showed that LZ4FastDecompressor can crash the JVM and that LZ4SafeDecompressor performs better w/o the crash risk — its also not deprecated. While we protect ourselves by checksumming the compressed data but that doesn’t mean we should leave deprecated code that can segfault the jvm (providing a potential DDOS vector among other things) in crucial places like io.compress.
Bug: Fix flakey testSendLarge - org.apache.cassandra.net.ConnectionTest
Status: Resolved
Priority: Normal
Resolution: Duplicate
Created: 10/Mar/20 16:39
Resolved: 26/Mar/20 09:30

The test fails sometimes with the following error message and trace. 

{code:java}
received count values don't match expected:<10> but was:<9>

junit.framework.AssertionFailedError: received count values don't match expected:<10> but was:<9>
at org.apache.cassandra.net.ConnectionUtils$InboundCountChecker.doCheck(ConnectionUtils.java:212)
at org.apache.cassandra.net.ConnectionUtils$InboundCountChecker.check(ConnectionUtils.java:200)
at org.apache.cassandra.net.ConnectionTest.lambda$testSendLarge$15(ConnectionTest.java:359)
at org.apache.cassandra.net.ConnectionTest.lambda$doTest$8(ConnectionTest.java:242)
at org.apache.cassandra.net.ConnectionTest.doTestManual(ConnectionTest.java:262)
at org.apache.cassandra.net.ConnectionTest.doTest(ConnectionTest.java:240)
at org.apache.cassandra.net.ConnectionTest.test(ConnectionTest.java:229)
at org.apache.cassandra.net.ConnectionTest.testSendLarge(ConnectionTest.java:312)
{code}