av9ash/GitBugs huggingface dataset:
Bug: Broken test_timeuuid - upgrade_tests.cql_tests
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 10/Nov/21 17:38
Resolved: 19/Jan/22 22:34

Both CircleCI and Jenkins build failed at test_timeuuid with the following error.

{quote}cassandra.InvalidRequest: Error from server: code=2200 [Invalid query] message="Ambiguous call to function maxtimeuuid (can be matched by following signatures: system.maxtimeuuid : (bigint) -> timeuuid, system.maxtimeuuid : (timestamp) -> timeuuid): use type casts to disambiguate"{quote}

https://app.circleci.com/pipelines/github/yifan-c/cassandra/273/workflows/7a855174-823a-4553-ad09-25623747a58e/jobs/1884/tests#failed-test-0

https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/1272/tests/

The change was added in CASSANDRA-17029.
Bug: JVMStabilityInspector.forceHeapSpaceOomMaybe should handle all non-heap OOMs rather than only supporting direct only
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 08/Nov/21 23:00
Resolved: 09/Nov/21 01:54

When an OOM is thrown we do normally want the JVM to halt (assuming JVM flags state to), but this only happens in very specific cases (see CASSANDRA-15214 for more details).  Rather than relying on an allow list to convert to heap-oom, we should rely on an deny list; this way we handle every OOM thrown.
Bug: Make capacity/validity/updateinterval/activeupdate for Auth Caches configurable via nodetool
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 24/Oct/21 21:06
Resolved: 10/Jan/22 09:21

Currently Auth Caches configuration options (capacity/validity/updateinterval/activeupdate) exposed via JMX or yaml only. We need to introduce a _nodetool setauthcachecconfig_ and _nodetool getauthcachecconfig_ commands.

Also we could think of some VT-based alternative to {_}nodetool{_}. But I feel there is no need to have a separate table for Auth Caches configs. It would be an overhead. Ideally we need to have a separate VT that shows/sets all the configs, but it is out of the scope.
Bug: v4+ protocol did not clean up client warnings, which caused leaking the state
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 21/Oct/21 18:15
Resolved: 25/Oct/21 15:44

If you perform a query in v5, this will cause the STARTUP message to be handled in the netty thread, but the way this is done is by calling an internal API to dispatcher which requires the caller to clean up; but we do not clean up; at this point the netty thread will have a ClientWarn state populated.  If you now perform the same query again, but with the v3 protocol, this will pick up the state and try to serialize it, causing a client error (in java as java rejects the output from the server) saying that v3 may not have client warnings.
Bug: Guardrails for collection items and size
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 15/Nov/21 18:39
Resolved: 15/Mar/22 13:34

Add guardrails for the number of items and size of collections. For example:

{code}
# Guardrail to warn or fail when encountering larger size of collection data than threshold.
# The two thresholds default to 0KiB to disable.
collection_size_warn_threshold: 0KiB
collection_size_fail_threshold: 0KiB

# Guardrail to warn or fail when encountering more elements in collection than threshold.
# The two thresholds default to -1 to disable.
items_per_collection_warn_threshold: -1
items_per_collection_fail_threshold: -1
{code}
Bug: Eliminate toCQLString() duplication between ReadCommand and AbstractReadQuery
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 05/Oct/21 20:56
Resolved: 25/Oct/21 14:24

This is certainly low-hanging fruit, but the {{toCQLString()}} in {{ReadCommand}} now entirely duplicates the one in its superclass {{AbstractReadQuery}}. I think we can just remove the former.
Bug: LocalReadSizeWarningTest#failThresholdSinglePartition is flaky
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 16/Dec/21 19:53
Resolved: 12/Apr/22 20:24

The test {{org.apache.cassandra.distributed.test.trackwarnings.LocalReadSizeWarningTest#failThresholdSinglePartition}} seems to be flaky.

It was discovered during CASSANDRA-17195 with [this CI run|https://app.circleci.com/pipelines/github/adelapena/cassandra/1217/workflows/b366e352-0862-485a-acdc-5b75fe1ef575/jobs/11188].

The failure can be reproduced running the test repeatedly for trunk, as it can be seen [here|https://app.circleci.com/pipelines/github/adelapena/cassandra/1219/workflows/a0c1fb7f-8a07-4fcf-97a4-7caf207dad78].
Bug: DOC - Fix multiple headers, formatting on Monitoring page
Status: Resolved
Priority: Normal
Resolution: Duplicate
Created: 24/Oct/21 10:08
Resolved: 31/Mar/22 08:03

[~azotcsit] reported on [ASF Slack|https://the-asf.slack.com/archives/C01RY1LUPD5/p1635066428010900] that several sections are formatted incorrectly on the [Monitoring|https://cassandra.apache.org/doc/latest/cassandra/operating/metrics.html] page.

For example, the *Table Metrics* section appears as:
 !website-monitoring-01-table_metrics.png|width=300! 
 The following sections don't render correctly:
 * Keyspace Metrics
 * Threadpool Metrics
 * Client Request Metrics
 * Cache Metrics

For example:
 !website-monitoring-02-keyspace_metrics.png|width=300!
Bug: Guardrail for partition size
Status: Resolved
Priority: Normal
Resolution: Duplicate
Created: 15/Nov/21 18:32
Resolved: 18/Mar/22 13:27

Add a guardrail for large partitions. Finding the size of a partition is tricky because partitions can be spread over multiple sstable and we want to avoid read before write. Thus, this might be just a warning thrown during compaction and not be linked to specific user queries, for example:
{code}
# Log a warning when compacting partitions larger than this value.
# Defaults to -1 to disable
# partition_size_warn_threshold_in_mb: -1
{code}
Bug: Consistency Level Considered Connectivity Checker
Status: Review In Progress
Priority: Normal
Created: 21/Dec/21 19:06

The connectivity checker runs during the startup of Cassandra, more specifically right after {{CassandraDaemon#setup}}. In general, it blocks for a certain period of time in order to establish connections with the peers in the cluster. The blocking is a best-effort one, meaning that the checker allows Cassandra to continue booting even if the criteria is not met.

The Consistency Level Considered Connectivity Checker prioritizes the peers to connect, while still satisfying the desired Consistency Level. The goal of the new connectivity checker is to solve the read unavailable/timeout.

The Consistency Level Considered Connectivity Checker (CL checker) uses the consistency level specified by the {{block_for_peers_consistency_level}} property to determine the number of peers to wait for in the local or remote datacenter before offering itself as a coordinator. Subject to the timeout specified by {{block_for_peers_timeout_in_secs}}.

The supported values for the CL checker are {{ALL}}, {{QUORUM}}, {{LOCAL_QUORUM}}, and {{EACH_QUORUM}}. The value is specified in the {{block_for_peers_consistency_level}} property defined in {{cassandra.yaml}}. The default consistency level is {{LOCAL_QUORUM}}.

During the connectivity checker execution, peers are categorized into primary and secondary peers, such that primary peers are the sufficient number of peers required to satisfy the consistency level specified in {{block_for_peers_consistency_level}}. If the connection fails to any of the primary peers, additional connections are performed to secondary peers, and after the {{block_for_peers_timeout_in_secs}} timeout, validation is performed to make sure the CL is satisfied for all the natural replicas for every node.

The CL checker does not support vnodes.
Bug: CEP-15: (C*) Unified Commit Log
Status: Triage Needed
Priority: Normal
Created: 30/Oct/21 11:05

Create a new data structure and system for combining Commit Log and Hints. This system will support compaction of commit log segments when the commit log is under space pressure, but under normal operation will continue to drop entire log records as soon as they become invalidated. By ensuring compaction only occurs for segments that are under 50% utilised we bound space and bandwidth at 2x optimal (and can tune this trade-off if we prefer, e.g. trading more space for less bandwidth)

This system will replace the storage layer for Commit Log and Hints, and be used to implement distributed repair for Accord (and perhaps other systems in future)
Bug: CEP-15: (C*) Unique Per-Node Id for (Time)UUID
Status: Triage Needed
Priority: Normal
Created: 30/Oct/21 11:04

Negotiate a unique and persistent id for each node on joining the cluster that is sufficiently compact to use for the  node part of a v2, v6 or v8 (Time)UUID, i.e. it should be at most 48 bits in length. In practice we should be able to target 7, 14 or 21 bits in length depending on cluster size, permitting more efficient vint encoding over the network and on disk.

A seemingly simpler option for issuing UUID might be to use the NIC MAC address, but this assumes each C* process has a unique NIC, and that all nodes in the cluster are on the same network. This is likely often true, but may not be universally, so we may need a mechanism for issuing unique IDs when clashes occur, in which case it may be easier to just issue the most compact ID we can in the first place.

Accord will use this value directly as part of its {{Timestamp}} which is very similar to a UUID but may have additional components. Accord may utilise this ID to uniquely identify the issuing node within the cluster, which the MAC address may not easily achieve as it may vary for the same logical node over time e.g. if the NIC is replaced - though a record of recent MAC addresses could be maintained.
Bug: Fix test: bootstrap_test.py::TestBootstrap::test_bootstrap_with_reset_bootstrap_state
Status: Resolved
Priority: Normal
Resolution: Duplicate
Created: 28/Oct/21 19:11
Resolved: 02/Nov/21 18:17

Seeing in circle and locally on trunk:

Looks like it's timing out waiting for the bootstrap to complete.
{code:java}
test_bootstrap_with_reset_bootstrap_state failed (1 runs remaining out of 2).
        <class 'ccmlib.node.TimeoutError'>
        28 Oct 2021 19:03:53 [node3] after 120.39/120 seconds Missing: ['127.0.0.1:7000.* is now UP'] not found in system.log:
 Head: ERROR [Stream-Deserializer-/127.0.0.1:7000-20b885c
 Tail: ...b336de0e72/nb-1-big-Data.db 
ERROR [Stream-Deserializer-/127.0.0.1:7000-29a7cdb5] 2021-10-28 15:01:36,578 StorageService.java:483 - Stopping gossiper

        [<TracebackEntry /Users/jmckenzie/src/cassandra-dtest/bootstrap_test.py:483>
<TracebackEntry /Users/jmckenzie/src/ccm/ccmlib/node.py:895>
<TracebackEntry /Users/jmckenzie/src/ccm/ccmlib/node.py:664>
<TracebackEntry /Users/jmckenzie/src/ccm/ccmlib/node.py:588>
<TracebackEntry /Users/jmckenzie/src/ccm/ccmlib/node.py:56>]
test_bootstrap_with_reset_bootstrap_state failed; it passed 0 out of the required 1 times.
        <class 'ccmlib.node.TimeoutError'>
        28 Oct 2021 19:08:23 [node3] after 120.41/120 seconds Missing: ['127.0.0.1:7000.* is now UP'] not found in system.log:
 Head: 
 Tail: ...
        [<TracebackEntry /Users/jmckenzie/src/cassandra-dtest/bootstrap_test.py:483>
<TracebackEntry /Users/jmckenzie/src/ccm/ccmlib/node.py:895>
<TracebackEntry /Users/jmckenzie/src/ccm/ccmlib/node.py:664>
<TracebackEntry /Users/jmckenzie/src/ccm/ccmlib/node.py:588>
<TracebackEntry /Users/jmckenzie/src/ccm/ccmlib/node.py:56>]
{code}
Bug: Broken API link on Cassandra Cloud Offering page
Status: Triage Needed
Priority: Normal
Created: 12/Dec/21 22:00

In the Cassandra document page: [https://cassandra.apache.org/_/ecosystem.html,] the API link for Azure Cosmos DB Cassandra API is broken because of incorrect asciidoc formatting, see below:

https://docs.microsoft.com/en-us/azure/cosmos-db/cassandra-introduction[Azure Cosmos DB Cassandra API,window=_blank]: Enables you to interact with data stored in https://docs.microsoft.com/en-us/azure/cosmos-db/introduction[Azure Cosmos DB,window=_blank] using the Cassandra Query Language (CQL) , Cassandra-based tools (like cqlsh) and Cassandra client drivers that you're already familiar with.</p>
Bug: Node can be left in a bad state after invalid memory access exception
Status: Triage Needed
Priority: Normal
Created: 21/Dec/21 02:15

There were a few reports of errors containing the following exception: {noformat}java.lang.InternalError: a fault occurred in a recent unsafe memory access operation in compiled Java {noformat} (CASSANDRA-8642, CASSANDRA-5737, CASSANDRA-11201, CASSANDRA-13091), normally closed as invalid due to the difficulty in reproducing it.

This exception can be thrown in a [variety of scenarios|https://stackoverflow.com/a/45536678] generally involving a kernel fault during unsafe memory access.

I've seen an occurence of this issue where the node went into a bad state after a memory access error.

I believe this exception should be treated analogous to `OutOfMemoryException` (CASSANDRA-13006 ) and cause the process to crash if/when encountered, perhaps guarded by a flag.
Bug: The process cannot access the file because it is being used by another process.
Status: Triage Needed
Priority: Normal
Created: 15/Dec/21 04:10

 
ERROR [COMMIT-LOG-ALLOCATOR] 2021-12-11 17:02:00,989 JVMStabilityInspector.java:140 - JVM state determined to be unstable.  Exiting forcefully due to:
org.apache.cassandra.io.FSWriteError: java.nio.file.FileSystemException: <basePath>\commitlog\CommitLog-6-1636406548826.log: The process cannot access the file because it is being used by another process.
 
    at org.apache.cassandra.io.util.FileUtils.deleteWithConfirm(FileUtils.java:138) ~[apache-cassandra-3.0.14.jar:3.0.14]
    at org.apache.cassandra.io.util.FileUtils.deleteWithConfirm(FileUtils.java:155) ~[apache-cassandra-3.0.14.jar:3.0.14]
    at org.apache.cassandra.db.commitlog.CommitLogSegment.discard(CommitLogSegment.java:342) ~[apache-cassandra-3.0.14.jar:3.0.14]
    at org.apache.cassandra.db.commitlog.CommitLogSegmentManager$2.run(CommitLogSegmentManager.java:379) ~[apache-cassandra-3.0.14.jar:3.0.14]
    at org.apache.cassandra.db.commitlog.CommitLogSegmentManager$1.runMayThrow(CommitLogSegmentManager.java:156) ~[apache-cassandra-3.0.14.jar:3.0.14]
    at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28) [apache-cassandra-3.0.14.jar:3.0.14]
    at org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:79) [apache-cassandra-3.0.14.jar:3.0.14]
    at java.lang.Thread.run(Unknown Source) ~[na:1.8.0_301]
Caused by: java.nio.file.FileSystemException: <basePath>\commitlog\CommitLog-6-1636406548826.log: The process cannot access the file because it is being used by another process.
 
    at sun.nio.fs.WindowsException.translateToIOException(Unknown Source) ~[na:1.8.0_301]
    at sun.nio.fs.WindowsException.rethrowAsIOException(Unknown Source) ~[na:1.8.0_301]
    at sun.nio.fs.WindowsException.rethrowAsIOException(Unknown Source) ~[na:1.8.0_301]
    at sun.nio.fs.WindowsFileSystemProvider.implDelete(Unknown Source) ~[na:1.8.0_301]
    at sun.nio.fs.AbstractFileSystemProvider.delete(Unknown Source) ~[na:1.8.0_301]
    at java.nio.file.Files.delete(Unknown Source) ~[na:1.8.0_301]
    at org.apache.cassandra.io.util.FileUtils.deleteWithConfirm(FileUtils.java:132) ~[apache-cassandra-3.0.14.jar:3.0.14]
    ... 7 common frames omitted

It seems similar to https://issues.apache.org/jira/browse/CASSANDRA-8390, but it was resolved in 2.2 beta, though I am facing this in version 3.0.14

I am running this on windows server OS and in cassandra.yaml, disk_access_mode is set to standard
Bug: Synthetic heap OOM generation should only run with the presence of on OOM JVM options
Status: Triage Needed
Priority: Normal
Created: 22/Dec/21 17:58

The synthetic heap OOM generation introduced in CASSANDRA-15214 assumes Cassandra always runs with the related on OOM JVM options, e.g. -XX:+ExitOnOutOfMemoryError. So that the synthetic heap OOM can trigger the handler.

If the Cassandra process does not start with any of those on OOM options, the synthetic heap OOM generation should not run.
Bug: Is Cassandra vulnerable to CVE-2021-44228?
Status: Resolved
Priority: Normal
Resolution: Invalid
Created: 14/Dec/21 20:21
Resolved: 14/Dec/21 20:30

Hello,

I'm not sure how/where to ask so this would be stupid if the answer is "no", but considering the popularity of CVE-2021-44228 bug I would like to ask if cassandra could be affected and if yes, what version do I need to update to or what else to do.

   Honza
Bug: Arrow to SSTable converter
Status: Resolved
Priority: Normal
Resolution: Invalid
Created: 10/Dec/21 08:50
Resolved: 10/Dec/21 12:49

Hi,

I hope this is the good project to ask for this. Recently this project to convert SSTables to Arrow allowed to analyse Cassandra data on GPU:
[https://developer.nvidia.com/blog/analyzing-cassandra-data-using-gpus-part-2/]

I'm wondering if an Arrow to SSTable would be feasible? In practice we envision using it to  to quickly process our parquet files on GPU and upload them faster to Cassandra.

I also brought this up with the RAPIDS team and Datastax:
[https://github.com/rapidsai/cudf/issues/9811]

[https://github.com/datastax/sstable-to-arrow/issues/1]

Cheers,

Michaël
Bug: " as first char of a text column (and unique occurrence) during COPY with DELIMITER set to |
Status: Open
Priority: Normal
Created: 09/Dec/21 10:03

Connected to Test Cluster at 127.0.0.1:9042.
[cqlsh 5.0.1 | Cassandra 3.11.11 | CQL spec 3.4.4 | Native protocol v4]

During an import using | as delimiter, e.g.:

COPY cy4secure_company_demo.demo_contacts_clear (record_id,state,city,first_name,last_name,email,salary,credit_rating,debt,ssn,liabilities,comments,picture) FROM '/var/www/cy4secure/csv/001_demo_contacts_clear_100000.csv' WITH DELIMITER='|' AND NUMPROCESSES=2 AND MAXBATCHSIZE=1 AND CHUNKSIZE=50 AND SKIPROWS=2;


Yep you can have double-quotes and quotes in a text column, no problem, example:

{{<other fields>...|Earth {color:#FF0000}"{color}observation{color:#FF0000}"{color} taken {color:#FF0000}'{color}during{color:#FF0000}'{color} a day pass by...|...<other fields>}}

BUT if you have a unique " at the beginning it fails, example:

<other fields>...|{color:#FF0000}"{color}Earth observation taken during a day pass by...|...<other fields>

This results in my case with: Failed to import 1 rows: ParseError - Invalid row length 12 should be 13,  given up without retries

And the rows part of the chunk are not imported.

My workaround: filter text values that starts with a ".

Otherwise, you'll probably want to take a look at it.
Bug: Found Third Party Software  vulnerabilities/security issue in 3.11.11
Status: Resolved
Priority: Normal
Resolution: Duplicate
Created: 24/Nov/21 13:11
Resolved: 24/Nov/21 13:19

we have found below vulnerabilities  in Cassandra 3.11.11.zip during security scan.

Could you please help us to resolve those?
| [sonatype-2021-1175] [logback-core] [1.1.3]|
| [CVE-2021-37137] [netty-all] [4.0.44.Final]|
| [sonatype-2021-1425] [thrift] [0.9.3]|
| [sonatype-2020-1031] [netty-all] [4.0.44.Final]|
| [CVE-2020-13949] [libthrift] [0.9.2]|
| [sonatype-2020-0029] [netty-all] [4.0.44.Final]|
| [CVE-2020-7238] [netty-all] [4.0.44.Final]|
| [CVE-2019-20444] [netty-all] [4.0.44.Final]|
| [CVE-2019-20445] [netty-all] [4.0.44.Final]|
| [CVE-2017-18640] [snakeyaml] [1.11]|
| [CVE-2019-16869] [netty-all] [4.0.44.Final]|
| [CVE-2019-0205] [thrift] [0.9.3]|
| [CVE-2018-1320] [libthrift] [0.9.2]|
| [CVE-2017-5929] [logback-classic] [1.1.3]|
|*[sonatype-2017-0312] [jackson-databind] [2.9.10.8]*|
Bug: Migrate thresholds for GC pauses to guardrails
Status: Triage Needed
Priority: Normal
Created: 06/Dec/21 17:56

Migrate the existing thresholds for GC pauses:
{code}
# gc_log_threshold_in_ms: 200
# gc_warn_threshold_in_ms: 1000
{code}
to a new guardrail under the guardrails section, for example:
{code}
guardrails:
    ...
    gc_pauses:
        log_threshold_in_ms: 200
        warn_threshold_in_ms: 200
{code}
Note that currently {{Threshold}} guardrails only have warn/abort threshold values, so we should consider adding a new {{log}} threshold value if we want to preserve the log-only functionality for this particular case.
Bug: Migrate thresholds for scanned tombstones to guardrails
Status: Triage Needed
Priority: Normal
Created: 06/Dec/21 15:39

Migrate the two existing thresholds for scanned tombstones:
{code:java}
tombstone_warn_threshold: 1000
tombstone_failure_threshold: 100000
{code}
to a new guardrail under the {{guardrails}} section, for example:
{code:java}
guardrails:
    ...
    # Guardrail to warn or abort when reading more tombstones than threshold. 
    scanned_tombstones:
        warn_threshold: 1000
        abort_threshold: 100000 {code}
At the moment these thresholds are enabled by default, while guardrails are globally disabled by default, so we should consider whether we want to globally enable guardrails, or change these thresholds to disabled by default, or don't migrate the thresholds.
Bug: Migrate the thresholds for RFP cached rows to guardrails
Status: Triage Needed
Priority: Normal
Created: 06/Dec/21 17:00

Migrate the existing thresholds for replica filtering protection:
{code}
replica_filtering_protection:
    cached_rows_warn_threshold: 2000
    cached_rows_fail_threshold: 32000
{code}
To a new guardrail under the {{guardrails}} section, for example:
{code}
guardrails:
    ...
    replica_filtering_protection_cached_rows:
        warn_threshold: 2000
        abort_threshold: 32000
{code}
At the moment these thresholds are enabled by default, while guardrails are globally disabled by default, so we should consider whether we want to globally enable guardrails, or change these thresholds to disabled by default, or don't migrate the thresholds.
Bug: Using the user specified page size for internal paging in GROUP BY queries can slow down the query and create high traffic between nodes
Status: Triage Needed
Priority: Normal
Created: 03/Dec/21 09:06

When performing aggregation queries or GROUP BY queries Cassandra compute the aggregates on the coordinator node to ensure consistency and request the data by pages (numbers of rows). Today, Cassandra use as internal page size the page size requested by the user (the number of rows that should be returned to the user). By consequence, if the page size requested by the user is too small the number of request performed by the node will be much higher.

For 1,000,000 rows, a consistency level of LOCAL_QUORUM and a page size of 5,000 the coordinator will contact 200 times the replicas. For a page size of 100 (CQLSH page size) the coordinator will contact 10,000 times the replicas.

To avoid this problem we should have a minimum page size for the internal paging and the possibility for the operators to change its value.
Bug: In the paxos implementation, a delayed proposal might overwrite newer values
Status: Resolved
Priority: Normal
Resolution: Not A Problem
Created: 18/Nov/21 10:04
Resolved: 18/Nov/21 11:05

I was going through this blog post , which talks about a possible bug in paxos implementation if in-progress ballot is not set while accepting a proposal.
[https://brooker.co.za/blog/2021/11/16/paxos.html]

I tried writing a failing test and possible fix. 

The in_progress_ballot needs to be set when accepting a proposal. The current implementation sets only the proposal_ballot when accepting a proposal.