av9ash/GitBugs huggingface dataset:
Bug: Add Option to Timebox write timestamps
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 21/Mar/23 07:07
Resolved: 17/May/23 20:35

In several cases it is desirable to have client provided timestamps generated at the application-level. This can be error prone, however. In particular, applications can choose timestamps that may be nonsensical for a given application. One dangerous manifestation of this is the "doomstone" (a tombstone far in the future of any realistic write). This feature would allow either operators or users to specify a minimum and maximum timebound of "reasonable" timestamps. The default would be negative infinity, positive infinity to maintain backwards compatibility. Writes that are USING TIMESTAMP with a timestamp outside of the timebox will see an exception.
Bug: Operations.migrateReadRequiredOperations fails due to concurrent access when TransactionStatement is prepared
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 16/Mar/23 01:08
Resolved: 17/Mar/23 19:04

{code}
java.util.NoSuchElementException
	at java.base/java.util.ArrayList$Itr.next(ArrayList.java:1000)
	at org.apache.cassandra.cql3.Operations.migrateReadRequiredOperations(Operations.java:71)
	at org.apache.cassandra.cql3.Operations.migrateReadRequiredOperations(Operations.java:63)
	at org.apache.cassandra.cql3.statements.ModificationStatement.getTxnWriteFragment(ModificationStatement.java:828)
	at org.apache.cassandra.cql3.statements.TransactionStatement.createWriteFragments(TransactionStatement.java:290)
	at org.apache.cassandra.cql3.statements.TransactionStatement.createUpdate(TransactionStatement.java:309)
	at org.apache.cassandra.cql3.statements.TransactionStatement.createTxn(TransactionStatement.java:334)
	at org.apache.cassandra.cql3.statements.TransactionStatement.execute(TransactionStatement.java:375)
{code}

this was caused by having shared mutable state!  when we start creating the txn objects we would also mutate the mutations that had operations that need to be run in the txn, this has an issue when the txn is run from prepared statements as the object is shared by multiple threads, causing the array to be mutated while iterating.
Bug: Enhance diagnostic nodetool tablestats output
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 23/Feb/23 19:00
Resolved: 08/Mar/23 15:51

The nodetool tablestats command lacks some available details which would be very useful to report upon.  This is especially helpful in database-as-a-service environments where servers and their disk files are not directly observable by users.

1. Currently, for LCS tablestats reports useful details about the number of sstables in each level:

          SSTable count: 6635

          SSTables in each level: [1, 9, 98, 805, 5722, 0, 0, 0, 0]

This type of additional detail about the sstables is absent from STCS and TWCS as it only reports the table count. 

1a) For STCS, tablestats should report the max sstable file size on disk. This is useful to know if compaction has failed due to disk space or if a forced compaction created a jumbo table.

1b) For TWCS, tablestats should report the min & max timestamp, and duration of the sstables representing windows.  This is useful to know if out-of-window writes or rows w/out a TTL have lead many more sstables on disk than expected by the time window configuration.

STCs example:

          SSTable count: 6635

          SSTable STCS max size: 122,000,000,000

TWCs example:

         SSTable count: 6635

          SSTables Time Window 15 DAYS, max duration : 362d 7h 16m 49s

2. While tablestats reports both memtable and disk file sstable statistics. It is useful these are in the same command, but it would clarify the output to separate mem vs disk into two sections

i.e., 

     -- File statistics

     SSTable count: 6635

     SSTables in each level: [1, 9, 98, 805, 5722, 0, 0, 0, 0] 

     -- Memtable statistics

     Bloom filter false positives: 12184123

     Bloom filter false ratio: 0.07203

     Bloom filter space used: 16874424

     Bloom filter off heap memory used: 16821344

     Index summary off heap memory used: 7525546

     Space used (live): 1324067896238

3.  Read / Write count should also be reported as a ratio, such as:

     Local read count: 202961459

     Local write count: 40554481

     Local read/write ratio: 5:1    <new>

     Local read latency: 1.957 ms

     Local write count: 40554481

     Local write latency: 0.040 ms
Bug: Coordinator level metrics for read response and mutation row and column counts
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 13/Jan/23 19:18
Resolved: 27/Jan/23 18:05

We propose creating a new metric group, {{ClientRequestSize}}, that will house 4 new coordinator-level metrics:

1.) ColumnsRead - the total number of columns returned from the database to clients
2.) RowsRead - the total number of rows returned from the database to clients
3.) ColumnsWritten - the total number of columns written to the database by clients
4.) RowsWritten - the total number of rows written to the database by clients
Bug:  NoSuchFileException when removing a snapshot
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 31/Jan/23 20:24
Resolved: 17/Feb/23 14:58

Automatic deletion of expired snapshots maintained by {{SnapshotManager}} can race with manual snapshot removal in a way an exception like {{NoSuchFileException}} is thrown. 

It is because the snapshot directory existence is checked and deleted if it exists as a non-atomic operation. Since we can potentially have two threads attempting to do that at the same time (automatic and manual snapshot removal) it may lead to a race in rare situations.
Bug: BufferPool incorrectly counts memoryInUse when putUnusedPortion is used
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 09/Mar/23 11:33
Resolved: 13/Mar/23 09:09

The counter is incorrectly decremented by the size of the unused portion of the provided buffer.
It should be decremented by the number of bytes actually returned to the pool (that may be different than "size"). The number should be calculated as a difference between original and resulting buffer capacity.
Bug: dtest.client_request_metrics_test.TestClientRequestMetrics.test_client_request_metrics 
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 16/Feb/23 08:21
Resolved: 26/Jul/23 11:18

https://ci-cassandra.apache.org/job/Cassandra-trunk/1459/testReport/dtest.client_request_metrics_test/TestClientRequestMetrics/test_client_request_metrics/
and
https://ci-cassandra.apache.org/job/Cassandra-trunk/1461/testReport/dtest-offheap.client_request_metrics_test/TestClientRequestMetrics/test_client_request_metrics/


Error Message
AttributeError: 'dict' object has no attribute 'scope'
Stacktrace
self = <client_request_metrics_test.TestClientRequestMetrics object at 0x7f0f53975460>

    def test_client_request_metrics(self):
        # this is written as a single test method in order to reuse the same cluster for all tests
        # setup_once configures and starts the cluster with all schema and preconditions required by all tests.
        self.setup_once()
    
>       self.write_nominal()

client_request_metrics_test.py:85: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
client_request_metrics_test.py:116: in write_nominal
    global_diff, cl_diff = self.validate_nominal('Write',
Bug: CEP-15 (Accord) Expected reply message with verb ACCORD_INFORM_OF_TXNID_RSP but got ACCORD_SIMPLE_RSP
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 28/Mar/23 20:51
Resolved: 31/Mar/23 22:06

{code}
java.lang.IllegalArgumentException: Expected reply message with verb ACCORD_INFORM_OF_TXNID_RSP but got ACCORD_SIMPLE_RSP
	at com.google.common.base.Preconditions.checkArgument(Preconditions.java:440)
	at org.apache.cassandra.service.accord.AccordMessageSink.reply(AccordMessageSink.java:125)
	at accord.local.Node.reply(Node.java:361)
	at accord.messages.AbstractEpochRequest.accept(AbstractEpochRequest.java:63)
	at accord.messages.InformOfTxnId.accept(InformOfTxnId.java:66)
	at accord.messages.InformOfTxnId.accept(InformOfTxnId.java:31)
	at org.apache.cassandra.service.accord.async.AsyncOperation.finish(AsyncOperation.java:165)
	at org.apache.cassandra.service.accord.async.AsyncOperation.finish(AsyncOperation.java:176)
	at org.apache.cassandra.service.accord.async.AsyncOperation.runInternal(AsyncOperation.java:247)
	at org.apache.cassandra.service.accord.async.AsyncOperation.run(AsyncOperation.java:268)
	at org.apache.cassandra.service.accord.async.AsyncOperation.callback(AsyncOperation.java:157)
	at accord.utils.async.AsyncCallbacks.lambda$null$0(AsyncCallbacks.java:31)
{code}
Bug: Fix the output of FQL dump tool to properly separate entries
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 01/Feb/23 15:01
Resolved: 07/Feb/23 13:51

This was reported in (1)

(1) https://github.com/apache/cassandra/pull/2050

If I create a table something like this:

{code}
CREATE TABLE t1 ( id int PRIMARY KEY , v1 int, v2 int, v3 int) ;
{code}

and inserted a row using:

{code}
try (CqlSession cqlSession = CqlSession.builder().build()) {
    PreparedStatement preparedStatement = cqlSession.prepare("INSERT INTO ks1.t1 (id, v1, v2, v3) VALUES (?, ?, ?, ?)");
    cqlSession.execute(preparedStatement.bind(1, 1, 1, 1));
}
{code}

The output of fqltool looks something like this:

{code}
Type: single-query
Query start time: 1673373829119
Protocol version: 5
Generated timestamp:-9223372036854775808
Generated nowInSeconds:1673373829
Query: INSERT INTO ks1.t1 (id, v1, v2, v3) VALUES (?, ?, ?, ?)
Values: 
00000000 00 00 00 01                                      ····             
00000000 00 00 00 01                                      ····             
-----
00000000 00 00 00 01                                      ····             
-----
00000000 00 00 00 01                                      ····             
-----
{code}


----- is not printed between the first and second value

{code}
Values: 
00000000 00 00 00 01                                      ····             
00000000 00 00 00 01                                      ····   
{code}

We are normally very cautious about changing the output of the tooling but in this case I think this is a legit bug which should be fixed.
Bug: Backport CASSANDRA-17205 to 4.0 branch (strong ref leak)
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 14/Mar/23 20:39
Resolved: 03/Apr/23 20:31

See description in CASSANDRA-17205; this should have been applied on 4.0 and merged up but was overlooked.

 

Also double-check that strong leaks are logged at ERROR instead of WARN on both 4.0, 4.1, and trunk (see [comment|https://issues.apache.org/jira/browse/CASSANDRA-18176?focusedCommentId=17687184&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17687184])
Bug: Reorganize Apache C* docs in trunk branch to match the IA
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 03/Feb/23 22:27
Resolved: 24/Jul/23 15:16

An agreed-upon Information Architecture will be used to reorganize the C* 5.0 docs.

IA doc: https://docs.google.com/document/d/1A96K73vj9MbJoD7wJNgIKWrOkLq-ZL2cNZAEXSWrciY/edit?usp=sharing
Bug: Cassandra messaging to self changed behavior
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 26/Jan/23 06:59
Resolved: 30/Jan/23 13:08

During testing of Cassandra on AWS, we noticed some behavior changes between Cassandra 3.11 and Cassandra 4.0 when it comes to messaging.
When performing a range query with consistency local_quorum, Cassandra sents a request to itself and some peers.
In case of Cassandra 4.0, it's trying to connect to itself using the broadcast_address while in Cassandra 3.11 it's connecting using the local address (see [https://github.com/apache/cassandra/blob/cassandra-3.11/src/java/org/apache/cassandra/net/OutboundTcpConnectionPool.java#L152].

This translation seems to be missing in Cassandra 4.X. I think the best place to fix it would be here (see attached file): [https://github.com/apache/cassandra/blob/cassandra-4.0/src/java/org/apache/cassandra/net/OutboundConnectionSettings.java#L451]
Bug: Test failure in upgrade_tests.cql_tests.cls.test_limit_ranges
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 23/Jan/23 21:37
Resolved: 24/Jan/23 04:25

https://ci-cassandra.apache.org/job/Cassandra-trunk/1434/testReport/dtest-upgrade.upgrade_tests.cql_tests/cls/test_limit_ranges/

{noformat}
self = <abc.TestCQLNodes2RF1_Upgrade_indev_4_1_x_To_indev_trunk object at 0x7f27f9268e10>

    def test_limit_ranges(self):
        """ Validate LIMIT option for 'range queries' in SELECT statements """
        cursor = self.prepare(ordered=True)
    
        cursor.execute("""
            CREATE TABLE clicks (
                userid int,
                url text,
                time bigint,
                PRIMARY KEY (userid, url)
            ) WITH COMPACT STORAGE;
        """)
    
>       for is_upgraded, cursor in self.do_upgrade(cursor):

upgrade_tests/cql_tests.py:318: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
upgrade_tests/upgrade_base.py:197: in do_upgrade
    node1.start(wait_for_binary_proto=True)
../venv/lib/python3.11/site-packages/ccmlib/node.py:896: in start
    node.watch_log_for_alive(self, from_mark=mark)
../venv/lib/python3.11/site-packages/ccmlib/node.py:665: in watch_log_for_alive
    self.watch_log_for(tofind, from_mark=from_mark, timeout=timeout, filename=filename)
../venv/lib/python3.11/site-packages/ccmlib/node.py:584: in watch_log_for
    time.sleep(1)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

title = 'Timeout'
stream = <_io.TextIOWrapper name='<stderr>' mode='w' encoding='utf-8'>
sep = '+'

    def write_title(title, stream=None, sep="~"):
        """Write a section title.
    
        If *stream* is None sys.stderr will be used, *sep* is used to
        draw the line.
        """
        if stream is None:
            stream = sys.stderr
>       width = py.io.get_terminal_width()
E       AttributeError: module 'py' has no attribute 'io'

../venv/lib/python3.11/site-packages/pytest_timeout.py:444: AttributeError
{noformat}
Bug: upgradesstables does not always upgrade tables in proper order.
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 11/Jan/23 09:54
Resolved: 14/Mar/23 14:33

The SSTableUpgrader accepts tools in the hash order provided by Directories.SSTableLister rather than ordering them to ensure that they are upgraded in the proper order.

They should be ordered by their id. The comparator for SSTableId is available in SSTableIdFactory.COMPARATOR. 
 
Dev discussion thread: https://lists.apache.org/thread/w6pm5hbdxt295mtvlckv0joyk8x4o8nf
Bug: Add more logging around CompactionManager operations
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 16/Feb/23 14:21
Resolved: 07/Mar/23 20:57

Whenever a cleanup or garbagecollect operation is issued from nodetool, there is no log statuses for the start and end of the operation at the node level although statuses on individual sstables are captured. Start can be inferred, but it is difficult to know when the operation has completed because there is no log message.

 

[INFO ] cluster_id=5 ip_address=127.1.1.1  CompactionManager.java:353 - Starting Remove deleted data for keyspace1.sstable1

[INFO ] cluster_id=5 ip_address=127.1.1.1  CompactionManager.java:395 - Finished Remove deleted data for keyspace1.sstable1 successfully

[INFO ] cluster_id=5 ip_address=127.1.1.1  CompactionManager.java:353 - Starting Remove deleted data for keyspace1.sstable2

[INFO ] cluster_id=5 ip_address=127.1.1.1  CompactionManager.java:364 - No sstables to GARBAGE_COLLECT for keyspace1.sstable2

[INFO ] cluster_id=5 ip_address=127.1.1.1  CompactionManager.java:395 - Finished Remove deleted data for keyspace1.sstable2 successfully

 

This improvement proposes adding additional for start and end statuses log messages for the above operation at the node level. I.e.,

 

[INFO ] cluster_id=5 ip_address=127.1.1.1  CompactionManager.java:395 – Starting GARBAGE_COLLECT

….

[INFO ] cluster_id=5 ip_address=127.1.1.1  CompactionManager.java:395 – Completed GARBAGE_COLLECT
Bug: Remove legacy 3.x buffer pool metrics
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 09/Mar/23 13:09
Resolved: 22/Jul/23 09:38

Remove BufferPoolMetrics.register3xAlias() 

Patch: https://github.com/apache/cassandra/compare/trunk...thelastpickle:cassandra:mck/18313/trunk
Bug: Docker image for releases
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 09/Feb/23 07:48
Resolved: 05/Apr/23 15:43

The release process is currently driven bu this [doc|https://github.com/apache/cassandra-website/blob/trunk/site-content/source/modules/ROOT/pages/development/release_process.adoc] mainly.

Some of the requirements are a Debian based distro and a number of packages. As recently discovered this could be a problem, Ubuntu 20.04 LTS doesn't have createrepo available i.e.

To avoid such problems, add repeatability, have a controlled env where releases are cut, enable more people to cut them, etc [~mck] suggested creating a docker image to that purpose probably based off [this|https://github.com/apache/cassandra-builds/blob/trunk/docker/bullseye-image.docker]
Bug: conf/cassandra.yaml line number 431 availabile spelling mistake
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 30/Jan/23 23:45
Resolved: 31/Jan/23 12:33

https://github.com/apache/cassandra/blob/trunk/conf/cassandra.yaml#L431

 

conf/cassandra.yaml config file

430 # org.apache.cassandra.cache.SerializingCacheProvider
431 #   This is the row cache implementation availabile
432 #   in previous releases of Cassandra.
433 # row_cache_class_name: org.apache.cassandra.cache.OHCProvider

 

line number 431 : availabile should read available (spelling mistake)
Bug: Remove deprecated CQL functions dateof and unixtimestampof
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 14/Mar/23 11:57
Resolved: 16/Mar/23 15:56

The CQL functions {{dateof}} and {{unixtimestampof}} were [deprecated on Cassandra 2.2.0|https://github.com/apache/cassandra/commit/c08aaabd95d4872593c29807de6ec1485cefa7fa], almost eight years ago. They were deprecated in favour of the then new {{totimestamp}} and {{tounixtimestamp}} functions.

A note about their deprecation was added to [{{NEWS.txt}}|https://github.com/apache/cassandra/blob/trunk/NEWS.txt#L1421-L1423], and they were marked as deprecated on [{{CQL.textile}}|https://github.com/apache/cassandra/blob/trunk/doc/cql3/CQL.textile#time-conversion-functions]. They are also listed as deprecated on [the new doc|https://github.com/apache/cassandra/blob/trunk/doc/modules/cassandra/pages/cql/functions.adoc#time-conversion-functions].

We can finally remove those functions in 5.0, since they have been deprecated for so long.

Discussion thread [here|https://lists.apache.org/thread/0gs824fpsngn5dr0yq2x1h8qsflj5sr0].
Bug: A link to the pull request can be attached to the JIRA issue as soon as the PR is raised
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 28/Mar/23 17:11
Resolved: 29/Mar/23 11:34

According to the ASF recommendations [1] a link to a pull request might be automatically attached to the corresponding JIRA issue if the pull request matches the following title: "CASSANDRA-XXXX Something to improve".

To achieve this, the {{.asf.yml}} must be updated as follows:

{code}
notifications:
  ...
  jira_options: link worklog
{code}

[1] https://cwiki.apache.org/confluence/display/INFRA/Git+-+.asf.yaml+features#Git.asf.yamlfeatures-Jiranotificationoptions
Bug: Add support for prepared statements for accord transactions
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 03/Mar/23 19:12
Resolved: 09/Mar/23 00:04

When you try to prepare an accord transaction we get a NullPointerException in method org.apache.cassandra.cql3.statements.QualifiedStatement#isFullyQualified. This is due to TransactionStatement extending but not overriding all the methods (and setting name to null).
Bug: bulkLoaderSuccessfullyStreamsOverSsl fails with ClassCastException on JDK17
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 18/Jan/23 22:04
Resolved: 25/Jul/23 01:42

While working on CASSANDRA-17992 we hit: 
{code:java}
java.lang.ClassCastException: class org.apache.cassandra.utils.memory.BufferPool$Chunk cannot be cast to class sun.nio.ch.DirectBuffer (org.apache.cassandra.utils.memory.BufferPool$Chunk is in unnamed module of loader 'app'; sun.nio.ch.DirectBuffer is in module java.base of loader 'bootstrap')\n\tat java.base/com.sun.crypto.provider.GaloisCounterMode$GCMEngine.overlapDetection(GaloisCounterMode.java:865)\n\tat java.base/com.sun.crypto.provider.GaloisCounterMode$GCMDecrypt.doFinal(GaloisCounterMode.java:1502)\n\tat java.base/com.sun.crypto.provider.GaloisCounterMode.engineDoFinal(GaloisCounterMode.java:447)\n\tat 
{code}
-The issue is exposed with JDK 17, trunk; if interested, ping- [~e.dimitrova] -for current branch as there is no feature branch at the moment-  we can build and start from trunk with JDK17 already. Circle CI can be run for JDK17 too. For more information how to do that - .circleci/readme.md

CC [~benedict]
Bug: Upgrade jamm; fix eclipse problems
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 14/Mar/23 13:11
Resolved: 22/Jul/23 19:19

Jamm is currently under maintenance that will solve JDK11 issues and enable it to work with post JDK11+ versions up to JDK17.

This ticket will serve as a placeholder for upgrading Jamm in Cassandra when the new Jamm release is out.
Bug: Test failure: org.apache.cassandra.distributed.test.ByteBuddyExamplesTest.countTest
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 16/Mar/23 09:12
Resolved: 14/Jul/23 06:26

jdk8 and jdk11 all faild at some time, jdk8 failed once, and jdk11 failed twice.


for jdk 11:
org.apache.cassandra.distributed.test.ByteBuddyExamplesTest.countTest-.jdk11 (from org.apache.cassandra.distributed.test.ByteBuddyExamplesTest-.jdk11)
Error Message
expected:<1> but was:<2>
Stacktrace
junit.framework.AssertionFailedError: expected:<1> but was:<2>
	at org.apache.cassandra.distributed.test.ByteBuddyExamplesTest.lambda$countTest$81c80a4a$1(ByteBuddyExamplesTest.java:93)
	at org.apache.cassandra.concurrent.FutureTask$1.call(FutureTask.java:96)
	at org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:61)
	at org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:71)
	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:829)

for jdk 8:
Error Message
expected:<1> but was:<4>
Stacktrace
junit.framework.AssertionFailedError: expected:<1> but was:<4>
	at org.apache.cassandra.distributed.test.ByteBuddyExamplesTest.lambda$countTest$81c80a4a$1(ByteBuddyExamplesTest.java:93)
	at org.apache.cassandra.concurrent.FutureTask$1.call(FutureTask.java:96)
	at org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:61)
	at org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:71)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
	at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
	at java.lang.Thread.run(Thread.java:750)


https://ci-cassandra.apache.org/job/Cassandra-4.1/286/testReport/org.apache.cassandra.distributed.test/ByteBuddyExamplesTest/countTest_2/

https://ci-cassandra.apache.org/job/Cassandra-trunk/1489/testReport/org.apache.cassandra.distributed.test/ByteBuddyExamplesTest/countTest__jdk11/