av9ash/GitBugs huggingface dataset:
Bug: [Analytics] Split out BufferingInputStream stats into separate interface
Status: Resolved
Priority: Low
Resolution: Fixed
Created: 17/Jul/24 17:10
Resolved: 17/Jul/24 21:30

The class level generics in the org.apache.cassandra.spark.stats.Stats interface are clashing with other generic parameters in the method names. This can be improved by splitting out the stats methods used by the BufferingInputStream into a separate stats interface that is used only by the BufferingInputStream so that class level generics are not required for the Stats interface.
Bug: Reentrant locks should always be locked outside of a try block
Status: Triage Needed
Priority: Low
Created: 11/Jul/24 14:08

{color:#172b4d}Acquiring the lock should always be done before the try block so that the finally clause to unlock will never execute unless the lock is acquired. More info:{color}
 
{code:java}
https://stackoverflow.com/questions/31058681/java-locking-structure-best-pattern
https://issues.apache.org/jira/browse/AMQ-9202
{code}
 

Unfortunately, there are no ready-made rules in Checkstyle, FindBugs, or SpotBugs for this type of violation checking. I use "IDEA inspection" to identify all such violations.
{code:java}
IDEA Code -> Analyze Code -> Run Inspection by Name(Lock acquired but not safely unlocked) ---> Whole project{code}
Bug: [Analytics] Refactor Analytics to move standalone code into common module with minimal dependencies
Status: Resolved
Priority: Low
Resolution: Fixed
Created: 03/Jul/24 21:18
Resolved: 12/Jul/24 21:59

The Analytics codebase is heavily tied to Spark. In an effort to re-use code across projects (like CDC) we should move standalone Pojos and util classes into an cassandra-analytics-common module that exists standalone without dependencies to Cassandra or Spark and with minimal standard dependencies (Kryo, Guava, Jackson, Apache Commons Lang etc).
Bug: Update CQLSH website documentation to remove Python 2.7 reference
Status: Resolved
Priority: Low
Resolution: Won't Fix
Created: 03/Jul/24 02:51
Resolved: 11/Jul/24 17:23

The CQLSH [Compatibility (4.1)|https://cassandra.apache.org/doc/stable/cassandra/tools/cqlsh.html#compatibility] section mentions Python 2.7 but this should be Python 3 now.

Note: it seems to be only an issue only with 4.1.

The trunk link here is correct: [Compatibility (trunk)|https://cassandra.apache.org/doc/trunk/cassandra/managing/tools/cqlsh.html]
Bug: Colourize log output
Status: Triage Needed
Priority: Low
Created: 05/Jul/24 14:15

It seems it is easy to colourize the console output, which helps read the logs and/or run tests in the IDE (works on Linux and Mac). Logback provides a way to do this easily:
[https://logback.qos.ch/manual/layouts.html#coloring]

The expected result:

!image-2024-07-05-16-10-51-385.png!
Bug: cassandra-cqlsh-tests.sh should return different return codes on circle vs jenkins
Status: Resolved
Priority: Urgent
Resolution: Fixed
Created: 05/May/21 09:51
Resolved: 05/May/21 16:11

Recent jenkins runs appear broken (red) bc of a cqlsh test failure. That reports the whole run as broken instead of that specific step with failures and an unstable (yellow) run.

It appears the reason may be [this|https://github.com/apache/cassandra/blame/trunk/pylib/cassandra-cqlsh-tests.sh#L146] change. At that time that was necessary to make circle fail that step. Otherwise cqlsh failures would be ignored and that step rendered green regarless making it useless. But it has been found now this makes jenkins report the whole run red upon a cqlsh test failure.

The solution seems to be to return different codes depending on whether we're on jenkins or circle. [~mck] has suggested sthg along these lines:

{code}
# circleci wants non-zero exit to report failures, jenkins wants zero exit for a unstable status
[[ command -v circleci >/dev/null 2>&1 ]] && exit ${RETURN}
exit 0
{code}

Procedure:
- Fix the sh script
- Break a cqlsh test
- Test the test gets reported as a failure in circle
- Test the test gets reported as a failure in jenkins and that the run and step are yellow (not red)
- Fix the test
- Both circle and jenkins report green for that step
Bug: When behind a firewall trunk is not buildable, need to allow overriding URLs
Status: Resolved
Priority: Urgent
Resolution: Fixed
Created: 06/Apr/21 17:03
Resolved: 07/Apr/21 18:15

When building behind a firewall which doesn’t allow external sites the build is no longer able to build; this is caused by 7 <get> tags in the build doing custom resolution. To work around this we should allow these paths to be overridable to allow building behind a firewall
Bug: New Cassandra Website and Documentation
Status: Resolved
Priority: High
Resolution: Fixed
Created: 24/Jun/21 20:28
Resolved: 04/May/22 13:34

This epic captures the work associated with the development of the new Cassandra website and documentation.

Work to create the new website and documentation will be broken up as follows:
 * Proof of concept - CASSANDRA-16029
 * Website concept and design - CASSANDRA-16115
 * Develop tooling to render new website and documentation - CASSANDRA-16066
 * Create website content that will be rendered by new tooling - CASSANDRA-16762
 * Create Cassandra documentation content that will be rendered by new tooling - CASSANDRA-16763

It is expected that the new website and documentation will be in asciidoc format and rendered using Antora.

Antora is purpose built for rendering versioned documentation to HTML. In addition it allows rendering customisations via Java Script which may be useful when rending the website.
Bug: Remediate Cassandra 3.11.10 JAR dependency vulnerability - com.google.guava_guava
Status: Resolved
Priority: High
Resolution: Duplicate
Created: 14/Jun/21 14:52
Resolved: 28/Jul/23 11:19

A JAR dependency is flagged in Cassandra 3.11.10 as having vulnerabilities that have been fixed in newer releases. The following is the Cassandra 3.11.10 source tree for their JAR dependencies: [https://github.com/apache/cassandra/tree/181a4969290f1c756089b2993a638fe403bc1314/lib] . 

JAR *com.google.guava_guava* version *18.0* has the following vulnerability and is fixed in version *30.0*. Recommendation is to upgrade to version *30.1.1-jre* or greater.

 
||id||cvss||desc||link||packageName||packageVersion||severity||status||vecStr||
|CVE-2018-10237|5.9|Unbounded memory allocation in Google Guava 11.0 through 24.x before 24.1.1 allows remote attackers to conduct denial of service attacks against servers that depend on this library and deserialize attacker-provided data, because the AtomicDoubleArray class (when serialized with Java serialization) and the CompoundOrdering class (when serialized with GWT serialization) perform eager allocation without appropriate checks on what a client has sent and whether the data size is reasonable.|https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2018-10237|com.google.guava_guava|18.0|medium|fixed in 24.1.1|CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H|
|CVE-2020-8908|3.3|A temp directory creation vulnerability exists in all versions of Guava, allowing an attacker with access to the machine to potentially access data in a temporary directory created by the Guava API com.google.common.io.Files.createTempDir(). By default, on unix-like systems, the created directory is world-readable (readable by an attacker with access to the system). The method in question has been marked @Deprecated in versions 30.0 and later and should not be used. For Android developers, we recommend choosing a temporary directory API provided by Android, such as context.getCacheDir(). For other Java developers, we recommend migrating to the Java 7 API java.nio.file.Files.createTempDirectory() which explicitly configures permissions of 700, or configuring the Java runtime\'s java.io.tmpdir system property to point to a location whose permissions are appropriately configured.|https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-8908|com.google.guava_guava|18.0|low|fixed in 30.0|CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N|

A possible fix strategy is to simply update the JAR to their newest version.
 * See [https://mvnrepository.com/artifact/com.google.guava/guava/30.1.1-jre]
Bug: Create Cassandra documentation content for new website
Status: Resolved
Priority: High
Resolution: Fixed
Created: 24/Jun/21 20:40
Resolved: 05/Jan/22 23:23

We need create the content (asciidoc) to render the Cassandra documentation using Antora. This work can commence once the following has happened:
 * Website and documentation proof of concept is done - CASSANDRA-16029
 * Website design and concept is done - CASSANDRA-16115
 * Website and document tooling is done - CASSANDRA-16066 
 * Website UI components are done - CASSANDRA-16762
Bug: Create content and UI components for new website
Status: Resolved
Priority: High
Resolution: Fixed
Created: 24/Jun/21 20:39
Resolved: 02/Sep/21 11:45

We need create the content (asciidoc) and UI components to render the website using Antora. This work can commence once the following has happened:
 * Website and documentation proof of concept is done - CASSANDRA-16029
 * Website design and concept is done - CASSANDRA-16115
 * Website and document tooling is done - CASSANDRA-16066
Bug: (3.0,3.11) Migrate dependency handling from maven-ant-tasks to resolver-ant-tasks
Status: Resolved
Priority: High
Resolution: Fixed
Created: 02/Apr/21 08:53
Resolved: 25/Jul/21 16:43

Backport CASSANDRA-16391 to 2.2, 3.0, and 3.11

This ticket is on hold until the ASF legal clears up its policy, and the project confirms the approach it wants to take with {{lib/}} dependencies. See [~benedict] comment [here|https://issues.apache.org/jira/browse/CASSANDRA-16391?focusedCommentId=17313754&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17313754].
Bug: Test Failure: Fix flaky ConnectionTest
Status: Open
Priority: Normal
Created: 19/May/21 13:42

https://ci-cassandra.apache.org/job/Cassandra-devbranch/785/testReport/junit/org.apache.cassandra.net/ConnectionTest/testMessageDeliveryOnReconnect_compression/

https://app.circleci.com/pipelines/github/adelapena/cassandra/460/workflows/cf7dcec6-612c-45d1-8471-623bde481dca/jobs/4069

https://app.circleci.com/pipelines/github/adelapena/cassandra/460/workflows/b750cd38-0263-4b5e-9bb8-a8be98214378/jobs/4065
Bug: The fetching strategy can be optimized for CL.ONE and CL.LOCAL_ONE
Status: Triage Needed
Priority: Normal
Created: 07/Jun/21 10:09

The current {{ColumnFilter}} fetching strategy has been implemented in order to guaranty the CQL semantics around empty vs non-existing rows. It has also some importance regarding read-repair (CASSANDRA-16710). Nevertheless, reads at {{CL.ONE}} and at {{CL.LOCAL_ONE}} do not use read-repair and do not require more columns than the queried ones as those cannot be deleted by column deletions present on other nodes. By consequence, having {{ColumnFilter}} fetching only the queried columns should improve query speed, by reducing the number of SSTable reads for queries fetching specific rows and reducing the amound of data serialized and transfered between nodes (if the data is not local).
Bug: Allow operators to disable 'ALTER ... DROP COMPACT STORAGE' statements
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 11/Jun/21 13:08
Resolved: 18/Jun/21 13:29

{{ALTER ... DROP COMPACT STORAGE}} statements have not been extensively tested and suffer from several issues like:

* As COMPACT tables did not have primary key liveness there empty rows
inserted AFTER the ALTER will be returned whereas the one inserted before
the ALTER will not.
* Also due to the lack of primary key liveness the amount of SSTables being
read will increase resulting in slower queries (CASSANDRA-16675)
* After DROP COMPACT it becomes possible to ALTER the table in a way that
makes all the row disappears
* There is a loss of functionality around null clustering when dropping
compact storage (CASSANDRA-16069)

To avoid running into those issues this ticket will introduce a new flag that allow operators to disable those statements on their clusters.

see https://www.mail-archive.com/dev@cassandra.apache.org/msg16789.html
Bug: Repaired data tracking on a read coordinator is susceptible to races between local and remote requests
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 07/Jun/21 18:37
Resolved: 27/Aug/21 17:03

At read time on a coordinator which is also a replica, the local and remote reads can race such that the remote responses are received while the local read is executing. If the remote responses are mismatching, triggering a {{DigestMismatchException}} and subsequent round of full data reads and read repair, the local runnable may find the {{isTrackingRepairedStatus}} flag flipped mid-execution.  If this happens after a certain point in execution, it would mean
that the RepairedDataInfo instance in use is the singleton null object {{RepairedDataInfo.NULL_REPAIRED_DATA_INFO}}. If this happens, it can lead to an NPE when calling {{RepairedDataInfo::extend}} when the local results are iterated.
Bug: Flaky MemtableSizeTest
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 21/May/21 09:36
Resolved: 03/Jun/21 16:23

Flaky [MemtableSizeTest|https://ci-cassandra.apache.org/job/Cassandra-4.0/50/testReport/junit/org.apache.cassandra.cql3/MemtableSizeTest/testSize_compression/]

{noformat}
Error Message

Expected heap usage close to 50.085MiB, got 41.294MiB.

Stacktrace

junit.framework.AssertionFailedError: Expected heap usage close to 50.085MiB, got 41.294MiB.

	at org.apache.cassandra.cql3.MemtableSizeTest.testSize(MemtableSizeTest.java:121)
	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)

Standard Output

INFO  [main] 2021-05-18 22:08:42,837 YamlConfigurationLoader.java:93 - Configuration location: file:////home/cassandra/cassandra/build/test/cassandra.compressed.yaml
DEBUG [main] 2021-05-18 22:08:42,840 YamlConfigurationLoader.java:112 - Loading settings from file:////home/cassandra/cassandra/build/test/cassandra.compressed.yaml
DEBUG [main] 2021-05-18 22:08:42,934 InternalLoggerFactory.java:63 - Using SLF4J as the default logging framework
DEBUG [main] 2021-05-18 22:08:42,956 PlatformDependent0
...[truncated 86028 chars]...
hed transaction log, deleting /home/cassandra/cassandra/build/test/cassandra/data/system_schema/keyspaces-abac5682dea631c5b535b3d6cffd0fb6/nb_txn_flush_a3253f00-b825-11eb-b0ec-cd4f0218a6b5.log 
DEBUG [MemtableFlushWriter:2] 2021-05-18 22:08:55,552 ColumnFamilyStore.java:1197 - Flushed to [BigTableReader(path='/home/cassandra/cassandra/build/test/cassandra/data/system_schema/keyspaces-abac5682dea631c5b535b3d6cffd0fb6/nb-6-big-Data.db')] (1 sstables, 4.894KiB), biggest 4.894KiB, smallest 4.894KiB

{noformat}
Bug: Remove dependency on sigar
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 06/Apr/21 20:08
Resolved: 23/Jan/24 13:01

sigar is used to check if the environment has good settings for running C*, but requires we bundle a lot of native libraries to perform this check (which can also be done elsewhere).  This project also appears to be dead as the last commit was around 6 years ago.

With the move to resolve artifacts rather than commit them, removing this dependency would remove majority of the artifacts fetched from GitHub.
Bug: Allow sstableloader to specify keyspace/table without relying on path
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 09/Apr/21 20:57
Resolved: 01/Jul/22 07:02

This is a followup to CASSANDRA-13884. It would be nice to be able to able to specify both the keyspace and table name for BulkLoader as commandline arguments and not rely on the path to the sstables, i.e. <keyspace>/<table>/*.db.

It looks like this may have already been completed in the patch in CASSANDRA-4763 which ended up closed because of the overlap with CASSANDRA-13884:

https://issues.apache.org/jira/browse/CASSANDRA-4763?focusedCommentId=16133937&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16133937
Bug: Changing listen_address with prefer_local may lead to issues
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 07/Jun/21 12:49
Resolved: 16/May/23 14:04

Many container based solution function by assigning new listen_addresses when nodes are stopped. Changing the listen_address is usually as simple as turning off the node and changing the yaml file. 

However, if prefer_local is enabled, I observed that nodes were unable to join the cluster and fail with 'Unable to gossip with any seeds'. 

Trace shows that the changing node will try to communicate with the existing node but the response is never received. I assume it is because the existing node attempts to communicate with the local address during the shadow round.
Bug: Add support  for AWS Ec2 IMDSv2
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 01/Apr/21 12:21
Resolved: 28/Jun/23 14:56

In order to patch a vulnerability, Amazon came up with a new version of their metadata service.

It's no longer unrestricted but now requires a token (in a header), in order to access the metadata service.
See [https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html] for more information.

Cassandra currently doesn't offer an out-of-the-box snitch class to support this.
See [https://cassandra.apache.org/doc/latest/operating/snitch.html#snitch-classes]

This issue asks to add support for this as a separate snitch class.
We'll probably do a PR for this, as we are in the process of developing one.
Bug: HintedHandoffAddRemoveNodesTest is failing
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 19/May/21 14:01
Resolved: 07/Sep/22 21:08

https://ci-cassandra.apache.org/job/Cassandra-devbranch/785/testReport/junit/org.apache.cassandra.distributed.test/HintedHandoffAddRemoveNodesTest/shouldStreamHintsDuringDecommission/

Java 8

[https://app.circleci.com/pipelines/github/adelapena/cassandra/464/workflows/888e47fb-e432-47f2-97df-c34a0d33753a/jobs/4104] 

and Java 11

 [https://app.circleci.com/pipelines/github/adelapena/cassandra/464/workflows/ce0f0690-e488-4b5b-ab82-ce92a2f336d8/jobs/4105]
Bug: org.apache.cassandra.utils.memory.LongBufferPoolTest - tests are flaky
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 19/May/21 19:12
Resolved: 11/Oct/22 14:54

Jenkins history:

[https://jenkins-cm4.apache.org/job/Cassandra-4.0/50/testReport/junit/org.apache.cassandra.utils.memory/LongBufferPoolTest/testPoolAllocateWithRecyclePartially/history/]

Fails being run in a loop in CircleCI:

https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/844/workflows/945011f4-00ac-4678-89f6-5c0db0a40169/jobs/5008
Bug: Log JVM Arguments at in-JVM Test Class Initialization
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 10/May/21 22:29
Resolved: 02/Nov/22 17:19

Normal C* startup flows through {{CassandraDaemon.setup()}}, which calls {{logSystemInfo()}}, logging JVM arguments and a number of other useful bits of information. The in-JVM dtest startup does not flow through {{CassandraDaemon.setup()}}, and therefore does not. It would be useful for troubleshooting purposes if {{TestBaseImpl}} logged the JVM arguments before moving into executing tests.
Bug: Assertion error in offline_tools_test.TestOfflineTools.sstableofflinerelevel_test
Status: Open
Priority: Normal
Created: 16/Jun/21 17:18

There is an occasional assertion error in \{{offline_tools_test.TestOfflineTools.sstableofflinerelevel_test}}:
{code:python}
        logger.debug(output)
        logger.debug(error)
    
        logger.debug(initial_levels)
        logger.debug(final_levels)
    
        # let's check sstables were promoted after releveling
>       assert max(final_levels) > 1
E       assert 1 > 1
E        +  where 1 = max([1, 1, 1, 1, 1, 1, ...])

offline_tools_test.py:217: AssertionError
 {code}
This error seems to only happen in 3.0, and it can be reproduced with the test multiplexer, for example [here|https://app.circleci.com/pipelines/github/adelapena/cassandra/589/workflows/374d302c-26a8-486c-a615-205a365f51cc/jobs/5699]. However it doesn't seem to affect more recent branches, as it can be seen in [this other run|https://app.circleci.com/pipelines/github/adelapena/cassandra/590/workflows/7ec24e4b-d3c8-48cd-ab16-d292b9e048c2/jobs/5702].
Bug: Remove test parallelism from ant build.xml in all branches
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 13/Apr/21 08:53
Resolved: 15/Apr/21 22:48

Cassandra's build.xml supports parallel test runners. This functionality is available through {{`-Dtest.runners`}} and the {{`testparallel`}} ant macro.

Having not been actively used and atrophied over time, it breaks a number of tests. The distributed in-jvm tests don't work at all with parallel runners (currently they need `-Dtest.runners=1` specified to work). And there are plenty of flakies, from where
tests use fixed ports (StorageServiceServerTest), to byteman (eg BMUnitRunner), and around conf files on disk.

This was raised on the dev ML, where the consensus was to remove it: https://lists.apache.org/thread.html/r1ca3c72b90fa6c57c1cb7dcd02a44221dcca991fe7392abd8c29fe95%40%3Cdev.cassandra.apache.org%3E

The idea is to then replace ant test parallelism with docker container parallelism.
Bug: Allow for transitioning from using one SSLContextFactory implementation to another
Status: Open
Priority: Normal
Created: 07/Jun/21 15:10

With CASSANDRA-16666 providing pluggable SSLContext, this ticket is to provide mechanics for being able to transparently transition from using one SSLContext implementation to another.

As indicated in https://issues.apache.org/jira/browse/CASSANDRA-16666?focusedCommentId=17358655&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17358655,
one could do the following on their cluster for moving from say Implementation1 to Implementation2
Stage #1: Current state of being only Implementation1 aware. Use keystore and trustmanager of implementation1
Stage #2: Start trusting both implementation1 and implementation2. Use keystore of implementation1, but use trustmanager of both implementation1 and implementation2 (using MultiTrustManagerFactory) (and perform a rolling restart of the cluster)
Stage #3: Start using implementation2 for keystore, and perform a rolling restart of the cluster
Stage #4: At this point, all nodes of the cluster are using implementation2 for keystore, but trust both implementation1 and implementation2, and we can now remove implementation1 from trustmanagers, and do a rolling restart.
Bug: CQLSH copy defaults appear to be incorrect on website
Status: Resolved
Priority: Normal
Resolution: Duplicate
Created: 07/Apr/21 20:22
Resolved: 23/Feb/23 19:09

The documentation on the website for the defaults of CQLSH appear to be incorrect and contain numerous errors (at least for the latest and greatest)

For this page:
[https://cassandra.apache.org/doc/latest/tools/cqlsh.html]

{{MINBATCHSIZE}} is listed as defaulting to 2.  Code says this is 10.
https://github.com/apache/cassandra/blob/trunk/pylib/cqlshlib/copyutil.py#L355

Chunksize says 1000, actually set to 5000.
https://github.com/apache/cassandra/blob/trunk/pylib/cqlshlib/copyutil.py#L352


NumProcessis is also off...
"NUMPROCESSES
 The number of child worker processes to create for COPY tasks. Defaults to a max of 4 for COPY FROM and 16 for COPY TO. However, at most (num_cores - 1) processes will be created."

 Default is the number of cores -1 or 16 which ever is smaller, and you can set this value to anything.  See the following code



https://github.com/apache/cassandra/blob/trunk/pylib/cqlshlib/copyutil.py#L361
https://github.com/apache/cassandra/blob/trunk/pylib/cqlshlib/copyutil.py#L407