av9ash/GitBugs huggingface dataset:
Bug: Unified Compaction Strategy is creating too many sstables
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 20/Oct/23 12:21
Resolved: 14/Nov/23 20:54

The unified compaction strategy currently aims to create sstables with close to the same size, defaulting to 1 GiB. Unfortunately tests show that Cassandra starts to have performance problems when the number of sstables grows to the order of a thousand, and in particular that even 1 TiB of data with the default configuration is creating too many sstables for efficient processing. This matters even more for SAI, where the number of sstables in the system can have a proportional effect on the complexity of operations.

It is quite easy to create a configuration option that allows sstables to take some part of the data growth by adding a multiplier to [the shard count calculation|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/compaction/UnifiedCompactionStrategy.md#sharding] formula, replacing 
{{2 ^ round(log2(d / (t * b))) * b}} 
with 
{{2 ^ round((1 - 𝜆) * log2(d / (t * b))) * b}}, 
where 𝜆 is a parameter whose value is between 0 and 1.

With this, a 𝜆 of 0.5 would mean that shard count and sstable size grow in parallel at the square root of the data size growth. 0 would result in no growth, and 1 in always using the same number of shards.

It may also be valuable to introduce a threshold for engaging the base shard count to avoid splitting lowest-level sstables into fragments that are too small.

Once both of these are in place, we can set defaults that better suit all node densities, including 10 TiB and beyond, for example:
 - target size of 1 GiB
 - 𝜆 of 1/3
 - base shard count of 4
 - minimum size 100 MiB
Bug: Upgrade Python driver to 3.28.0
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 25/Oct/23 11:37
Resolved: 02/Nov/23 17:17

The version of the Python driver that is used by cqlsh (3.25.0) doesn't entirely support the new vector data type introduced by CASSANDRA-18504. While we can perfectly write data, read vectors are presented as blobs:
{code}
> CREATE TABLE t (k int PRIMARY KEY, v vector<int, 2>);
> INSERT INTO t(k, v) VALUES (0, [1, 2]);
> SELECT * FROM t;

 k | v
---+-------------------------------------
 0 | b'\x00\x00\x00\x01\x00\x00\x00\x02'
{code}
I think that would we fixed if we update the driver to (at least) 3.28.0, which includes support for the new vector data type.
Bug: cqlsh should allow failure to import cqlshlib.serverversion
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 13/Nov/23 14:53
Resolved: 13/Nov/23 20:20

cqlshlib.serverversion is created by ant, recording the server's version so that python can see if it matches cqlsh later.  This can make work for other things that need to be aware of it like CASSANDRA-18594, so we should relax it a bit since this really has no value outside of warning humans they have a mismatch.
Bug: Incremental repair never cleans up completed sessions from CoordinatorSessions.sessions
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 03/Oct/23 20:11
Resolved: 13/Nov/23 14:45

Currently, there is nothing cleaning up repaired sessions from org.apache.cassandra.repair.consistent.CoordinatorSessions#sessions. This causes memory to leak for cluster members with long uptimes and lots of incremental repair.
Bug: Remove sstable format 'nc' and make 5.0 'nb' and 'oa'
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 08/Nov/23 08:27
Resolved: 13/Nov/23 08:31

CASSANDRA-18933 found out 4.1 sstables are 'nb' and not 'nc' as incorrectly noted in the code. Hence 5.0 should use 'nb' in compatibility mode and 'oa' out of it. This leaves 'nc' only to be removed.
Bug: DESC TYPE forgets to quote UDT's field names
Status: Resolved
Priority: Normal
Resolution: Duplicate
Created: 12/Nov/23 17:40
Resolved: 12/Nov/23 20:59

If I create a type with

*CREATE TYPE "Quoted_KS"."udt_@@@" (a int, "field_!!!" text)*

and then run DESC TYPE "Quoted_KS"."udt_@@@" I get:

*CREATE TYPE "Quoted_KS"."udt_@@@" (a int, field_!!! text)*

Note the missing quotes around the non-alphanumeric field name, which does need quoting. If I'll try to run this command, it won't work.

Tested on Cassandra 4.1.
Bug: Add retries to IR messages
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 25/Oct/23 17:37
Resolved: 01/Nov/23 22:18

With CASSANDRA-18816 we now have repair message retries for full and preview repair, but IR was left out as message processing was handled differently, this patch is to extend that work to include IR messages!

Out of scope of this patch was making the status checks deal with retries as we retry anyways every hour or so…
Bug: StartupClusterConnectivityChecker fails on upgrade from 3.X
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 27/Oct/23 16:46
Resolved: 10/Nov/23 10:35

Starting up a new 4.X node on a 3.x cluster throws the following warning:

{noformat}
WARN  [main] 2023-10-27 15:58:22,234 StartupClusterConnectivityChecker.java:183 - Timed out after 10002 milliseconds, was waiting for remaining peers to connect: {dc1=[X.Y.Z.W, A.B.C.D]}
{noformat}

I think this is because the PING messages used by the startup check are not available on 3.X.

To provide a smoother upgrade experience we should probably disable this check on a mixed version clusters, or skip peers on versions < 4.x when doing the connectivity check.
Bug: Harry-found silent data loss issue
Status: Resolved
Priority: Normal
Resolution: Duplicate
Created: 02/Nov/23 08:02
Resolved: 09/Nov/23 15:44

Harry has discovered a silent data loss bug in trunk, but it goes all the way back to early 5.0.

Some rows are not visble after flush. Compared Harry repro running a memtable instead of a regular Harry model, and it still reproduces (in other words, it is almost certainly not a Harry issue).

Simple schema, and only one flush is required for repro, so not an unlikely bug. Max partition size is 1k rows, so not an unlikely setup here, either. No concurrency involved; reproduces stably. Good chance this is related to the fact the schema has DESC clusterings.

I am working on posting a Harry branch that stably reproduces it.
Bug: Improve documentation about cloud-based snitches
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 03/Nov/23 11:10
Resolved: 03/Nov/23 11:38

There were various improvements and refactorings of cloud-based snitches and snitches in general in CASSANDRA-18646 CASSANDRA-18438 or CASSANDRA-16555.

We should reflect new features and add new snitches in the documentation.
Bug: Performance issues after Cassandra upgrade
Status: Resolved
Priority: Normal
Resolution: Invalid
Created: 09/Nov/23 11:53
Resolved: 09/Nov/23 11:57

I would like to ask for your help in the following issue.
 
We have upgraded our Cassandra 3.11.4 to 4.1.2 in production environment and since that we're facing with many performance issues:
 * The cluster operations lowered to 17-20k/s which was between 21-25k/s with 3.11.4
 * CPU usage significantly increased -> previously it was nearly 50% at peak times, after the update it's between 65-70%
 * Pending tasks increased -> from nearly 0 to 30 at peak times
 * Native Transport Requests significantly increased -> from 100-200 to 2K-3K at peak times
 * Chunck cache hit rate metric stopped working
 * Read latency increased from microsecs to milisecs
 * sstables per read histogram also shows increased values

We have already done with:
 * file_cache_enabled has been enabled
 * sstableupgrade
 * Java has been updated from 8 to 11
 * Made a truncate of affected keyspace
 * Affected keyspace's indexes has been rebuilt

Our infrastructure contains 2 DCs with 24 nodes/dc. Every node has 8 CPUs and 64GBs of RAM and running on RHEL 8.6.

We have already compared the two versions but didn't notice any new feature or option which could cause this performance degradation. If do you have any idea or do you need any kind of logs don't hesitate to contact me.
Bug: Correct comment for nc SSTable format
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 17/Oct/23 16:53
Resolved: 19/Oct/23 17:30

In [CASSANDRA-18134 |https://issues.apache.org/jira/browse/CASSANDRA-18134], the {{nc}} SSTable format was introduced. The patch was merged into {{5.0+}}, however the comment in source incorrectly mentions that the format was added to version {{4.1}}.
Bug: DROPing a non-existant function with parameter types results in bizarre error
Status: Triage Needed
Priority: Normal
Created: 07/Nov/23 16:19

When attempting a command like

{{DROP FUNCTION ks.fun(int)}}

Where the keyspace "ks" exists, but "fun" doesn't - and note also an attempt to choose which of several (non-existent) overloads to remove - one gets a bizarre error from Cassandra - instead of InvalidRequest (or maybe ConfigurationException), we get a SyntaxError, with the strange message "NoSuchElementException No value present". Neither the SyntaxError type nor this specific message makes much sense. This is not a syntax error, and the same request would have worked if this specific function existed.
Bug: DROPing an overloaded UDF produces the wrong error message if drop permissions are lacking
Status: Triage Needed
Priority: Normal
Created: 07/Nov/23 15:58

When a user creates two user-defined functions with the same name but different parameters, to later remove these functions with DROP FUNCTION, the user must disambiguate which one to delete. For example, "DROP FUNCTION ks.fun(int, int)". If the user tries just "DROP FUNCTION ks.fun", Cassandra will return an InvalidRequest, complaining about "multiple functions" with the same name. So far so good.

Now, if the user has (via GRANT) permissions to drop only one of these functions and no permissions to drop the second, trying to do "DROP FUNCTION ks.fun" should still return the good old InvalidRequest, because the request is still just as ambiguous as it was when permissions weren't involved. But, Cassandra instead notices that one of the variants, e.g., ks.fun(int, int), doesn't have drop permissions, and returns an Unauthorized error (instead of InvalidRequest), saying that "ks.fun(int, int)" doesn't have drop permissions. This is true - but irrelevant - the user didn't ask to drop that specific overload of the function. Moreover, it's misleading because it can lead the user to GRANT these supposedly-missing permissions, but after granting them, the DROP FUNCTION command still won't work, because it will still be ambiguous.

This is a minor error-path bug, but I noticed it while trying to exhaustively look how permissions and functions interact in Cassandra.
Bug: Test failure: dtest-novnode.sslnodetonode_test.TestNodeToNodeSSLEncryption.test_ssl_client_auth_required_fail 
Status: Open
Priority: Normal
Created: 14/Oct/23 19:40

Seen on trunk:
[https://ci-cassandra.apache.org/job/Cassandra-trunk/1744/testReport/dtest-novnode.sslnodetonode_test/TestNodeToNodeSSLEncryption/test_ssl_client_auth_required_fail/]
{code:java}
Error Message
assert False

Stacktrace
self = <sslnodetonode_test.TestNodeToNodeSSLEncryption object at 0x7f45f37786d0> def test_ssl_client_auth_required_fail(self): """peers need to perform mutual auth (cient auth required), but do not supply the local cert""" credNode1 = sslkeygen.generate_credentials("127.0.0.1") credNode2 = sslkeygen.generate_credentials("127.0.0.2") self.setup_nodes(credNode1, credNode2, client_auth=True) self.fixture_dtest_setup.allow_log_errors = True self.cluster.start(no_wait=True) time.sleep(2) found = self._grep_msg(self.node1, _LOG_ERR_HANDSHAKE, _LOG_ERR_GENERAL) > assert found E assert False sslnodetonode_test.py:83: AssertionError
{code}
Bug: Test failure: dtest.sslnodetonode_test.TestNodeToNodeSSLEncryption.test_ca_mismatch
Status: Open
Priority: Normal
Created: 20/Oct/23 18:11

Seen here:

[https://ci-cassandra.apache.org/job/Cassandra-trunk/1746/testReport/dtest.sslnodetonode_test/TestNodeToNodeSSLEncryption/test_ca_mismatch/]

 
{code:java}
self = <sslnodetonode_test.TestNodeToNodeSSLEncryption object at 0x7f45da997710> def test_ca_mismatch(self): """CA mismatch should cause nodes to fail to connect""" credNode1 = sslkeygen.generate_credentials("127.0.0.1") credNode2 = sslkeygen.generate_credentials("127.0.0.2") # mismatching CA! self.setup_nodes(credNode1, credNode2) self.fixture_dtest_setup.allow_log_errors = True self.cluster.start(no_wait=True) found = self._grep_msg(self.node1, _LOG_ERR_HANDSHAKE) self.cluster.stop() > assert found E assert False sslnodetonode_test.py:115: AssertionError{code}
Bug: Accord: UX: Force transactions / automatic transactions
Status: Open
Priority: Normal
Created: 31/Oct/23 20:29

Note: I chose  "bug" because I think this is a serious UX issue we should consider. But strictly speaking this is a UX issue and technically the implementation is working as designed. The UX conclusion rather is that the desing needs improvement...

I'm submitting this based on observing [~antithesis-luis] creating a checker with some accord transactions. A discussion that followed his experience is here https://the-asf.slack.com/archives/C0459N9R5C6/p1698352614742079

The tl;dr is that users are likely to expect single SELECT queries, and maybe even single UPDATE/INSERT to be consistent even if they neglect the BEGIN...COMMIT around the single statement.

My proposed fix for improved UX is an ability to force or default also single statements to be wrapper in an accord transaction.

There are two ways to implement this: 

1. Add configuration option to reject queries that are not accord transactions. This could be a per table or per keyspace option.
2. A per session setting that enables automatic transactions, combined with a global setting to have this behavior as default. MySQL's AUTOCOMMIT is an example of this approach.

My preference is #2.
Bug: TableHistograms output a lot of repeated information
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 24/Oct/23 10:30
Resolved: 25/Oct/23 06:45

This patch aims to fix two issues:

1. the original output of nodetool tablehistograms with no tables specified is wrong , the output will contains many repeated informations. See the picture below.

The reason is that for [tablesList.keys()|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/tools/nodetool/TableHistograms.java#L80] will give a Multiset output as tablesList is a Multimap.  

2. as we have DISCUSS for "Change the useage of nodetool tablehistograms" , for arguments more than two, the output of tablehistograms will be all of the tables, it's a bug that we should fix. We can see that the [description|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/tools/nodetool/TableHistograms.java#L42] of tablehistograms is ,out put the statistic histograms for the given table. and the format of the argument is like [tthis|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/tools/nodetool/TableHistograms.java#L45]
Bug: Remove unnecessary reporter-config3 dependency
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 04/Oct/23 15:05
Resolved: 10/Oct/23 06:34

After the CASSANDRA-14667 the dwopwizard metrics library was updated to the latest version, metrics reporters e.g. ConsoleReporter or CsvReporter that were shipped with the {{reporter-config3}} are no longer needed as they are part of the dropwizard itself. 

The project has been archived since the 2020 year and is no longer supported.
https://github.com/addthis/metrics-reporter-config

I think we can remove the following:
{code}
      <dependency>
        <groupId>com.addthis.metrics</groupId>
        <artifactId>reporter-config3</artifactId>
        <version>3.0.3</version>
        <exclusions>
          <exclusion>
            <artifactId>hibernate-validator</artifactId>
            <groupId>org.hibernate</groupId>
          </exclusion>
        </exclusions>
      </dependency>
{code}
Bug: http/2 vulnerability: CVE-2023-44487
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 19/Oct/23 11:02
Resolved: 26/Oct/23 11:09

https://nvd.nist.gov/vuln/detail/CVE-2023-44487

Basically anything using http/2 is covered by this, but we don't use it.
Bug: [WEBSITE] Update the Metric Reporters documentation page 
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 04/Oct/23 15:52
Resolved: 12/Oct/23 06:42

After CASSANDRA-18743 and CASSANDRA-14667 we need to update the website (documentation) information accordingly. The links to dropwizard metrics must be updated. The references to the metrics reporters should be added to the following page:
[https://cassandra.apache.org/doc/latest/cassandra/operating/metrics.html#metric-reporters]
Bug: Vector type in UDTs can break schema loading 
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 26/Oct/23 13:26
Resolved: 26/Oct/23 16:48

{{RawVector}} doesn’t override {{referencesUserType(String name)}}, which causes {{Types.RawBuilder.build()}} to not populate UDT dependency DAG correctly. Then depending on natural iteration order or the vertices map,  a UDT with a vector referencing another UDT can fail to resolve, if that referenced UDT has not been resolved.
Bug: IllegalArgumentException "tuple is null" thrown for illegal syntax in cql transaction block
Status: Open
Priority: Normal
Created: 26/Oct/23 17:51

*System configuration and information:*

Single node Cassandra with Accord transactions enabled running on docker

Built from commit: [a7cd114435704b988c81f47ef53d0bfd6441f38b|https://github.com/apache/cassandra/commit/a7cd114435704b988c81f47ef53d0bfd6441f38b]

CQLSH: [cqlsh 6.2.0 | Cassandra 5.0-alpha2-SNAPSHOT | CQL spec 3.4.7 | Native protocol v5]

 

*Steps to reproduce in CQLSH:*
{code:java}
CREATE KEYSPACE accord WITH replication = {'class': 'SimpleStrategy', 'replication_factor': '1'}  AND durable_writes = true;{code}
{code:java}
CREATE TABLE accord.accounts (
    partition_key text,
    account_id int,
    balance int,
    PRIMARY KEY (partition_key, account_id)
) WITH CLUSTERING ORDER BY (account_id ASC){code}
{code:java}
INSERT INTO accord.accounts (partition_key, account_id, balance) VALUES ('default', 1, 1000);{code}
bug happens after executing the following statement:

After assigning a variable within the transaction block, we are attempting to perform arithmetic operations in the next SELECT statement. Without the arithmetic operation, the SELECT statement is valid. Instead of reporting an IllegalArgumentException, CQL should probably just report invalid syntax.
{code:java}
BEGIN TRANSACTION LET row = (SELECT * FROM accord.accounts WHERE partition_key = 'default' AND account_id = 1); SELECT (row.balance + 50); COMMIT TRANSACTION;{code}
 

Bug / Error:
======================================================================
{color:#de350b}SyntaxException: Failed parsing statement: [BEGIN TRANSACTION LET row = (SELECT * FROM accord.accounts WHERE partition_key = 'default' AND account_id = 1); SELECT (row.balance + 50); COMMIT TRANSACTION;] reason: IllegalArgumentException tuple is null{color}

 

{color:#172b4d}This was found while testing Accord transactions with [~henrik.ingo] and team.{color}
Bug: SHA1 keys prevent installation on RHEL 9
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 31/Oct/23 13:53
Resolved: 31/Oct/23 15:46

Due to the presence of SHA1 keys they have to be explicitly allowed before C* can be installed on RHEL 9-based systems: 

{quote}
Importing GPG key 0xF2833C93:
 Userid     : "Eric Evans <eevans@sym-link.com>"
 Fingerprint: CEC8 6BB4 A0BA 9D0F 9039 7CAE F835 8FA2 F283 3C93
 From       : https://downloads.apache.org/cassandra/KEYS
Is this ok [y/N]: y
Key imported successfully
Importing GPG key 0x8D77295D:
 Userid     : "Eric Evans <eevans@sym-link.com>"
 Fingerprint: C496 5EE9 E301 5D19 2CCC F2B6 F758 CE31 8D77 295D
 From       : https://downloads.apache.org/cassandra/KEYS
Is this ok [y/N]: y
Key imported successfully
Importing GPG key 0x2B5C1B00:
 Userid     : "Sylvain Lebresne (pcmanus) <sylvain@datastax.com>"
 Fingerprint: 5AED 1BF3 78E9 A19D ADE1 BCB3 4BD7 36A8 2B5C 1B00
 From       : https://downloads.apache.org/cassandra/KEYS
Is this ok [y/N]: y
warning: Signature not supported. Hash algorithm SHA1 not available.
Key import failed (code 2). Failing package is: cassandra-4.0.11-1.noarch
 GPG Keys are configured as: https://downloads.apache.org/cassandra/KEYS
The downloaded packages were saved in cache until the next successful transaction.
You can remove cached packages by executing 'yum clean packages'.
Error: GPG check FAILED
{quote}

This can be worked around by allowing SHA1:

{quote}
update-crypto-policies --set DEFAULT:SHA1
{quote}

https://www.redhat.com/en/blog/rhel-security-sha-1-package-signatures-distrusted-rhel-9
Bug: Repository repodata file does not contain all versions.
Status: Resolved
Priority: Normal
Resolution: Not A Problem
Created: 31/Oct/23 11:43
Resolved: 31/Oct/23 14:08

The repomd.xml files inside the noboolean/repodata/ folders are only pointing to the latest version rpms, this way we are unable to install using yum from previous versions for Centos7.

The repomd.xml of the main repository is the only one that has all the RPM packages, but in such a way that it is impossible to differentiate versions for CentOS8 and CentOS7.
{code:java}

vi /etc/yum.repos.d/cassandra.repo
[cassandra]
name=Apache Cassandra
baseurl=https://redhat.cassandra.apache.org/40x/noboolean/
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://downloads.apache.org/cassandra/KEYS

 {code}
{code:java}
# yum list --showduplicate cassandra\*
Loaded plugins: fastestmirror, ovl
Loading mirror speeds from cached hostfile
 * base: mirrors.up.pt
 * extras: mirrors.up.pt
 * updates: mirrors.up.pt
Available Packages
cassandra.noarch                                          4.0.11-1                       cassandra
cassandra-tools.noarch                                    4.0.11-1                       cassandra
 {code}
If I try one of the old versions:
{code:java}
# yum install cassandra-4.0.5-1
Loaded plugins: fastestmirror, ovl
Loading mirror speeds from cached hostfile
 * base: mirrors.up.pt
 * extras: mirrors.up.pt
 * updates: mirrors.up.pt
No package cassandra-4.0.5-1 available.
Error: Nothing to do
 {code}
 
Changing to main 40x repo folder:
{code:java}
vi /etc/yum.repos.d/cassandra.repo

[cassandra]
name=Apache Cassandra
baseurl=https://redhat.cassandra.apache.org/40x/
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://downloads.apache.org/cassandra/KEYS {code}
Same results:
{code:java}
# yum list --showduplicate cassandra\*
Loaded plugins: fastestmirror, ovl
Loading mirror speeds from cached hostfile
 * base: mirror.cloudhosting.lv
 * extras: mirror.cloudhosting.lv
 * updates: mirrors.up.pt
Available Packages
cassandra.noarch                                                                                                                                                 4.0.11-1                                                                                                                                            cassandracassandra-tools.noarch                                                                                                                                           4.0.11-1                                                                                                                                            cassandra
 {code}
 
[https://apache.jfrog.io/artifactory/cassandra-rpm/noboolean/|http://example.com] Has no repodata files.
 
And
 
https://apache.jfrog.io/artifactory/cassandra-rpm/repodata/repomd.xml.asc: [Errno 14] HTTPS Error 404 - Not Found