av9ash/GitBugs huggingface dataset:
Bug: Update the slf4j-api library in order to avoid potential leaks
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 25/Sep/23 14:39
Resolved: 27/Sep/23 18:33

{color:red}>{color}The proposed update is 1.7.25 (current) > 1.7.36 (latest)

The following commits are included in the newer slf4j-api and that currently look very useful for us:
 - [SLF4J-469|https://www.mail-archive.com/slf4j-dev@qos.ch/msg02569.html] Potential memory leaks if there is no underlying implementation
 - [SLF4j-466|https://www.mail-archive.com/slf4j-dev@qos.ch/msg02499.html] Add test for all happy flow cases
 - [SLF4J-460|https://www.mail-archive.com/search?l=slf4j-dev@qos.ch&q=subject:%22%5C%5Bslf4j%5C-dev%5C%5D+%5C%5BJIRA%5C%5D+%5C%28SLF4J%5C-460%5C%29+EventRecodingLogger+debug+logs+as%09TRACE%22&o=newest&f=1)] EventRecodingLogger debug logs as TRACE
Bug: Upgrade hdrhistogram
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 28/Sep/23 22:19
Resolved: 03/Oct/23 15:21

We are on 2.1.9, but some breaking changes for J9+ were introduced only in 2.1.10 (we don't hit them in our CI but a user reported they saw NoClassFound in some testing)
https://github.com/HdrHistogram/HdrHistogram/commit/c410c5c2699b69ce0eb026ff954fefc4045ec363
Bug: Compactions are slow
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 17/Aug/23 01:41
Resolved: 02/Oct/23 12:18

I have noticed that compactions involving a lot of sstables are very slow (for example major compactions). I have attached a cassandra stress profile that can generate such a dataset under ccm. In my local test I have 2567 sstables at 4Mb each.

I added code to track wall clock time of various parts of the code. One problematic part is ManyToOne constructor. Tracing through the code for every partition creating a ManyToOne for all the sstable iterators for each partition. In my local test get a measy 60Kb/sec read speed, and bottlenecked on single core CPU (since this code is single threaded) with it spending 85% of the wall clock time in ManyToOne constructor.

As another datapoint to show its the merge iterator part of the code using the cfstats from [https://github.com/instaclustr/cassandra-sstable-tools/] which reads all the sstables but does no merging gets 26Mb/sec read speed.

Tracking back from ManyToOne call I see this in UnfilteredPartitionIterators::merge
{code:java}
                for (int i = 0; i < toMerge.size(); i++)
                {
                    if (toMerge.get(i) == null)
                    {
                        if (null == empty)
                            empty = EmptyIterators.unfilteredRow(metadata, partitionKey, isReverseOrder);
                        toMerge.set(i, empty);
                    }
                }
 {code}
Not sure what purpose of creating these empty rows are. But on a whim I removed all these empty iterators before passing to ManyToOne and then all the wall clock time shifted to CompactionIterator::hasNext() and read speed increased to 1.5Mb/s.

So there are further bottlenecks in this code path it seems, but the first is this ManyToOne and having to build it for every partition read.
Bug: Set io.netty.transport.noNative to false for in-jvm dtests
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 07/Sep/23 20:26
Resolved: 22/Sep/23 12:20

This ticket was created as a reaction to (1).

(1) https://lists.apache.org/thread/p42yksvo6t0dy67wmnl2bzpnggo9gpp9
Bug: remove bytebuddy / byteman from production classpath and remove compress-lzf dependency from build deps
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 23/Sep/23 12:19
Resolved: 10/Oct/23 08:30

I was digging in the project deps and if you compare all libs in "libs" dir and all libs in "build/lib/jars", there are indeed some differences which are OK however in build/lib/jars there are also libraries for byteman and byte-buddy. This is clearly wrong as these dependecies should not be accessible from the production code, only from tests.

The reason they are accessible in prod code is that there is the class TestRateLimiter (1). I do not have a clue why that class is in the prod code in the first place. The only place it is referenced in is here (2) but that byteman script is not loaded anywhere in tests. I was also checking Python dtests.

I think this is some leftover or something like "I will keep it here when I need it", but as nobody seems to do, I strongly advocate for removing it and making bytebuddy and byteman only test scoped dependencies as it should be.

A reader who pays attention notices that these dependencies are of provided scope which is a trick to have it compilable but not among the libraries in the production runtime and it does not do any harm as it is never invoked from the production code (if it was, it would fail on missing imports) neverthless this is still an issue which should be addressed. We were doing something similar with assertj dependency recently.

The second issue is that there is a dependency on compress-lzf in build dependencies. This is not necessary either as that library was removed from the repository in (3) but it still somehow leaked to the build process again. 

(1) https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/utils/TestRateLimiter.java
(2) https://github.com/apache/cassandra/blob/trunk/test/resources/byteman/mutation_limiter.btm
(3) https://github.com/apache/cassandra/commit/fc92db2b9b56c143516026ba29cecdec37e286bb
Bug: Test failure: org.apache.cassandra.repair.ConcurrentIrWithPreviewFuzzTest
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 28/Sep/23 11:43
Resolved: 03/Oct/23 16:50

The unit test {{org.apache.cassandra.repair.ConcurrentIrWithPreviewFuzzTest}} is flaky in both 5.0 and trunk:
* https://app.circleci.com/pipelines/github/adelapena/cassandra/3222/workflows/ecfca708-f183-429e-80e5-b2bfea8d25a0/jobs/80292/tests
* https://app.circleci.com/pipelines/github/adelapena/cassandra/3221/workflows/bb777ac0-6263-4d6e-aa54-35d6928e1e9b/jobs/80294

{code}
junit.framework.AssertionFailedError: Property error detected:
Seed = 3695691971125975155
Examples = 2
Pure = false
Error: property test did not complete within PT1M
Values:

	at accord.utils.Property$Common.checkWithTimeout(Property.java:115)
	at accord.utils.Property$SingleBuilder.check(Property.java:223)
	at accord.utils.Property$ForBuilder.check(Property.java:124)
	at org.apache.cassandra.repair.ConcurrentIrWithPreviewFuzzTest.concurrentIrWithPreview(ConcurrentIrWithPreviewFuzzTest.java:46)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
{code}
Flakiness is around 6%. The CircleCI runs above have been generated with:
{code}
.circleci/generate.sh -p -s \
  -e REPEATED_UTESTS=org.apache.cassandra.repair.ConcurrentIrWithPreviewFuzzTest \
  -e REPEATED_UTESTS_COUNT=500
{code}
Bug: InstanceClassLoader leak in 5.0/trunk
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 12/Sep/23 14:55
Resolved: 15/Sep/23 20:17

Something in the 5.0/trunk branches has caused an in-jvm dtest InstanceClassLoader leak - it appears to have something to do with the Mutual TLS Authenticator (f078c02cb58bddd735490b07548f7352f0eb09aa) but nothing in that commit, so far, has stood out as causing issues.

The culprit class appears to be {{io.netty.util.internal.InternalThreadLocalMap}}, which seems to no be removed when the threads stops for some reason.
Bug: Test failure: dtest.secondary_indexes_test.TestPreJoinCallback.test_resume
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 13/Sep/23 20:38
Resolved: 16/Oct/23 11:04

Since recently, it fails regularly on 4.1, 5.0, and trunk: 
{code:java}
Error Message
failed on teardown with "Failed: Unexpected error found in node logs (see stdout for full details). Errors: [[node2] 'ERROR [Stream-Deserializer-/127.0.0.1:7000-6e2ae2f5] 2023-09-13 12:41:02,461 StreamSession.java:700 - [Stream #cc2010c0-5232-11ee-bc8b-4945091d03ae] Socket closed before session completion, peer 127.0.0.1:7000 is probably down.\njava.nio.channels.ClosedChannelException: null\n\tat org.apache.cassandra.net.AsyncStreamingInputPlus.reBuffer(AsyncStreamingInputPlus.java:119)\n\tat org.apache.cassandra.io.util.RebufferingInputStream.readByte(RebufferingInputStream.java:178)\n\tat org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:49)\n\tat org.apache.cassandra.streaming.StreamDeserializingTask.run(StreamDeserializingTask.java:59)\n\tat io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)\n\tat java.base/java.lang.Thread.run(Thread.java:829)']"

Stacktrace
Unexpected error found in node logs (see stdout for full details). Errors: [[node2] 'ERROR [Stream-Deserializer-/127.0.0.1:7000-6e2ae2f5] 2023-09-13 12:41:02,461 StreamSession.java:700 - [Stream #cc2010c0-5232-11ee-bc8b-4945091d03ae] Socket closed before session completion, peer 127.0.0.1:7000 is probably down.\njava.nio.channels.ClosedChannelException: null\n\tat org.apache.cassandra.net.AsyncStreamingInputPlus.reBuffer(AsyncStreamingInputPlus.java:119)\n\tat org.apache.cassandra.io.util.RebufferingInputStream.readByte(RebufferingInputStream.java:178)\n\tat org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:49)\n\tat org.apache.cassandra.streaming.StreamDeserializingTask.run(StreamDeserializingTask.java:59)\n\tat io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)\n\tat java.base/java.lang.Thread.run(Thread.java:829)']
{code}
Bug: Internode legacy SSL storage port certificate is not hot reloaded on update
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 21/Jul/23 20:15
Resolved: 25/Sep/23 20:45

In CASSANDRA-16666 the SSLContext cache was changed to clear individual {{EncryptionOptions}} from the SslContext cache if they needed reloading to reduce resource consumption. Before the change if ANY cert needed hot reloading, the SSLContext cache would be cleared for ALL certs.

If the legacy SSL storage port is configured, a new {{EncryptionOptions}} object is created in {{org.apache.cassandra.net.InboundSockets#addBindings}} just for binding the socket, but never gets cleared as the change in port means it no longer matches the configuration retrieved from {{DatabaseDescriptor}} in {{org.apache.cassandra.net.MessagingServiceMBeanImpl#reloadSslCertificates}}.

This is unlikely to be an issue in practice as the legacy SSL internode socket is only used in mixed version clusters with pre-4.0 nodes, so the cert only needs to stay valid until all nodes upgrade to 4.x or above.

One way to avoid this class of failures is to just check the entries present in the SSLContext cache.
Bug: DDM's mask_default function should support vectors
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 27/Sep/23 20:52
Resolved: 10/Oct/23 14:10

DDM uses the CQL function {{mask_default}} as the default masking function. This function supports all CQL data types except for {{vector}}, which didn't exist when DDM was added. 

We should make {{mask_default}} (and thereof default masking) work with vector columns.
Bug: Add support for repair coordinator to retry messages that timeout
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 01/Sep/23 18:44
Resolved: 27/Sep/23 23:23

Now that CASSANDRA-15399 is in, most of the repair messages have a state that they can check against to make message delivery idempotent, allowing the coordinator to retry such messages; a few of the most critical messages to retry are: PREPARE_MSG, VALIDATION_REQ, VALIDATION_RSP, SYNC_REQ, and SYNC_RSP.

With this I propose making the coordinator able to retry these key messages to try and make repair more resilient to ephemeral issues.
Bug: Distributed tests can return ordering columns that have not been selected
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 28/Sep/23 15:46
Resolved: 30/Oct/23 13:19

The following test fails
{code:java}
@Test
public void incorrectClusteringColumnTest() throws IOException
{
    try (Cluster cluster = init(Cluster.build(1).start()))
    {
        cluster.schemaChange(withKeyspace("CREATE TABLE %s.t (k int, c int, v int, primary key(k, c))"));

        cluster.coordinator(1).execute(withKeyspace("INSERT INTO %s.t (k, c, v) VALUES (0, 1, 2)"), ConsistencyLevel.QUORUM);

        String query = withKeyspace("SELECT v FROM %s.t WHERE k IN (0, 1) ORDER BY c LIMIT 10");
        assertRows(cluster.coordinator(1).execute(query, ConsistencyLevel.ONE), row(2));
    }
}
 {code}
The query is returning the clustering column c as well as the regular column v.

The reason for the extra column being returned is that the RowUtil is using ResultMessage.Rows.result.metadata.names instead on ResultMessage.Rows.result.metadata.requestNames(). This last method removes columns that have not been requested.
Bug: Remove libraries in lib/sigar-bin for unsupported architectures
Status: Resolved
Priority: Normal
Resolution: Won't Do
Created: 17/Aug/23 13:46
Resolved: 23/Oct/23 06:14

{code}
✔ ~/dev/cassandra/cassandra-instaclustr/cassandra [trunk L|⚑ 49] 
15:41 $ ls -la lib/sigar-bin/
total 6376
drwxrwxr-x 2 fermat fermat   4096 aug 17 11:26 .
drwxrwxr-x 5 fermat fermat  12288 aug 17 11:28 ..
-rw-rw-r-- 1 fermat fermat 210641 aug 17 11:26 libsigar-amd64-freebsd-6.so
-rw-rw-r-- 1 fermat fermat 246605 aug 17 11:26 libsigar-amd64-linux.so
-rw-rw-r-- 1 fermat fermat 251360 aug 17 11:26 libsigar-amd64-solaris.so
-rw-rw-r-- 1 fermat fermat 577452 aug 17 11:26 libsigar-ia64-hpux-11.sl
-rw-rw-r-- 1 fermat fermat 494929 aug 17 11:26 libsigar-ia64-linux.so
-rw-rw-r-- 1 fermat fermat 516096 aug 17 11:26 libsigar-pa-hpux-11.sl
-rw-rw-r-- 1 fermat fermat 425077 aug 17 11:26 libsigar-ppc64-aix-5.so
-rw-rw-r-- 1 fermat fermat 310792 aug 17 11:26 libsigar-ppc64le-linux.so
-rw-rw-r-- 1 fermat fermat 330767 aug 17 11:26 libsigar-ppc64-linux.so
-rw-rw-r-- 1 fermat fermat 400925 aug 17 11:26 libsigar-ppc-aix-5.so
-rw-rw-r-- 1 fermat fermat 258547 aug 17 11:26 libsigar-ppc-linux.so
-rw-rw-r-- 1 fermat fermat 269932 aug 17 11:26 libsigar-s390x-linux.so
-rw-rw-r-- 1 fermat fermat 261896 aug 17 11:26 libsigar-sparc64-solaris.so
-rw-rw-r-- 1 fermat fermat 285004 aug 17 11:26 libsigar-sparc-solaris.so
-rw-rw-r-- 1 fermat fermat 397440 aug 17 11:26 libsigar-universal64-macosx.dylib
-rw-rw-r-- 1 fermat fermat 377668 aug 17 11:26 libsigar-universal-macosx.dylib
-rw-rw-r-- 1 fermat fermat 179751 aug 17 11:26 libsigar-x86-freebsd-5.so
-rw-rw-r-- 1 fermat fermat 179379 aug 17 11:26 libsigar-x86-freebsd-6.so
-rw-rw-r-- 1 fermat fermat 233385 aug 17 11:26 libsigar-x86-linux.so
-rw-rw-r-- 1 fermat fermat 242880 aug 17 11:26 libsigar-x86-solaris.so
✔ ~/dev/cassandra/cassandra-instaclustr/cassandra [trunk L|⚑ 49] 
15:43 $ du -shc lib/sigar-bin/
6,3M    lib/sigar-bin/
6,3M    total
{code}

I think we could definitely improve this. We basically need just x86-linux, amd64-linux and two libs for macosx.

We could save like 5M from the final tarball size. From 75M down to 70M is not bad!

Or maybe I am not getting something and we need this?
Bug: Replace CRC32 w/ CRC32C in IndexFileUtils.ChecksummingWriter
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 11/Sep/23 19:50
Resolved: 20/Oct/23 19:56

It seems that now we're on Java 11 for 5.0, there isn't much reason not to use CRC32C as a drop-in replacement for CRC32. SAI isn't even released, so has no binary compatibility entanglements, and this should be pretty straightforward.

See https://github.com/apache/bookkeeper/pull/3309
Bug: Test failure: org.apache.cassandra.tools.nodetool.ForceCompactionTest.forceCompactMultipleRowsTombstoneTest-.jdk11 
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 25/Sep/23 13:42
Resolved: 16/Oct/23 10:28

[https://ci-cassandra.apache.org/job/Cassandra-trunk/1718/testReport/org.apache.cassandra.tools.nodetool/ForceCompactionTest/forceCompactMultipleRowsTombstoneTest__jdk11/]
h3.  
{code:java}
Stacktrace
junit.framework.AssertionFailedError at org.apache.cassandra.tools.nodetool.ForceCompactionTest.verifyNotContainsTombstones(ForceCompactionTest.java:251) at org.apache.cassandra.tools.nodetool.ForceCompactionTest.forceCompactMultipleRowsTombstoneTest(ForceCompactionTest.java:129) 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: ConnectionBurnTest fails with NullPointerException
Status: Patch Available
Priority: Normal
Created: 19/Aug/23 17:26

The ConnectionBurnTest is used to check the throughput of outgoing and incoming connections and report the results of execution to the log. During the test run, I noticed a couple of errors that actually prevent us from getting any results.
 # The {{NullPointerException}} is thrown during the test execution
{code:java}
java.lang.NullPointerException: null
	at org.apache.cassandra.metrics.ClientMetrics.unpauseConnection(ClientMetrics.java:69)
	at org.apache.cassandra.net.AbstractMessageHandler.onReserveCapacityRegained(AbstractMessageHandler.java:314)
	at org.apache.cassandra.net.AbstractMessageHandler.onGlobalReserveCapacityRegained(AbstractMessageHandler.java:289)
	at org.apache.cassandra.net.AbstractMessageHandler$WaitQueue$Ticket.reactivateHandler(AbstractMessageHandler.java:792)
	at org.apache.cassandra.net.AbstractMessageHandler$WaitQueue$ReactivateHandlers.run(AbstractMessageHandler.java:740)
{code}
 # The exception is swallowed and the test exits almost immediately, but the exception itself is not rethrown and the exit code is zero. The test is always green on CI, but a fatal exception has occurred;
Bug: Test failure: org.apache.cassandra.db.compaction.LongCompactionsTest 
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 26/Sep/23 18:33
Resolved: 28/Sep/23 06:05

org.apache.cassandra.db.compaction.LongCompactionsTest in "long" tests is broken. This seems to be a regression after CASSANDRA-18737

If I checkout the code one merge before (CASSANDRA-18871), these tests do not fail there.
Bug: The vector data type shouldn't support empty value
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 22/Sep/23 12:59
Resolved: 04/Oct/23 16:42

As discussed on [the mail list|https://lists.apache.org/thread/qq0jkm6rlkd2slfmhgz7om14tbpys891], the vector data type shouldn't allow empty values.
Bug: Drop commitlog chain marker updates
Status: Triage Needed
Priority: Normal
Created: 29/Sep/23 12:57

CASSANDRA-13987 added a periodic update of the last commit log chain marker in order to allow for data in memory-mapped segments to be recovered even if it was not part of a synced segment.

A much simpler way to do this is something in the vein of CASSANDRA-16482, i.e. ignoring an empty sync marker for the last entry in the commit log. We could do this by default if the commit log is uncompressed (and possibly only if using memory mapping after CASSANDRA-18464).
Bug: JMH benchmark improvements
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 20/Sep/23 09:32
Resolved: 25/Sep/23 10:56

1. CASSANDRA-12586  introduced {{build-jmh}} task which builds uber jar for JMH benchmarks which is then not used with {{ant microbench}} task. It is used though by the {{test/bin/jmh}} script. 

In fact, I have no idea why we should use uber jar if JMH can perfectly run with a regular classpath. Maybe that had something to do with older JMH version which was used that time. Building uber jars takes time and is annoying. Since it seems to be redundant anyway, I'm going to remove it and fix {{test/bin/jmh}} to use a regular classpath. 

2. I'll add support for async profiler in benchmarks. That is, the {{microbench}} target automatically fetches the async profiler binaries and adds the necessary args for JMH ({{-prof asyc...}} in particular) whenever we run {{microbench-with-profiler}} task. If no additional properties are provided some default options will be applied (defined in the script, can be negotiated). Otherwise, whatever is passed to the {{profiler.opts}} property will be added as profiler options after library path and target directory definition.

3. If someone wants to see any additional improvements, please comment on the ticket.
Bug: Fix broken JMH benchmarks
Status: Triage Needed
Priority: Normal
Created: 21/Sep/23 17:29

The following benchmarks are broken:
* {{ZeroCopyStreamingBench}}
* {{MutationBench}}
* {{FastThreadLocalBench}}
* {{AtomicBTreePartitionUpdateBench}} (OOM on Jenkins)
* {{ReadSmallPartitionsBench}} (assertion error)
* {{ReadWidePartitionsBench}} (assertion error)
* {{BloomFilterSerializerBench}} (NPE)
* {{KeyLookupBench}} (IAE)

Additionally, those benchmarks take too much time to run:
* {{BTreeUpdateBench}} ~ 58 hours
* {{AtomicBTreePartitionUpdateBench}} ~ 5 hours
* {{BTreeTransformBench}} ~ 2.5 hours

Here the complete list of estimated benchmark times:
{noformat}
Estimated time for CacheLoaderBench: ~5 s
Estimated time for LatencyTrackingBench: ~26 s
Estimated time for SampleBench: ~30 s
Estimated time for ReadWriteBench: ~30 s
Estimated time for MutationBench: ~30 s
Estimated time for CompactionBench: ~35 s
Estimated time for DiagnosticEventPersistenceBench: ~40 s
Estimated time for ZeroCopyStreamingBench: ~44 s
Estimated time for BatchStatementBench: ~110 s
Estimated time for DiagnosticEventServiceBench: ~120 s
Estimated time for MessageOutBench: ~144 s
Estimated time for BloomFilterSerializerBench: ~144 s
Estimated time for FastThreadLocalBench: ~156 s
Estimated time for HashingBench: ~156 s
Estimated time for ChecksumBench: ~208 s
Estimated time for StreamingTombstoneHistogramBuilderBench: ~208 s
Estimated time for PendingRangesBench: ~ 5 m
Estimated time for DirectorySizerBench: ~ 5 m
Estimated time for instance.ReadSmallPartitionsBench: ~ 5 m
Estimated time for PreaggregatedByteBufsBench: ~ 7 m
Estimated time for AutoBoxingBench: ~ 8 m
Estimated time for OutputStreamBench: ~ 13 m
Estimated time for BTreeBuildBench: ~ 13 m
Estimated time for StringsEncodeBench: ~ 20 m
Estimated time for instance.ReadWidePartitionsBench: ~ 21 m
Estimated time for btree.BTreeBuildBench: ~ 30 m
Estimated time for BTreeSearchIteratorBench: ~ 31 m
Estimated time for btree.BTreeTransformBench: ~ 138 m
Estimated time for btree.AtomicBTreePartitionUpdateBench: ~ 288 m
Estimated time for btree.BTreeUpdateBench: ~58 h
Total estimated time: ~69 h
{noformat}

I'd like to add a test which estimates the benchmark times and fails if a single benchmark estimated run time is longer than xxx minutes.
Bug: Invalid unit test check for CreateTableValidationTest
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 20/Sep/23 03:37
Resolved: 21/Sep/23 13:54

https://github.com/apache/cassandra/blob/trunk/test/unit/org/apache/cassandra/schema/CreateTableValidationTest.java#L40
This test case testInvalidBloomFilterFPRatio()  makes no sense and cannot achieve the desired purpose.
Bug: Document multiple GRANT or REVOKE permissions in a single statement
Status: Triage Needed
Priority: Normal
Created: 19/Sep/23 19:13

Update https://cassandra.apache.org/doc/4.1/cassandra/cql/security.html to include the new DCL added by CASSANDRA-17027.

{code:sql}
GRANT MODIFY, SELECT ON KEYSPACE field TO manager;
{code}
Bug: Document GROUP BY time interval feature
Status: Triage Needed
Priority: Normal
Created: 19/Sep/23 18:40

It looks like the aggregation by time range feature added by CASSANDRA-11871 was not added to the documentation.

Example:
{code:sql}
SELECT pk, date, floor(time, 5m), min(v), max(v), count(v) FROM table GROUP BY pk, date, floor(time, 5m)
{code}