av9ash/GitBugs huggingface dataset:
Bug: Test failure: org.apache.cassandra.distributed.test.RepairTest.testForcedNormalRepairWithOneNodeDown
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 10/Apr/23 17:33
Resolved: 16/Jan/25 19:56

The test appears to be flaky as seen in 
https://ci-cassandra.apache.org/job/Cassandra-trunk/1509/testReport/org.apache.cassandra.distributed.test/RepairTest/testForcedNormalRepairWithOneNodeDown__jdk1_8/
and 
https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2329/workflows/f56b57d8-a283-4c76-968a-a2a553bf57b7/jobs/20786/tests#failed-test-0


{code:java}
junit.framework.AssertionFailedError: Exception found expected null, but was:<java.lang.RuntimeException: Did not get replies from all endpoints.
	at org.apache.cassandra.service.ActiveRepairService.failRepair(ActiveRepairService.java:748)
	at org.apache.cassandra.service.ActiveRepairService.prepareForRepair(ActiveRepairService.java:681)
	at org.apache.cassandra.repair.RepairRunnable.prepare(RepairRunnable.java:400)
	at org.apache.cassandra.repair.RepairRunnable.runMayThrow(RepairRunnable.java:279)
	at org.apache.cassandra.repair.RepairRunnable.run(RepairRunnable.java:248)
	at org.apache.cassandra.concurrent.FutureTask$1.call(FutureTask.java:96)
	at org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:61)
	at org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:71)
	at org.apache.cassandra.concurrent.FutureTask$1.call(FutureTask.java:96)
	at org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:61)
	at org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:71)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
	at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
	at java.lang.Thread.run(Thread.java:750)
>
	at org.apache.cassandra.distributed.test.DistributedRepairUtils.lambda$assertParentRepairSuccess$4(DistributedRepairUtils.java:129)
	at org.apache.cassandra.distributed.test.DistributedRepairUtils.validateExistingParentRepair(DistributedRepairUtils.java:164)
	at org.apache.cassandra.distributed.test.DistributedRepairUtils.assertParentRepairSuccess(DistributedRepairUtils.java:124)
	at org.apache.cassandra.distributed.test.RepairTest.testForcedNormalRepairWithOneNodeDown(RepairTest.java:212)
{code}
Bug: Added support for type VECTOR<type, dimension>
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 05/May/23 23:09
Resolved: 22/Jun/23 15:47

Based off several mailing list threads (see "[POLL] Vector type for ML”, "[DISCUSS] New data type for vector search”, and "Adding vector search to SAI with heirarchical navigable small world graph index”), its desirable to add a new type “VECTOR” that has the following properties

1) fixed length array
2) elements may not be null
3) flatten array (aka multi-cell = false)
Bug: Convert AccordStateCache cache from write-through to write-back
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 02/Jun/23 12:22
Resolved: 16/Jun/23 14:20

Pre-requisite work for soon to go up PRs that continue shifting the bulk of persistence from system tables to {{AccordJournal}}. The switch to write-back caching should allow to bypass writes to the system tables entirely for some of the transactions.

Additionally fixes some bugs in the cache, e.g. {{AsyncLoader}} failing to load an object could cause entries to be forever stuck in {{PENDING}} state because it would never reach the code path that submits the load runnables to the executor (that is now the job of the cache). Also switched the list implementation from a hand-rolled ad-hoc one to the pre-existing {{IntrusiveLinkedList}}, plus various simplifications and cleanup.
Bug: Fix cross-refs in trunk - incorrect syntax, no components
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 15/Jun/23 21:37
Resolved: 23/Aug/23 21:41

The nav.adoc in modules/cassandra has xrefs with:
{code:java}
xref:developing:data-modeling/filename.adoc
{code}
when they should be:
{code:java}
xref:developing/data-modeling/filename.adoc
{code}

Issue arose due to the flattened antora component structure of the Apache C* docs (only ROOT and cassandra).

All xrefs need fixing.
Bug: Tidy up vestigial code left over after CASSANDRA-17931
Status: Open
Priority: Normal
Created: 26/Jun/23 18:50

In CASSANDRA-17931, some code was left over (\{{additionalBytes}}, {{{}additionalSSTables{}}}) inside the {{PendingRepairManager}} which, while not explicitly hurting anything, provides for some confusion around when we do or don't take additional values into account when adjusting for pending operations when deciding what to do with upcoming repairs etc.

 

We should tidy that up and consider making the role of those methods / their structure more clear between the \{{PendingRepairManager]} hierarchy and the {{AbstractCompactionStrategy}} hierarchy to prevent further confusion.
Bug: Make JMX SSL to be configured in cassandra.yaml
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 09/May/23 14:13
Resolved: 23/Nov/24 09:44

We need a way to specify sensitive JMX SSL configuration options to avoid them being easily exposed.

When encrypting the JMX connection the passwords for the key and trust stores must be specified using the {{javax.net.ssl.keyStorePassword}} and {{javax.net.ssl.trustStorePassword}} options respectively in the _cassandra-env.sh_ file. After Cassandra is started it is possible to see the passwords by looking the running process ({{ps aux | grep "cassandra"}}).

Java 8 has the ability to specify a configuration file that can contain these security sensitive settings using the {{com.sun.management.config.file}} argument. However, despite what the documentation ([https://docs.oracle.com/javase/8/docs/technotes/guides/management/agent.html#gdevf]) says, both the {{com.sun.management.jmxremote}} and {{com.sun.management.jmxremote.port}} arguments need to be defined in the _cassandra-env.sh_ for the JVM to read the contents of the file.

The problem with defining the {{com.sun.management.jmxremote.port}} argument is it conflicts with the {{cassandra.jmx.remote.port}} argument. Even if the port numbers are different, attempting an encrypted JMX connection using {{nodetool}} fails and we see a {{ConnectException: 'Connection refused (Connection refused)'}} error.

One possible way to fix this is to introduce a new option that would allow a file to be passed containing the JMX encryption options.
Bug: TupleType getString and fromString are not safe with string types
Status: Open
Priority: Normal
Created: 12/May/23 23:13

In adding property tests for our type system in CASSANDRA-18504, I found that tuples have issues with strings as its escaping doesn’t work in all cases… below is a simple example where it fails

{code}
package org.apache.cassandra.db.marshal;

import java.nio.ByteBuffer;
import java.util.Arrays;
import java.util.List;
import java.util.UUID;

import org.junit.Test;

import org.apache.cassandra.cql3.FieldIdentifier;
import org.apache.cassandra.utils.ByteBufferUtil;

import static org.assertj.core.api.Assertions.assertThat;

public class UserTypeTest
{
    @Test
    public void test()
    {
        // tuple parsing checks for : and looks to see if a \\ is before it (escaped :), so when the string ends with this escape... we fail to parse
        String str = "thiswillbreakthings\\";
        UUID uuid = UUIDType.instance.compose(UUIDType.instance.fromString("00000000-0000-4800-9100-000000000000"));

        List<FieldIdentifier> fieldNames = Arrays.asList(new FieldIdentifier(ByteBufferUtil.bytes("a")),
                                                         new FieldIdentifier(ByteBufferUtil.bytes("b")));
        List<AbstractType<?>> fieldTypes = Arrays.asList(UTF8Type.instance, UUIDType.instance);
        UserType type = new UserType("--dummy--", UTF8Type.instance.decompose("name"), fieldNames, fieldTypes, false);
        ByteBuffer original = TupleType.buildValue(UTF8Type.instance.decompose(str), UUIDType.instance.decompose(uuid));
        String source = type.getString(original);
        ByteBuffer bb = type.fromString(source);
        ByteBuffer[] split = type.split(ByteBufferAccessor.instance, bb);
        assertThat(split).hasSize(2);
        assertThat(split[1]).isEqualTo(uuid);
    }
}
{code}
Bug: SAI - LIKE prefix/suffix support
Status: Open
Priority: Normal
Created: 02/May/23 17:46

This should provide the following functionality:
 * LIKE abc% - prefix support
 * LIKE %bcd - suffix support
 * LIKE ab%cd - prefix/suffix support

Out of scope:
 * LIKE %abc% - contains support

The index support for this can broken down as follows (general ideas that are open to suggestions):
 * Prefix support. This can currently be achieved with the existing trie index but this needs work to make it more performant in coalescing postings. An alternative approach could be to modify the block balanced tree to support variable length datatypes. This would make general range queries possible on variable length types as well as prefix queries. These would benefit from the auxilary postings present in the balanced tree.
 * Suffix support. This will need a reverse index on the values. This allows a search of the suffix to operate in the same way as a prefix query. There is no reason why suffix index cannot be built on top of the prefix index with separate postings for prefix and suffix. We would need to look at the byte comparable code in order to produce reverse values efficiently that sort correctly. 
 * Prefix/Suffix support. This would require separate prefix and suffix index searches and an intersection on the resulting postings.
Bug: CEP-29: NOT operator
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 12/Jun/23 13:30
Resolved: 30/Aug/24 01:18

Implement new CQL operators:
- NOT CONTAINS,
- NOT CONTAINS KEY,
- NOT IN
- NOT LIKE

https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-29%3A+CQL+NOT+operator
Bug: Enhance nodetool gcstats 
Status: Changes Suggested
Priority: Normal
Created: 17/Apr/23 20:19

Nodetool gcstats provides only a brief one line output of historical GC activity with Max, Total, Stdev, etc
{noformat}
% nodetool gcstats
       Interval (ms) Max GC Elapsed (ms)Total GC Elapsed (ms)Stdev GC Elapsed (ms)   GC Reclaimed (MB)         Collections      Direct Memory Bytes
               11979                   0                   0                 NaN                   0                   0                       -1
{noformat}
1. Performance of garbage collection is such an key part of Cassandra performance that it would be helpful to have more complete metrics with *gcstats* here.  The MBean java.lang.GarbageCollector has recent statistic which could be added in events/second for:
 * GcThreadCount
 * Duration

The current size of eden / survivor / old space and humongous allocations should be shown as well.

The metrics show with jhsdb jmap would be very helpful as well, if they're available.

[https://docs.oracle.com/en/java/javase/11/troubleshoot/diagnostic-tools.html#GUID-A69901EC-F87D-4B63-A8B7-DE8684AD4FF9]

2. Since physical memory is also a critical part of GC performance, it would be useful to report the following MBeans 
|[cassandra_os_free_memory_bytes|https://github.com/instaclustr/cassandra-exporter/wiki/Exported-Metrics#_cassandra_os_free_memory_bytes]|Amount of free physical memory available (as seen by the Cassandra JVM process).|
|[cassandra_os_free_swap_bytes|https://github.com/instaclustr/cassandra-exporter/wiki/Exported-Metrics#_cassandra_os_free_swap_bytes]|Amount of free swap space available (as seen by the Cassandra JVM process).|
|[cassandra_os_memory_bytes_total|https://github.com/instaclustr/cassandra-exporter/wiki/Exported-Metrics#_cassandra_os_memory_bytes_total]|Total physical memory available (as seen by the Cassandra JVM process).|
|[cassandra_os_swap_bytes_total|https://github.com/instaclustr/cassandra-exporter/wiki/Exported-Metrics#_cassandra_os_swap_bytes_total]|Total swap space available (as seen by the Cassandra JVM process).|

or use [/proc/meminfo|https://stackoverflow.com/questions/59581597/get-available-ram-in-java] SystemInfo.java already reads /proc/<pid>/limits on Linux systems.

3. Status of memlock
Bug: Enable Direct I/O For CommitLog Files
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 18/Apr/23 20:23
Resolved: 29/Nov/23 10:51

Relocating from [dev@ email thread.|https://lists.apache.org/thread/j6ny17q2rhkp7jxvwxm69dd6v1dozjrg]

 

I shared my investigation about Commitlog I/O issue on large core count system in my previous email dated July-22 and link to the thread is given below.
[https://lists.apache.org/thread/xc5ocog2qz2v2gnj4xlw5hbthfqytx2n]

Basically, two solutions looked possible to improve the CommitLog I/O.
 # Multi-threaded syncing
 # Using Direct-IO through JNA

I worked on 2nd option considering the following benefit compared to the first one
 # Direct I/O read/write throughput is very high compared to non-Direct I/O. Learnt through FIO benchmarking.
 # Reduces kernel file cache uses which in-turn reduces kernel I/O activity for Commitlog files only.
 # Overall CPU usage reduced for flush activity. JVisualvm shows CPU usage < 30% for Commitlog syncer thread with Direct I/O feature
 # Direct I/O implementation is easier compared to multi-threaded

As per the community suggestion, less in code complex is good to have. Direct I/O enablement looked promising but there was one issue. 
Java version 8 does not have native support to enable Direct I/O. So, JNA library usage is must. The same implementation should also work across other versions of Java (like 11 and beyond).

I have completed Direct I/O implementation and summary of the attached patch changes are given below.
 # This implementation is not using Java file channels and file is opened through JNA to use Direct I/O feature.
 # New Segment are defined named “DirectIOSegment”  for Direct I/O and “NonDirectIOSegment” for non-direct I/O (NonDirectIOSegment is test purpose only).
 # JNA write call is used to flush the changes.
 # New helper functions are defined in NativeLibrary.java and platform specific file. Currently tested on Linux only.
 # Patch allows user to configure optimum block size  and alignment if default values are not OK for CommitLog disk.
 # Following configuration options are provided in Cassandra.yaml file
a. use_jna_for_commitlog_io : to use jna feature
b. use_direct_io_for_commitlog : to use Direct I/O feature.
c. direct_io_minimum_block_alignment: 512 (default)
d. nvme_disk_block_size: 32MiB (default and can be changed as per the required size)

 Test matrix is complex so CommitLog related testcases and TPCx-IOT benchmark was tested. It works with both Java 8 and 11 versions. Compressed and Encrypted based segments are not supported yet and it can be enabled later based on the Community feedback.

 Following improvement are seen with Direct I/O enablement.
 # 32 cores >= ~15%
 # 64 cores >= ~80%

 Also, another observation would like to share here. Reading Commitlog files with Direct I/O might help in reducing node bring-up time after the node crash.

 Tested with commit ID: 91f6a9aca8d3c22a03e68aa901a0b154d960ab07

 The attached patch enables Direct I/O feature for Commitlog files. Please check and share your feedback.
Bug: Waiting for gossip to settle does not wait for live endpoints
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 23/May/23 00:36
Resolved: 15/Jun/23 13:58

When a node starts it will get endpoint states (via shadow round) but have all nodes marked as down. The problem is the wait to settle only checks the size of endpoint states is stable before starting Native transport. Once native transport starts it will receive queries and fail consistency levels such as LOCAL_QUORUM since it still thinks nodes are down.

This is problem for a number of large clusters for our customers. The cluster has quorum but due to this issue a node restart is causing a bunch of query errors.

My initial solution to this was to only check live endpoints size in addition to size of endpoint states. This worked but I noticed in testing this fix that there also a lot of duplication of checking the same node (via Echo messages) for liveness. So the patch also removes this duplication of checking node is UP in markAlive.

The final problem I found while testing is sometimes could still not see a change in live endpoints due to only 1 second polling, so the patch allows for overridding the settle parameters. I could not reliability reproduce this but think its worth providing a way to override these hardcoded values.
Bug: cqlsh on Cassandra 4.1.2 fails on Amazon Linux 
Status: Open
Priority: Normal
Created: 30/Jun/23 10:49

I am on the newest Amazon Linux Version 2023.1.20230629

When I install cassandra-4.1.2 from Yum repository, it starts fine but cqlsh prints this:

{code}
[ec2-user@ip-172-31-27-5 ~]$ cqlsh
Traceback (most recent call last):
  File "/usr/bin/cqlsh.py", line 148, in <module>
    from cqlshlib import cql3handling, pylexotron, sslhandling, cqlshhandling, authproviderhandling
ModuleNotFoundError: No module named 'cqlshlib'
{code}

If I change in /usr/bin/cqlsh.py

{code}
cqlshlibdir = os.path.join(CASSANDRA_PATH, 'pylib')
{code}

to this

{code}
cqlshlibdir = os.path.join('/usr/lib/python3.6', 'site-packages')
{code}

it works.

I am not sure if this is the correct way to handle that as not everybody has python3.6. There is also no symlink pointing to this. I guess we would need to find where packages are for Python we are going to use in cassandra.spec and then change cqlsh.py to reflect that?

{code}
[ec2-user@ip-172-31-27-5 /]$ sudo find -type d -name site-packages
./usr/lib/python3.9/site-packages
./usr/lib/python3.6/site-packages
./usr/lib64/python3.9/site-packages
{code}

I think we need to pass whatever this (1) expands to here (2)

(1) https://github.com/apache/cassandra/blob/trunk/redhat/cassandra.spec#L167
(2) https://github.com/apache/cassandra/blob/trunk/bin/cqlsh.py#L78
Bug: Test failure: utest: org.apache.cassandra.db.RepairedDataTombstonesTest.readTestPartitionTombstones-.jdk11
Status: Resolved
Priority: Normal
Resolution: Cannot Reproduce
Created: 04/Apr/23 20:01
Resolved: 07/Sep/23 08:10

{{Failed 1 times in the last 5 runs. Flakiness: 25%, Stability: 80%}}

{code}
Error Message
val=5
Stacktrace
junit.framework.AssertionFailedError: val=5
	at org.apache.cassandra.db.RepairedDataTombstonesTest.readTestPartitionTombstones(RepairedDataTombstonesTest.java:189)
	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: Test failure: org.apache.cassandra.distributed.test.UpgradeSSTablesTest
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 28/Jun/23 10:56
Resolved: 11/Mar/24 07:12

Seen here: https://app.circleci.com/pipelines/github/driftx/cassandra/1095/workflows/6114e2e3-8dcc-4bb0-b664-ae7d82c3349f/jobs/33405/tests

{noformat}
junit.framework.AssertionFailedError: expected:<0> but was:<2>
	at org.apache.cassandra.distributed.test.UpgradeSSTablesTest.upgradeSSTablesInterruptsOngoingCompaction(UpgradeSSTablesTest.java:86)
{noformat}
Bug: Storage Attached Indexes (Phase 2)
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 21/Apr/23 16:42
Resolved: 01/Mar/24 22:28

At the completion of CASSANDRA-16052, we should be able to release the core capabilities of SAI in a stable, production-ready package. Once that begins to gain traction, we'll be able to make improvements and add features for the next major release. The major initial theme of this epic is likely to be performance, but it will likely expand to include features like basic text analysis, etc.
Bug: Instance.nodetoolResult should connect to JMX if there is such feature enabled in its config
Status: Patch Available
Priority: Normal
Created: 07/Jun/23 11:20

Instance.nodetoolResult is not using JMX internally but it throws UnsupportedOperationException in InternalNodeProbe for some nodetool comamnds.

This makes calls to instance.nodetoolResult("info"), for example, impossible, because these commands are using JMX / calling methods which are throwing exception and it makes the testing painful.

There is no reason to not support this if Instance has JMX feature as it was added recently.
Bug: Make Corretto Crypto Provider the Default
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 23/Jun/23 04:42
Resolved: 28/Jul/23 10:17

[Amazon Corretto Crypto Provider| https://github.com/corretto/amazon-corretto-crypto-provider] is an alternative provider of TLS and cryptographic functions that has significant performance benefits for Cassandra. It is Apache 2.0 licensed and has been deployed in several existing large fleets.
Bug: Test Failure: HintsDisabledTest.testHintedHandoffDisabled
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 25/Apr/23 23:25
Resolved: 26/Apr/23 21:35

Test throws timeout exception before the CL.ONE request completes. Need to increase the timeout and make sure hints have had the opportunity to deliver.
 
{{code}}
Error Message
Operation timed out - received only 0 responses.
Stacktrace
org.apache.cassandra.exceptions.WriteTimeoutException: Operation timed out - received only 0 responses.
	at org.apache.cassandra.service.AbstractWriteResponseHandler.throwTimeout(AbstractWriteResponseHandler.java:152)
	at org.apache.cassandra.service.AbstractWriteResponseHandler.get(AbstractWriteResponseHandler.java:130)
	at org.apache.cassandra.service.StorageProxy.mutate(StorageProxy.java:901)
	at org.apache.cassandra.service.StorageProxy.mutateWithTriggers(StorageProxy.java:1151)
	at org.apache.cassandra.cql3.statements.ModificationStatement.executeWithoutCondition(ModificationStatement.java:519)
	at org.apache.cassandra.cql3.statements.ModificationStatement.execute(ModificationStatement.java:493)
	at org.apache.cassandra.distributed.impl.Coordinator.unsafeExecuteInternal(Coordinator.java:122)
	at org.apache.cassandra.distributed.impl.Coordinator.unsafeExecuteInternal(Coordinator.java:103)
	at org.apache.cassandra.distributed.impl.Coordinator.lambda$executeWithResult$0(Coordinator.java:66)
	at org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:61)
	at org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:71)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
	at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
	at java.base/java.lang.Thread.run(Thread.java:829)
{{code}}
Bug: Standalone Jenkinsfile
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 13/Jun/23 12:59
Resolved: 04/Apr/24 10:02

Spin off CASSANDRA-18133

Once all build and test scripts are in-tree, dockerised with their images in-tree too, the {{.jenkins/Jenkinsfile}} can be rewritten to be standalone. Today its inner stage jobs refer to already defined jobs by cassandra-builds' groovy dsl.

 

This addresses the epic's stated existing problems:
 - mixture of jenkins dsl groovy, declarative and scripting pipeline.
 - different pre-commit and post-commit jenkins pipelines are used.

In addition it addresses:
 - stage jobs don't always running on the same SHA as the pipeline's run,
 - a more readable Jenkinsfile