av9ash/GitBugs huggingface dataset:
Bug: CEP-29: NOT Operator SAI acceleration
Status: Open
Priority: Normal
Created: 18/Sep/24 15:49

This is a spin-off ticket from CEP-29 to add SAI acceleration for the NOT operator.
There is a WIP branch here that can be taken over and finished:
https://github.com/ekaterinadimitrova2/cassandra/tree/C18584-and-sai

We need to ensure we follow the Three-valued logic.
Identified limitations of the current branch:
* TTL and NOT CONTAINS in collections because they may not be null after expiring if they have other items.

{code:java}
Example:
cqlsh:test> create table sets(pk int primary key, s set<int>);
cqlsh:test> create custom index on sets(s) using 'StorageAttachedIndex';

cqlsh:test> insert into sets(pk, s) values (1, {1, 2, 3, 4});
cqlsh:test> update sets using ttl 30 set s = s+{5} where pk = 1;

// run nodetool flush here

cqlsh:test> select * from sets;

 pk | s
----+-----------------
  1 | {1, 2, 3, 4, 5}

// wait 30 seconds

cqlsh:test> select * from sets;

 pk | s
----+--------------
  1 | {1, 2, 3, 4}                      // <---- see? the row does not contain 5

(1 rows)
cqlsh:test> select * from sets where s not contains 5;   

 pk | s
----+---
                                            // <---- but we don't return it, ouch
(0 rows)
{code}

* For NEQ and maps, the current implementation will return everything that does not match the exact entry.

{code:java}
Example:

execute("INSERT INTO %s(k, v, m) values (1, 0, {1:1, 2:2})");
execute("INSERT INTO %s(k, v, m) values (2, 0, {1:1, 3:3})");
execute("INSERT INTO %s(k, v, m) values (3, 0, {4:4, 5:5})");
execute("INSERT INTO %s(k, v, m) values (4, 0, {1:10, 2:20})");
execute("INSERT INTO %s(k, v, m) values (5, 0, {1:10, 3:30})");
execute("INSERT INTO %s(k, v, m) values (6, 0, {4:40, 5:50})");
// not equals entries
test("SELECT k FROM %s WHERE m[1] != 1",
        !hasIndex("me"),
        hasIndex("me"),
        row(3), row(4), row(5), row(6));
{code}

The SELECT statement should return only row(4) and row(5).

To get it to work, we'll need the NEQ operator to have the key and to do two checks on the map entry, one to check the key and another to check the value (the Composite Type complicates things). Wondering if this part can be another follow-up ticket where someone can work on !=, >, <, <=, >=. Leaving this to whoever decides to assign this ticket.

* Tests show that there is some work needed around Empty Index

Overall the branch needs thorough review and fixes.
Bug: [Analytics] Deprecate old compression cache and move to using cache of CompressionMetadata
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 17/Sep/24 17:11
Resolved: 17/Sep/24 22:53

The compression cache currently caches a single byte array for the CompressionInfo.db file, this is a problem for large files as it involves allocating and garbage collecting large memory segments, but also means that every consumer of the bytes will instantiate a CompressionMetadata object and allocate an individual BigLongArray to store the chunk offsets. This is unnecessary as the CompressionMetadata is immutable and can be re-used.
Bug: In-jvm dtest to detect InstanceClassLoaderLeaks
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 18/Jul/24 17:12
Resolved: 17/Sep/24 21:24

It is currently very easy to add dependencies/code that cause in-jvm dtest {{InstanceClassLoader}} leaks, and hard to find them. These patches add a WeakHashSet that allows us to count the number of reachable InstanceClassLoaders in the in-jvm dtest API, so that we can use it in the ResourceLeakTest in the actual Cassandra branches in CI (it only takes 2 iterations to find the leak recently introduced by the inclusion of the {{oshi.jna}}  library, which was fixed in [https://github.com/apache/cassandra-in-jvm-dtest-api/pull/38])

Notes:

The trunk patch +requires+ the changes made in the in-jvm-dtest-api project in order to compile.

Additionally, ResourceLeakTest#looperEverythingTest (the newly-enabled test) won't fail once we pick up the changes made to include `osha.jna` in the in-jvm-dtest-api project, so I added some "DO NOT COMMIT" code there to prove the test can in fact detect the leak.

 

NOTE: I'm removing the `DO NOT COMMIT` code that demonstrates the test actually fails when there's a leak. If you want to try it out, you can change the line 202 in ResourceLeakTest.java to this: 

 
{code:java}
            try (Cluster cluster = (Cluster) builder.withNodes(numClusterNodes).withConfig(updater)
                    .withSharedClasses(builder.getSharedClasses().and(name -> !name.startsWith("oshi.jna.")))
                    .start())
{code}
This removes the `oshi.jna` classes from the shared class loader, which demonstrates the failure.
Bug: CEP-15 (C*) increase message timeouts for range barrier messages
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 16/Sep/24 19:54
Resolved: 16/Sep/24 23:10

Messages involved in the coordination of accord barriers and sync points can take longer than those involved in typical operations and are not blocking client requests. Subjecting them to the same timeouts as client operations can destabilize the system by preventing background bookkeeping operations from completing and putting them into a retry loop. This patch special cases the timeouts for messages coordinating range barriers.
Bug: Add snapshot repo aliasing to build.properties.default and build-resolver.xml
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 31/Jul/24 17:27
Resolved: 16/Sep/24 20:05

Currently {{resolver-apache-snapshot}} is hard-coded in {{build-resolver.xml}} and overriding it isn't supported in {{build.properties.default}}. Further, the comment on that repository in {{build-resolver.xml}} is... rather confusing, since it states we don't support it and to uncomment it out if you need it, but then it's already uncommented out.

We should just support aliasing the snapshot repo the way we do the others.
Bug: Function inference can fail when on a reversed clustering column
Status: Open
Priority: Normal
Created: 12/Sep/24 21:20

{code}
createTable("CREATE TABLE %s(pk smallint, ck smallint, v smallint, PRIMARY KEY(pk, ck)) WITH CLUSTERING ORDER BY (ck DESC)");
execute("INSERT INTO %s(pk, ck, v) VALUES (-42 + -42, 42 + 42, -8200 + -16990)");
{code}

Result

{code}
org.apache.cassandra.exceptions.InvalidRequestException: Ambiguous '+' operation with args 42 and 42: use type hint to disambiguate, example '(int) ?'

	at org.apache.cassandra.cql3.statements.RequestValidations.invalidRequest(RequestValidations.java:370)
	at org.apache.cassandra.cql3.functions.FunctionResolver.pickBestMatch(FunctionResolver.java:179)
	at org.apache.cassandra.cql3.functions.FunctionResolver.get(FunctionResolver.java:87)
	at org.apache.cassandra.cql3.functions.FunctionCall$Raw.prepare(FunctionCall.java:154)
	at org.apache.cassandra.cql3.terms.Terms$Raw$2.prepare(Terms.java:280)
	at org.apache.cassandra.cql3.Relation.toRestriction(Relation.java:178)
	at org.apache.cassandra.cql3.restrictions.StatementRestrictions.<init>(StatementRestrictions.java:218)
	at org.apache.cassandra.cql3.restrictions.StatementRestrictions.<init>(StatementRestrictions.java:157)
	at org.apache.cassandra.cql3.statements.UpdateStatement$ParsedInsert.prepareInternal(UpdateStatement.java:227)
	at org.apache.cassandra.cql3.statements.ModificationStatement$Parsed.prepare(ModificationStatement.java:1077)
	at org.apache.cassandra.cql3.statements.ModificationStatement$Parsed.prepare(ModificationStatement.java:1064)
	at org.apache.cassandra.cql3.statements.ModificationStatement$Parsed.prepare(ModificationStatement.java:1036)
{code}

This was found by CASSANDRA-19769, and looks to be the same issue (just different path) as CASSANDRA-19781
Bug: Fix incorrect nodetool suggestion when gossip mode is running
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 09/Sep/24 16:59
Resolved: 12/Sep/24 20:16

In trunk, when data directories were present with older system tables starting up Cassandra produces the following error:

{code:java}
NoHostAvailable: ('Unable to complete the operation against any hosts', {<Host: 127.0.0.1:9042 datacenter1>: <Error from server: code=0000 [Server error] message="java.lang.IllegalStateException: Can't commit transformations when running in gossip mode. Enable the ClusterMetadataService with `nodetool addtocms`.">})
{code}

The correct error message should state the the command to run is {{nodetool cms initialize}} instead.
Bug: The build-dependencies.sh can set CASSANDRA_USE_JDK11=true if analytics is running on JDK11 to avoid build failures in the integration tests when compiled.
Status: Patch Available
Priority: Normal
Created: 12/Sep/24 17:19

The build-dependencies.sh script can set CASSANDRA_USE_JDK11=true if analytics is running on JDK11 to avoid build failures in the integration tests when compiled.
Bug: Removed MemtableSizeTest test re-appeared after a merge
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 11/Sep/24 17:24
Resolved: 12/Sep/24 07:19

As a part of CASSANDRA-17298 [https://github.com/apache/cassandra/blob/cassandra-4.1/test/unit/org/apache/cassandra/cql3/MemtableSizeTest.java] test was removed and replaced with other tests (commit. [https://github.com/apache/cassandra/commit/c56ba3b317e67f4530db1737169f5558969bd531#diff-e7b2385cd817d698d35bdeffea2d4cb765653e2e3eb13fa22abfb070fed05a8f]) but it is still in the repository for 4.1 (looks like a merge issue).

This old test needs to be deleted.
Bug: [Analytics] Add writer option COORDINATED_WRITE_CONFIG to define coordinated write to multiple Cassandra clusters
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 10/Sep/24 19:36
Resolved: 12/Sep/24 04:04

As the first step of implementing coordinated write to multiple Cassandra clusters, this patch introduces the new writer option, COORDINATED_WRITE_CONFIG and the optional clusterId to identify clusters. The COORDINATED_WRITE_CONFIG value is a json string that defines the target clusters for the bulk write.

The coordinated write feature requires the exact same table schema (not including table properties) across clusters.
Bug: make buffer size in AsyncStreamingOutputPlus configurable when using SSL
Status: Triage Needed
Priority: Normal
Created: 12/Sep/24 01:25

When streaming with SSL, we use a hardcoded buffer size of 64KB.  On local disks this is probably OK, but when dealing with devices that have an IOPS quota it might not be optimal.  For example, with EBS you can read up to 256KB on a single operation.  

If we make this configurable, we can either reduce IOPS usage by a factor of 4 or 4x the maximum throughput for a given device configuration.  This will result in either more reliable system performance, faster streaming, or both.

The relevant code is here:


{noformat}
  /**
     * Writes all data in file channel to stream: <br>
     * * For zero-copy-streaming, 1MiB at a time, with at most 2MiB in flight at once. <br>
     * * For streaming with SSL, 64KiB at a time, with at most 32+64KiB (default low water mark + batch size) in flight. <br>
     * <p>
     * This method takes ownership of the provided {@link FileChannel}.
     * <p>
     * WARNING: this method blocks only for permission to write to the netty channel; it exits before
     * the {@link FileRegion}(zero-copy) or {@link ByteBuffer}(ssl) is flushed to the network.
     */
    public long writeFileToChannel(FileChannel file, RateLimiter limiter) throws IOException
    {
        if (channel.pipeline().get(SslHandler.class) != null)
            // each batch is loaded into ByteBuffer, 64KiB is more BufferPool friendly.
            return writeFileToChannel(file, limiter, 1 << 16);
        else
            // write files in 1MiB chunks, since there may be blocking work performed to fetch it from disk,
            // the data is never brought in process and is gated by the wire anyway
            return writeFileToChannelZeroCopy(file, limiter, 1 << 20, 1 << 20, 2 << 20);
    }
{noformat}
Bug: SIGSEGV crash when FastByteOperations.copy is given a read-only ByteBuffer
Status: Open
Priority: Normal
Created: 11/Sep/24 22:03

{code}
@Test
public void jvmCrash()
{
    ByteBuffer src = ByteBufferUtil.bytes(42).asReadOnlyBuffer();
    ByteBuffer buffer = ByteBuffer.allocate(4);
    FastByteOperations.copy(src, src.position(),
                            buffer, buffer.position(),
                            src.remaining());
}
{code}

This crashes the JVM with the following

{code}
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00000001015c6810, pid=30607, tid=5379
#
# JRE version: OpenJDK Runtime Environment JDK-11.0.15.10.2 (build 11.0.15+10-LTS)
# Java VM: OpenJDK 64-Bit Server VM JDK-11.0.15.10.2 (11.0.15+10-LTS, mixed mode, compressed oops, concurrent mark sweep gc, bsd-aarch64)
# Problematic frame:
# V  [libjvm.dylib+0x6f6810]  Unsafe_GetByte(JNIEnv_*, _jobject*, _jobject*, long)+0xb8
#
# No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# /Users/dcapwell/src/github/apache/cassandra/cep-15-accord/hs_err_pid30607.log
#
# If you would like to submit a bug report, please visit:
#   https://bugreport.java.com/bugreport/crash.jsp
#

Process finished with exit code 134 (interrupted by signal 6: SIGABRT)
{code}

And the stack trace is

{code}
Stack: [0x000000016fc68000,0x000000016fccb000],  sp=0x000000016fcc95b0,  free space=389k
Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.dylib+0x6f6810]  Unsafe_GetByte(JNIEnv_*, _jobject*, _jobject*, long)+0xb8
j  jdk.internal.misc.Unsafe.getByte(Ljava/lang/Object;J)B+0 java.base@11.0.15
j  sun.misc.Unsafe.getByte(Ljava/lang/Object;J)B+5 jdk.unsupported@11.0.15
j  org.apache.cassandra.utils.FastByteOperations$UnsafeOperations.copy(Ljava/lang/Object;J[BII)V+35
j  org.apache.cassandra.utils.FastByteOperations$UnsafeOperations.copy(Ljava/lang/Object;JLjava/nio/ByteBuffer;II)V+22
j  org.apache.cassandra.utils.FastByteOperations$UnsafeOperations.copy(Ljava/nio/ByteBuffer;ILjava/nio/ByteBuffer;II)V+54
j  org.apache.cassandra.utils.FastByteOperations.copy(Ljava/nio/ByteBuffer;ILjava/nio/ByteBuffer;II)V+9
j  org.apache.cassandra.utils.FastByteOperationsTest.jvmCrashV2()V+28
{code}

The issue is that we think the read only BB doesn’t have an array even though its a heap buffer, so we try to do direct memory access and crash.

This was found in testing and I don’t see the code call “asReadOnlyBuffer” at all, so this looks localized to testing and not a production environment.
Bug: Fix Journal segment allocation/switch race condition
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 26/Aug/24 20:49
Resolved: 09/Sep/24 14:08

Concurrent r/w workload is currently throwing:
{code}
java.lang.IllegalArgumentException: Can not reference segment 1724695101990
        at org.apache.cassandra.journal.Segments.isFlushed(Segments.java:189)
        at org.apache.cassandra.journal.Journal.isFlushed(Journal.java:199)
        at org.apache.cassandra.journal.Journal$FlusherCallbacks.submit(Journal.java:151)
        at org.apache.cassandra.journal.Journal.onFlush(Journal.java:204)
        at org.apache.cassandra.service.accord.AccordJournal.appendCommand(AccordJournal.java:264)
        at org.apache.cassandra.service.accord.AccordCommandStore.appendCommands(AccordCommandStore.java:579)
        at org.apache.cassandra.service.accord.async.AsyncOperation.runInternal(AsyncOperation.java:277)
        at org.apache.cassandra.service.accord.async.AsyncOperation.run(AsyncOperation.java:303)
        at org.apache.cassandra.service.accord.async.AsyncOperation.onLoaded(AsyncOperation.java:169)
        at accord.utils.async.AsyncCallbacks.lambda$inExecutorService$0(AsyncCallbacks.java:36)
        at org.apache.cassandra.concurrent.ExecutionFailure$1.run(ExecutionFailure.java:133)
        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: [Analytics] Refactor TokenRangeMapping to use proper types instead of Strings
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 05/Sep/24 21:43
Resolved: 07/Sep/24 04:09

Proposing the refactoring of TokenRangeMapping and the related classes to use proper types instead of String to improve maintainability. As of now, String are used to represent IP, IP with port, node name, etc. It is difficult to distinguish the actual types.
Bug: ant artifacts creates -src.tar.gz with .build/docker/*.sh scripts not having execution flag set
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 04/Sep/24 12:34
Resolved: 06/Sep/24 08:28

Execution flags in that directory for shell scripts are set when cloned from the repository. We should have this aligned otherwise ".build/docker/build-debian.sh" and similar do not work on source artifacts without having a user fixing that on her own.
Bug: [Analytics] Removes checks for blocked instances from bulk-write path
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 27/Aug/24 17:51
Resolved: 05/Sep/24 20:24

The analytics bulk writer currently performs checks for blocked instances for consistency-level validations prior-to and after the bulk-write. It also takes all the blocked nodes into account for these validations instead of the nodes in the specific range being written (addressed separately under https://issues.apache.org/jira/browse/CASSANDRA-19842).

 

This change removes the notion of blocked instances for bulk-writes, treating such nodes as available, as the intended usage of "blocked" nodes is to operationally prevent client CQL connections going into the node, but not writes.
Bug: Vectors of counter as subtype do not work as expected
Status: Open
Priority: Normal
Created: 04/Sep/24 07:42

Here is the current behavior:
{code:java}
cqlsh:default> create table counter_table ( i int PRIMARY KEY, j vector<counter,2> );

cqlsh:default> insert into counter_table (i, j) values (0, [0,0]);
cqlsh:default> select * from counter_table;

 i | j
---+----------------------------------------
 0 | [576460752303423488, 2251799813685248]

(1 rows) {code}
 We may want vectors to handle `counter` subtype as other collections do, which is throwing an error:
{code:java}
cqlsh:cycling>  create table upcoming_calendar ( year int, month int, events list<counter>, primary key (year, month));
InvalidRequest: Error from server: code=2200 [Invalid query] message="Counters are not allowed inside collections: list<counter>"


cqlsh:cycling>  create table upcoming_calendar ( year int, month int, events map<int, counter>, primary key (year, month));
InvalidRequest: Error from server: code=2200 [Invalid query] message="Counters are not allowed inside collections: map<int, counter>" {code}
Bug: /etc/cassandra/cassandra-jaas.config does not exist in Packages install
Status: Open
Priority: Normal
Created: 04/Jul/24 12:35

When installing cassandra 4.1.5 wth the debian packaged installer the file cassandra-jaas.config  does not exist.

When enabling JMX authentication in the cassandra-env.sh you uncomment the line JVM_OPTS="$JVM_OPTS -Djava.security.auth.login.config=$CASSANDRA_CONF/cassandra-jaas.config" 

It is expecting this file to be in this location (which maps to /etc/cassandra/) and it is not.
Bug: Add timeout or maximum retries for ColumnFamilyStore.selectAndReference
Status: Triage Needed
Priority: Normal
Created: 04/Sep/24 00:49

Hi, I’ve encountered a potential performance bottleneck in _ColumnFamilyStore_ which could cause indefinite waiting. 

 

The method _[snapshotWithoutMemtable|https://github.com/apache/cassandra/blob/02f38208b15b119b3038482c5e36f05c14e2a4cf/src/java/org/apache/cassandra/db/ColumnFamilyStore.java#L2007]_ has iteration over _ColumnFamilyStore_ instances, which creates hard links for each of {_}SSTables{_}, and takes a snapshot. In the iteration, It makes a call to {_}[selectAndReference|https://github.com/apache/cassandra/blob/02f38208b15b119b3038482c5e36f05c14e2a4cf/src/java/org/apache/cassandra/db/ColumnFamilyStore.java#L1873]{_}, which uses a *while (true)* loop to repeatedly attempt obtaining references to _SSTables_ until successful. This continuous looping behavior can lead to an indefinite waiting, causing _snapshotWithoutMemtable_ to either get stuck or take an excessively long time to process each _ColumnFamilyStore_ instance. This issue could become more severe when dealing with a large number of _ColumnFamilyStore_ instances, leading to significant delays and possible resource contention.

 

To mitigate this issue, one possible solution would be introducing a timeout or a maximum number of retries for {_}selectAndReference{_}. This would help prevent the indefinite spinning and ensure a more predictable execution time. 

 

I wonder if there is anything incorrect with the analysis, and if it is worth having an optimization on it. Thanks!
Bug: Filtering on clustering columns in reversed order with BETWEEN return invalid results
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 29/Aug/24 14:06
Resolved: 04/Sep/24 20:02

As noted by [~maedhroz], filtering on clustering columns in reverser order do not work properly.

The problem can be reproduced using the following test:
{code}
@Test
public void testReverseAndBetweenMemtableFiltering()
{
    createTable("CREATE TABLE %s(p int, c int, c2 int, abbreviation ascii, PRIMARY KEY (p, c, c2)) WITH CLUSTERING ORDER BY (c DESC, c2 DESC)");

    execute("INSERT INTO %s(p, c, c2, abbreviation) VALUES (0, 1, 1, 'CA')");
    execute("INSERT INTO %s(p, c, c2, abbreviation) VALUES (0, 2, 2, 'MA')");
    execute("INSERT INTO %s(p, c, c2, abbreviation) VALUES (0, 3, 3, 'MA')");
    execute("INSERT INTO %s(p, c, c2, abbreviation) VALUES (0, 4, 4, 'TX')");

    ResultSet betweenRowsNet = executeNet("SELECT * FROM %s WHERE c2 BETWEEN 2 AND 3 ALLOW FILTERING");
    assertRowsNet(betweenRowsNet, row (0, 3, 3, "MA"), row (0, 2, 2, "MA")); // NO RESULTS?
}
{code}

The issue is due to the fact that the comparison performed in {{BETWEEN.isSatisfied}} ignore the {{ReversedType}}.