av9ash/GitBugs huggingface dataset:
Bug: Incorrect stream used in SUPPORTED frame
Status: Resolved
Priority: Normal
Resolution: Duplicate
Created: 05/Feb/21 07:08
Resolved: 05/Feb/21 10:38

Cassandra 4.0 beta4 does not correctly send replies to OPTIONS frames when using CQL protocol version 4: In response to OPTIONS frame sent with stream ID 1, Cassandra 4.0 beta4 replies with SUPPORTED frame with stream ID 0 (instead of replying with the same stream ID as client requested).

See attached network dump.

The issue can be reproduced by connecting with gocql driver, see attached Go program.

Happens also when using protocol version 3. I haven't checked protocol version 5 as we don't have support for it in gocql yet.

The issue cannot be reproduced with Cassandra 4.0 beta3.

Originally reported at gocql: https://github.com/gocql/gocql/issues/1532
Bug: Response headers to OPTION messages always have Stream ID of zero 
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 11/Jan/21 10:14
Resolved: 15/Jan/21 12:08

It seems that streaming behavior has changed since version 4.0-beta2. When a new connection is made, all responses to the OPTIONS messages always return with stream id 0 even if requests are made with stream id 1. This causes connection failures on some clients. 

Attached wireshark dump with an example.

 

Node version: 4.0-beta4

Native protocol version: tested with v3 and v4
Bug: Cassandra-builds should remove the unused (non-dangling) docker images in Jenkins
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 03/Feb/21 22:01
Resolved: 04/Feb/21 21:41

The docker `prune` commands used in the Jenkins builds only remove the dangling images. What we are expecting is to remove the unused ones as well. 

The commands currently used are missing the option `-a | --all`.
Bug: Bugs in CQLSH tests
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 27/Jan/21 10:48
Resolved: 28/Jan/21 11:58

There are some bugs in Python CQLSH tests which causes problems when testing in some environments - it hit me when I tried to test that on Mac. In particular the tests seem to be sensitive to terminal settings and Python version (and it seems like the operating system too).
Bug: Selecting resource intensive tests is not consistent
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 22/Jan/21 07:52
Resolved: 28/Jan/21 11:03

It looks like there are two problems:
 - collection of tests to run fails when there are log messages in stderr
 - collection of resource intensive tests (with
{code:java}
--only-resource-intensive-tests{code}
) is broken
Bug: Restore check for consistent native protocol versions for connection
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 05/Jan/21 14:30
Resolved: 22/Jan/21 14:03

In protocol v4 and earlier, the frame header is checked during deserialization to ensure that the version matches the one negotiated for the connection.
The original intention was to remove this version id from the frame (renamed to envelope in v5) header. However, there is value in keeping this check as well as the the one for the beta flag, so it remains in the frame/envelope format. The validation itself however, was removed by some refactoring as part of CASSANDRA-15299 and should be added back for all protocol versions before finalizing v5 and cutting a release candidate. The text detailing its removal also remains in the proposed spec update attached to CASSANDRA-14688, which also needs to be updated.
Bug: KeyCache load performance issue during startup
Status: Resolved
Priority: Normal
Resolution: Duplicate
Created: 12/Jan/21 13:26
Resolved: 14/Jan/21 15:22

Cassandra startup blocked for loading key cache.

From org.apache.cassandra.service.CassandraDaemon#setup method:
{code:java}
try
{
 loadRowAndKeyCacheAsync().get();
}
catch (Throwable t)
{
 JVMStabilityInspector.inspectThrowable(t);
 logger.warn("Error loading key or row cache", t);
}{code}

Key cache {{deserialize}} method is fetching all CANONICAL SSTables and picks one from it for each entry: https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/service/CacheService.java#L447. When the key cache is relatively big and has lots of SSTables (in thousands) then loading key cache take lots of time.

Performance of key cache loading can be improved and have timeout for it.
Bug: Import from csv of empty strings in list fails with a ParseError: Empty values are not allowed,  given up without retries
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 04/Jan/21 15:23
Resolved: 12/Jan/21 19:32

 

Cqlsh fail to import an empty string which is present in a list data type.

{color:#ff0000}_In those conditions, simple csv backups can discard rows and data can be corrupted._{color}

 

*Conditions*

 
{code:java}
# cqlsh
Connected to Test Cluster at 127.0.0.1:9042.
[cqlsh 5.0.1 | Cassandra 3.11.6 | CQL spec 3.4.4 | Native protocol v4]
Use HELP for help.

CREATE TABLE test.test_1 (
    uid uuid PRIMARY KEY,
    texts list<text>
);

insert into test.test_1 ( uid, texts ) VALUES( 833fee3f-d4f9-418b-9387-84ac2cda5cb7, ['But if you now try to wash your hands,', ''] );

{code}
 

Now exporting and and re-importing data fails:

 
{code:java}
cqlsh> select * from test.test_1;

 uid                                  | texts
--------------------------------------+------------------------------------------------
 833fee3f-d4f9-418b-9387-84ac2cda5cb7 | ['But if you now try to wash your hands,', '']


cqlsh> COPY test.test_1 (uid, texts) TO 'ctm.csv'; 
Using 7 child processesStarting copy of test.test_1 with columns [uid, texts].
Processed: 1 rows; Rate: 9 rows/s; Avg. rate: 9 rows/s 1 rows exported to 1 files in 0.148 seconds. 

cqlsh> truncate table test.test_1;


cqlsh> COPY test.test_1 (uid, texts) FROM 'ctm.csv';
Using 7 child processes
Starting copy of test.test_1 with columns [uid, texts].
Failed to import 1 rows: ParseError - Failed to parse ['But if you now try to wash your hands,', ''] : Empty values are not allowed,  given up without retries
Failed to process 1 rows; failed rows written to import_test_test_1.err
Processed: 1 rows; Rate:       2 rows/s; Avg. rate:       2 rows/s
1 rows imported from 1 files in 0.415 seconds (0 skipped).


cqlsh> select * from test.test_1; 
uid  | pid
-----+-----

{code}
Bug: Deploy testing docker images to hub.docker.com/u/apache/ 
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 05/Jan/21 13:49
Resolved: 07/Jan/21 21:40

INFRA-21103 demonstrates PMC individuals can get access to the apache organisation on dockerhub (and the dockerhub "cassandra" team).

We have a number of docker images (used in testing and CI) that are currently deployed under individual user accounts on dockerhub. These can now be deployed under https://hub.docker.com/u/apache
Bug: Byteman fails to install injections after Jacoco upgrade
Status: Resolved
Priority: Low
Resolution: Fixed
Created: 28/Jan/21 19:42
Resolved: 22/Oct/22 02:11

This ticket is a follow up on CASSANDRA-16365 and it should be worked on after the Jacoco upgrade is committed

List of the failing tests:

org.apache.cassandra.db.commitlog.CommitLogSegmentBackpressureTest.testCompressedCommitLogBackpressure

org.apache.cassandra.db.compaction.CompactionsBytemanTest.testSSTableNotEnoughDiskSpaceForCompactionGetsDropped

org.apache.cassandra.db.compaction.CompactionsBytemanTest.testRuntimeExceptionWhenNoDiskSpaceForCompaction

org.apache.cassandra.db.compaction.CompactionsBytemanTest.testStopUserDefinedCompactionRepaired

org.apache.cassandra.db.compaction.CompactionsBytemanTest.testStopSubRangeCompactionRepaired

org.apache.cassandra.db.repair.PendingAntiCompactionBytemanTest.testExceptionAnticompaction

org.apache.cassandra.gms.PendingRangeCalculatorServiceTest.testDelayedResponse

org.apache.cassandra.hints.HintsBufferPoolTest.testBackpressure
Bug: Update Cassandra dependencies to fix security vulnerabilities
Status: Resolved
Priority: Low
Resolution: Not A Problem
Created: 19/Mar/21 16:57
Resolved: 03/Aug/21 21:31

There are a couple of security vulnerabilities that show up in libraries that cassandra pulls in.
 # apache commons-collections v 3.2.1
 # apache commons-beanutils v 1.7.0

For number one, there is a well-known security vulnerability in apache commons-collection 3.2.1 (see [https://www.kb.cert.org/vuls/id/576313] and https://issues.apache.org/jira/browse/COLLECTIONS-580). This is fixed/mitigated in commons-collections 3.2.2.

All current versions of cassandra (including 4.0beta4) pull in commons-collections 3.2.1 via apache-rat 0.10. Is it possible to upgrade apache-rat to version 0.12 in order to pull in the latest version of commons-collections? See [https://github.com/apache/creadur-rat/commit/2380409fbcd02b418eceacfdc1e486bdbbca9632].

I made the below change in 3.0.24 src and recompiled without errors.
{code:java}
// code placeholder
diff --git a/cassandra/cassandra-3.0-src/build.xml b/cassandra/cassandra-3.0-src/build.xml
index 73c9889d81..ed236443d4 100644
--- a/cassandra/cassandra-3.0-src/build.xml
+++ b/cassandra/cassandra-3.0-src/build.xml
@@ -402,3 +402,3 @@
           <dependency groupId="org.reflections" artifactId="reflections" version="0.9.12" />
-          <dependency groupId="org.apache.rat" artifactId="apache-rat" version="0.10">
+          <dependency groupId="org.apache.rat" artifactId="apache-rat" version="0.12">
              <exclusion groupId="commons-lang" artifactId="commons-lang"/>
@@ -1605,3 +1605,3 @@
     <artifact:dependencies pathId="rat.classpath">
-      <dependency groupId="org.apache.rat" artifactId="apache-rat-tasks" version="0.6" />
+      <dependency groupId="org.apache.rat" artifactId="apache-rat-tasks" version="0.12" />
       <remoteRepository refid="central"/>
{code}
 

For number two, I was able to discern that beanutils is coming from hadoop-core which is version 1.0.3.  I believe this also is quite out of date and could be upgraded. 

Could someone take a look and see if these version upgrades are possible?

{{}}
Bug: In Jenkins move and split jvm dtests to 'Distributed Test' stage
Status: Resolved
Priority: Low
Resolution: Fixed
Created: 23/Jan/21 11:33
Resolved: 26/Mar/21 22:27

The jvm-dtests are taking long enough now to warrant moving them from the 'Test' stage to the 'Distributed Test' stage in the Jenkins pipeline.

That is, jvm-dtests is now taking significantly longer than any of the other unit test jobs in the 'Test' stage, increasing the time the time the whole pipeline takes.

Moving both jvm-dtest and jvm-dtest-upgrade to the `Distributed Test`, and splitting them (changing the job to a matrix), will reduce the pipeline runtime. Such grouping also makes sense logically.
Bug: Expose StorageServiceMBean#getKeyspaceReplicationInfo from 4.0 to 3.11
Status: Resolved
Priority: Low
Resolution: Fixed
Created: 15/Feb/21 12:30
Resolved: 26/Mar/21 09:10

As part of CASSANDRA-13853, there was a method introduced into StorageServiceMBean via which an operator can retrieve information about a particular keyspace. This method is very handy not only in the context of 13853 and I am lacking that method in 3.11 as it was not ported there. I would like to have that method in 3.11 too for observability purposes as well as for the feature parity with 4.0.

https://github.com/apache/cassandra/pull/897

https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/505/
Bug: Update the Compact Storage related docs
Status: Resolved
Priority: Low
Resolution: Fixed
Created: 02/Mar/21 19:33
Resolved: 22/Mar/21 16:04

Compact Storage partial support was returned recently. 

We need to elaborate in the docs on what does this mean to the users.
 * Compact Storage support was returned, except for the supercolumn tables.
 * This was done because during the big 4.0 beta testing changes of behavior after DROP COMPACT STORAGE usage were revealed.   

/CC [~ifesdjeen]
Bug: Remove ant targets list-jvm-dtests and ant list-jvm-upgrade-dtests 
Status: Resolved
Priority: Low
Resolution: Fixed
Created: 15/Mar/21 10:33
Resolved: 19/Mar/21 17:15

Nobody uses them.

CircleCI uses {{`circleci tests glob …`}} https://github.com/apache/cassandra/blob/trunk/.circleci/config-2_1.yml#L881 

And ci-cassandra.a.o is [soon going|https://issues.apache.org/jira/browse/CASSANDRA-16402] to be using {{`split -n r/S/N …`}}
https://github.com/thelastpickle/cassandra-https://github.com/thelastpickle/cassandra-builds/commit/96b0d768757e61b23bee191f287eeca4b14c14cc#diff-4195e47b46326c5e879c949a1300aa403d4562fb70eb872dbeb597e22e18f9e0R19


references:
- https://the-asf.slack.com/archives/CK23JSY2K/p1615796046117100
Bug: Add dtest-upgrade and dtest-large-novnode to Jenkins pipeline
Status: Resolved
Priority: Low
Resolution: Fixed
Created: 11/Jan/21 10:31
Resolved: 10/Feb/21 11:59

Now that dtest-upgrade test runs are passing they can be considered for addition to the jenkins pipeline. And dtest-large-novnode only as one failure so should be added too.  

https://the-asf.slack.com/archives/CK23JSY2K/p1610132643162700
Bug: Handle both TimeoutError and NodeError when expecting node start failure
Status: Resolved
Priority: Low
Resolution: Fixed
Created: 25/Jan/21 10:01
Resolved: 29/Jan/21 13:19

*Summary*

Some tests are validating situation, when node (or cluster) does not start correctly.

They rely on `TimeoutError` to be raised, but technically it is also possible that `ccm` will raise `NodeError` without waiting for timeout to be met.

*Why we need this change*

We can improve `ccm` to fail fast in case node being started terminates. This would:
 * make unexpected test failures faster to fail (not waiting 90 or 120s)
 * shorten overall test duration, even if timeout is given

ccm work (in progress): [https://github.com/riptano/ccm/pull/724]

*Proposed improvement*

Handle both TimeoutError and NodeError as expected node failure.

*PR*

https://github.com/apache/cassandra-dtest/pull/120
Bug: Increase node start timeout for selected bootstrap and replace node tests
Status: Resolved
Priority: Low
Resolution: Fixed
Created: 19/Jan/21 08:45
Resolved: 21/Jan/21 12:53

*Summary*

Node start timeouts should be explicitly extended to more than default 90s (boostrap with reset state, replace node tests) because the default 90s will start to work after ccm changes.

*Why we need this change*

There is a bug in [https://github.com/riptano/ccm] that node.start() timeout (or more precisely node.wait_for_binary_proto() timeout is in practice 600s. This is the time to wait for certain log message:

[https://github.com/riptano/ccm/blob/484476494bda6d71f895826358722a7b1c47a3cf/ccmlib/node.py#L642|https://github.com/riptano/ccm/blob/cassandra-test/ccmlib/node.py#L642]

This bug will be fixed by: [https://github.com/riptano/ccm/pull/725]

*Proposed improvement*

Explicitly raise node start timeout to 120s or 180s (depending on the scenario) by using existing `Node` api to provide timeout as int (in seconds) instead of bool.

Note that this is available after [https://github.com/riptano/ccm/pull/725] is merged but should not break test logic before it is merged.

*PR*

[https://github.com/apache/cassandra-dtest/pull/113/files]
Bug: Using a cryptographically weak Pseudo Random Number Generator (PRNG)
Status: Resolved
Priority: Low
Resolution: Not A Problem
Created: 16/Jan/21 01:09
Resolved: 19/Jan/21 17:05

We are a security research team at Virginia Tech. We are doing an empirical study about the usefulness of the existing security vulnerability detection tools. The following is a reported vulnerability by certain tools. We'll so appreciate it if you can give any feedback on it.

*Vulnerability Description*

In file [cassandra/src/java/org/apache/cassandra/gms/Gossiper.java|https://github.com/apache/cassandra/blob/79e693e16e2152097c5b27d2d7aaa1763e34f594/src/java/org/apache/cassandra/gms/Gossiper.java], use java.util.Random instead of java.security.SecureRandom at Line 123.

*Security Impact:*

Java.util.Random is not cryptographically strong and may expose sensitive information to certain types of attacks when used in a security context.

*Useful Resources*:

[https://cwe.mitre.org/data/definitions/338.html]

*Solution we suggest*

Replace it with SecureRandom

*Please share with us your opinions/comments if there is any*

Is the bug report helpful?
Bug: Ability to log large objects with query that's reading it
Status: Triage Needed
Priority: Urgent
Created: 25/Jul/24 16:59

We often encounter cases where humongous object allocations cause long GC pauses. However, identifying the cause is very difficult because you must use a profiler to catch the allocations before GC.

It would be nice to add a TRACE-level logger to the ReadCommand or ReadExecutor classes. This would allow us to turn on code that calculates the cell size and, if it exceeds the heap region size (which varies by heap size), triggers a message in the logs that identifies the query that triggered the large read with the partition key and query parameters so it's easy to ID the cell.

It might be easier to log on the write rather than the read path.
Bug: Expose the execution results of a cleanup command to a virtual table
Status: Review In Progress
Priority: High
Created: 09/Jul/24 17:19

When a cleanup command is called, the compaction process is triggered under the hood is triggered accordingly. However, if there is nothing to compact or the cleanup command returns with a status other than SUCCESSFUL, there is no way to get the execution results of the command that was run. This is especially true when using any kind of automation/scripting on top of JMX or as a nodetool wrapper.

We want to see some information about the cleanup command (id, status, etc.) that was executed. As a possible solution, we can use a small heap buffer with the history of the executed commands to expose the buffer in a virtual table accordingly.

Operations with other OperationType e.g. SCRUB, VERIFY etc. can be exposed in the same way.
Bug: Make the compression cache configurable to reduce heap pressure for large SSTables
Status: Resolved
Priority: High
Resolution: Fixed
Created: 05/Sep/24 20:37
Resolved: 08/Sep/24 15:14

Normally the CompressionInfo.db file is trivial in size (a few kb) and so can be easily cached to prevent wasteful requests for the same file, but for large SSTables (running into a few hundred GB, due to schema issues or large blobs) then the {color:#000000}CompressionInfo.db files can also grow to be a few hundred MB or GB making it problematic to cache. We should make the compression cache optional and configurable so we don’t cache large files.{color}
Bug: Add an ability to reconstruct arbitrary epoch state from the log to TCM
Status: Resolved
Priority: High
Resolution: Fixed
Created: 22/Jul/24 16:12
Resolved: 27/Aug/24 09:47

Current Accord functionality requires TCM to be able to provide cluster metadata for an arbitrary epoch. Unfortunately, epochs are not always available locally especially on bootstrapping non-CMS nodes. For this, we need to reconstruct from the log.
Bug:  Accord Journal / Determinism: Load Command states from the log
Status: Resolved
Priority: High
Resolution: Fixed
Created: 08/Jul/24 14:23
Resolved: 14/Aug/24 07:52

  * Persist intermediate Command inthe journal
  * Simplify AccordJournal by removing Framing
  * Save command outcomes to the log
  * Reconstruct latest command state from the log entries
  * Replace `SerializerSupport#reconstruct` with log reconstruction
Bug: Accord Journal / Determinism: Store intermediate Command states in the log
Status: Resolved
Priority: High
Resolution: Fixed
Created: 08/Jul/24 09:50
Resolved: 19/Aug/24 09:49

Write side of the replay determinism: persist intermediate Command in the journal

      * Simplifies AccordJournal by removing Framing
      * Saves command outcomes to the log
      * Reconstructs latest command state from the log entries
Bug:  CREATE TABLE LIKE with  INDEX / ALL option
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 29/Sep/24 05:12
Resolved: 26/Feb/25 14:38

no matter  Copy table with indexes or triggers  under same keyspace or  differenet.
The indexes and trigger name should be different from the source in case of conflict.
we need to 
1.Adding cql parser for ALL/INDEX/TRIGGER when doing create table like 
2.Automatic completion of keywords(LIKE/ALL/INDEX/TRIGGER) and function hints (the source table and target table explain_completion when doing table copy) at the cqlsh level.

 in pylib/cqlshlib/cql3handling.py and the test in pylib/cqlshlib/test/test_cqlsh_completion.py.
Bug: Add jeetkundoug's gig key to project's KEYS file
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 10/Sep/24 13:24
Resolved: 10/Sep/24 13:40

This patch adds my gpg public key to the KEYS file.

My gpg public key has the fingerprint 9A648E3DEDA36EECCCC374C4277B602ED2C52277
Bug: Enhance the Native Protocols page by replacing the plain text with an interactive, section-based navigation
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 12/Sep/24 07:25
Resolved: 24/Feb/25 22:41

This ticket tracks this PR (1). The PR was created before this ticket was and I feel like it is impactful enough to deserve its own ticket to track these changes under.

(1) https://github.com/apache/cassandra-website/pull/282
Bug: StorageService JMX mbean is not available during bootstrap
Status: Review In Progress
Priority: Normal
Created: 06/Sep/24 01:56

Looks like the seemingly harmless cosmetic patch from CASSANDRA-11537 causes the StorageServiceMBean to not be available during bootstrap. This causes commands like "nodetool nestats/status/etc" to not be available on the boostrapping node with the following error:

{code:none}
- StackTrace --
javax.management.InstanceNotFoundException: org.apache.cassandra.db:type=StorageService
        at java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getMBean(DefaultMBeanServerInterceptor.java:1083)
        at java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttribute(DefaultMBeanServerInterceptor.java:637)
{code}

This ticket is just to revert CASSANDRA-11537, we can re-add the improvement of that ticket later.
Bug: CREATE TABLE LIKE for copying  Basic Table definition
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 29/Sep/24 03:55
Resolved: 15/Jan/25 09:45

Introduce CREATE TABLE LIKE grammar that only COPY table's basic information:  primary key , clustering key, regular column , and their data types(including udt), data masking and table params , under the same keyspace or different keyspace.

Besides, we can also set table paramas at the time when copy table : The grammer is :
{quote}CREATE TABLE [IF NOT EXISTS] <newtable> LIKE <oldtable> WITH <property> = <value>{quote}
Bug: Update Docs page for 3rd Party Plugins 
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 16/Jul/24 00:13
Resolved: 31/Jan/25 11:01

The Plugin doc page under [integrating/plugins|https://github.com/apache/cassandra/tree/trunk/doc/modules/cassandra/pages/integrating/plugins/index.adoc] has only two plugins, but of which are obsolete as of Cassandra 5.0.  This suggests the entire page should be deleted to avoid confusing users.
 # The Stratio's [Lucene|https://github.com/instaclustr/cassandra-lucene-index] plugin was maintained by Instaclustr (NetApp) but will be retired with Cassandra 5.0 in favor of SAI indexing. It should be removed.
 # [CAPI-Rowcache|https://github.com/ppc64le/capi-rowcache] for IBM Power8 system with a CAPI flash card hasn't been maintained or updated for the past 7 years with the last release in June 2017. I've attempted to contact the author by email, but have received no response.  In addition the Power8 has reached end-of-service-life in October 2024.