av9ash/GitBugs huggingface dataset:
Bug: ConnectionLimitHandler may leaks connection count if remote connection drops
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 11/Jan/22 00:10
Resolved: 19/Mar/22 14:17

In some cases, Netty does not return the original IP used for per-IP counting when the channel becomes inactive,
which throws an NPE before decrementing the active per-IP count.


{code:java}
java.lang.NullPointerException
at org.apache.cassandra.transport.ConnectionLimitHandler.channelInactive(ConnectionLimitHandler.java:101)
       at io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:262)
       at io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:248)
       at io.netty.channel.AbstractChannelHandlerContext.fireChannelInactive(AbstractChannelHandlerContext.java:241)
       at io.netty.handler.codec.ByteToMessageDecoder.channelInputClosed(ByteToMessageDecoder.java:389)
       at io.netty.handler.codec.ByteToMessageDecoder.channelInactive(ByteToMessageDecoder.java:354)
       at io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:262)
       at io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:248)
       at io.netty.channel.AbstractChannelHandlerContext.fireChannelInactive(AbstractChannelHandlerContext.java:241)
       at io.netty.channel.DefaultChannelPipeline$HeadContext.channelInactive(DefaultChannelPipeline.java:1405)
       at io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:262)
       at io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:248)
       at io.netty.channel.DefaultChannelPipeline.fireChannelInactive(DefaultChannelPipeline.java:901)
       at io.netty.channel.AbstractChannel$AbstractUnsafe$8.run(AbstractChannel.java:819)
       at io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:164)
       at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:472)
       at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:497)
       at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
       at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
       at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
       at java.base/java.lang.Thread.run(Thread.java:834)
{code}
Bug: Test Failure: org.apache.cassandra.db.lifecycle.LogTransactionTest.testGetTemporaryFilesSafeAfterObsoletion-cdc
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 24/Jan/22 20:50
Resolved: 23/Mar/22 00:54

Looks like it's a straight up flaky test:

 

[https://ci-cassandra.apache.org/job/Cassandra-trunk/899/testReport/org.apache.cassandra.db.lifecycle/LogTransactionTest/testGetTemporaryFilesSafeAfterObsoletion_cdc/]

 
Failed 3 times in the last 17 runs. Flakiness: 31%, Stability: 82%
h3. Error Message

java.nio.file.NoSuchFileException: /home/cassandra/cassandra/build/test/cassandra/data/TransactionLogsTest/mockcf33-ed510f6070ca11ecbc8a25a710ea09dc/nb-0-big-Data.db
h3. Stacktrace

java.io.UncheckedIOException: java.nio.file.NoSuchFileException: /home/cassandra/cassandra/build/test/cassandra/data/TransactionLogsTest/mockcf33-ed510f6070ca11ecbc8a25a710ea09dc/nb-0-big-Data.db at org.apache.cassandra.io.util.PathUtils.propagateUnchecked(PathUtils.java:695) at org.apache.cassandra.io.util.PathUtils.toRealPath(PathUtils.java:514) at org.apache.cassandra.io.util.PathUtils.toCanonicalPath(PathUtils.java:502) at org.apache.cassandra.io.util.File.toCanonical(File.java:411) at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195) at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1655) at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484) at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474) at java.base/java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:913) at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) at java.base/java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:578) at org.apache.cassandra.db.lifecycle.LogTransactionTest.listFiles(LogTransactionTest.java:1333) at org.apache.cassandra.db.lifecycle.LogTransactionTest.getTemporaryFiles(LogTransactionTest.java:1317) at org.apache.cassandra.db.lifecycle.LogTransactionTest.testGetTemporaryFilesSafeAfterObsoletion(LogTransactionTest.java:1182) 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) Caused by: java.nio.file.NoSuchFileException: /home/cassandra/cassandra/build/test/cassandra/data/TransactionLogsTest/mockcf33-ed510f6070ca11ecbc8a25a710ea09dc/nb-0-big-Data.db at java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:92) at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:111) at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:116) at java.base/sun.nio.fs.UnixPath.toRealPath(UnixPath.java:860) at org.apache.cassandra.io.util.PathUtils.toRealPath(PathUtils.java:510)
Bug: Snapshot true size computation does not include secondary indexes
Status: Resolved
Priority: Normal
Resolution: Duplicate
Created: 07/Feb/22 23:16
Resolved: 11/May/22 18:16

The true size is supposed to show the total size of the snapshot minus any live sstables.

Nevertheless, sstables from secondary indexes are not included in the computation of the true size, causing a mismatch between the true size and snapshot size when there are indexes and no live sstables.

It's possible to fetch the global snapshot size per table and indexes separately via nodetool tablestats, but not for individual snapshots.

This behavior seems to be there since before 3.0, so I think it has always been like this.

Reproduction steps:
{noformat}
% ccm node1 nodetool -- snapshot -t test test_ks

Requested creating snapshot(s) for [test_ks] with snapshot name [test]
Snapshot directory: test

% ccm node1 nodetool listsnapshots

Snapshot Details:
Snapshot name Keyspace name Column family name True size Size on disk
test          test_ks       tbl                0 bytes   10.76 KB

Total TrueDiskSpaceUsed: 0 bytes

% ccm node1 nodetool tablestats test_ks.tbl | grep -i snapshot
    Space used by snapshots (total): 0

% ccm node1 nodetool tablestats test_ks.tbl.tbl_val_idx | grep -i snapshot
    Space used by snapshots (total): 0

% ccm node1 nodetool compact test_ks tbl.tbl_val_idx

% ccm node1 nodetool compact test_ks tbl_val_idx

% ccm node1 nodetool tablestats test_ks.tbl | grep -i snapshot
    Space used by snapshots (total): 5027

% ccm node1 nodetool tablestats test_ks.tbl.tbl_val_idx | grep -i snapshot
    Space used by snapshots (total): 5060

% ccm node1 nodetool listsnapshots

Snapshot Details:
Snapshot name Keyspace name Column family name True size Size on disk
test          test_ks       tbl                4.91 KB   10.76 KB

Total TrueDiskSpaceUsed: 4.91 KB
{noformat}
Bug: cassandra-harry: disable harry-integration local (in-jvm) module for standalone mode
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 16/Jan/22 15:24
Resolved: 05/May/22 09:12

In case we don't need the docker integration of {{harry-integration}}
and we are using an external running Cassandra

https://github.com/apache/cassandra-harry/pull/12
Bug: WEBSITE - March 2022 blog "Kinetic Data chooses Apache Cassandra to deliver workflow automation solution"
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 29/Mar/22 17:44
Resolved: 31/Mar/22 02:05

This ticket is to capture the work associated with publishing the March 2022 blog "Kinetic Data chooses Apache Cassandra to deliver workflow automation solution"

If this blog cannot be published by the *March 31, 2022 publish date*, please contact me, suggest changes, or correct the date when possible in the pull request for the appropriate time that the blog will go live (on both the blog.adoc and the blog post's file).
Bug: WEBSITE - Case Studies - Add Kinetic Data, fix Backblaze
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 23/Mar/22 18:47
Resolved: 31/Mar/22 04:20

This ticket is to capture the work associated with adding a new case study to the website and entry on the Case Studies page.
 * Add Kinetic Data case study
 * Add Kinetic Data card to Case Studies page
 * Add Kinetic Data logo to images: kinetic_data.svg
 * Fix Backblaze case study typo
Bug: WEBSITE - March 2022 blog "Inside Cassandra: An Interview with Project Contributor, Lorina Poland"
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 15/Mar/22 21:25
Resolved: 17/Mar/22 06:34

This ticket is to capture the work associated with publishing the March 2022 blog "Inside Cassandra: An Interview with Project Contributor, Lorina Poland"

If this blog cannot be published by the *March 17, 2022 publish date*, please contact me, suggest changes, or correct the date when possible in the pull request for the appropriate time that the blog will go live (on both the blog.adoc and the blog post's file).
Bug: WEBSITE - March 2022 blog "Can Apache Cassandra take my PEM keys?"
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 28/Feb/22 19:08
Resolved: 10/Mar/22 07:59

This ticket is to capture the work associated with publishing the March 2022 blog "Can Apache Cassandra take my PEM keys?"

If this blog cannot be published by the *March 10, 2022 publish date*, please contact me, suggest changes, or correct the date when possible in the pull request for the appropriate time that the blog will go live (on both the blog.adoc and the blog post's file).
Bug: WEBSITE - March 2022 blog "Apache Cassandra Changelog #13"
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 25/Feb/22 19:10
Resolved: 03/Mar/22 11:03

This ticket is to capture the work associated with publishing the March 2022 changelog blog #13

If this blog cannot be published by the *March 3, 2022 publish date*, please contact me, suggest changes, or correct the date when possible in the pull request for the appropriate time that the blog will go live (on both the blog.adoc and the blog post's file).
Bug: WEBSITE - February 2022 blog "Apache Cassandra and Java SE 11 support"
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 21/Feb/22 20:08
Resolved: 23/Feb/22 00:24

This ticket is to capture the work associated with publishing the January 2022 blog "Apache Cassandra and Java SE 11 support"

If this blog cannot be published by the *February 24, 2022 publish date*, please contact me on ASF Slack or suggest/make changes when possible in the pull request for the appropriate time that the blog will go live (on blog.adoc and in the blog post .adoc).
Bug: WEBSITE - February 2022 blog "Behind the scenes of an Apache Cassandra Release"
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 15/Feb/22 02:00
Resolved: 18/Feb/22 13:25

This ticket is to capture the work associated with publishing the January 2022 blog "Behind the scenes of an Apache Cassandra Release"

If this blog cannot be published by the *February 17, 2022 publish date*, please contact me/suggest changes when possible in the pull request for the appropriate time that the blog will go live (on blog.adoc and in the blog post .adoc).
Bug: cassandra-website run.sh needs to move and prep files for content/ folder
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 11/Feb/22 11:38
Resolved: 26/Apr/22 10:21

See manual steps still required here:
https://github.com/apache/cassandra-builds/compare/trunk...thelastpickle:mck/16765#diff-1f760d89dfb81ea05a11d862007a4e4e586b38aac7ae87f62c5b2e86571809c0R1273-R1291
Bug: WEBSITE - February 2022 blog "Tightening Security for Apache Cassandra Part: 3"
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 11/Feb/22 02:37
Resolved: 15/Feb/22 22:43

This ticket is to capture the work associated with publishing the January 2022 blog "Tightening Security for Apache Cassandra Part: 3"

If this blog cannot be published by the *February 14, 2022 publish date*, please contact me/suggest changes when possible in the pull request for the appropriate time that the blog will go live (on blog.adoc and in the blog post .adoc).
Bug: WEBSITE - February 2022 changelog #12
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 07/Feb/22 23:15
Resolved: 09/Feb/22 16:45

This ticket is to capture the work associated with publishing the January 2022 changelog blog #12

If this blog cannot be published by the *February 10, 2022 publish date*, please contact me, suggest changes, or correct the date when possible in the pull request for the appropriate time that the blog will go live (on both the blog.adoc and the blog post's file).
Bug: WEBSITE - January 2022 blog "Tightening Security for Apache Cassandra Part: 2"
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 02/Feb/22 18:18
Resolved: 07/Feb/22 13:35

This ticket is to capture the work associated with publishing the January 2022 blog "Tightening Security for Apache Cassandra Part: 2"

If this blog cannot be published by the *February 4, 2022 publish date*, please contact me/suggest changes when possible in the pull request for the appropriate time that the blog will go live (on blog.adoc and in the blog post .adoc).
Bug: WEBSITE - January 2022 blog "Tightening Security for Apache Cassandra Part: 1"
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 27/Jan/22 21:47
Resolved: 31/Jan/22 13:01

This ticket is to capture the work associated with publishing the January 2022 blog "Tightening Security for Apache Cassandra Part: 1"

If this blog cannot be published by the *January 31, 2022 publish date*, please contact me/suggest changes when possible in the pull request for the appropriate time that the blog will go live (on blog.adoc and in the blog post .adoc).
Bug: flaky dtest-upgrade.upgrade_tests.cql_tests TestCQLNodes2RF1_Upgrade_indev_4_0_x_To_indev_trunk test_static_cf
Status: Resolved
Priority: Normal
Resolution: Duplicate
Created: 18/Mar/22 10:58
Resolved: 20/Apr/22 14:47

{code:java}
Error Messagecassandra.WriteFailure: Error from server: code=1500 [Replica(s) failed to execute write] message="Operation failed - received 1 responses and 1 failures: UNKNOWN from /127.0.0.1:7000" info={'consistency': 'ONE', 'required_responses': 1, 'received_responses': 1, 'failures': 1, 'error_code_map': {'127.0.0.1': '0x0000'}}Stacktraceself = <abc.TestCQLNodes2RF1_Upgrade_indev_4_0_x_To_indev_trunk object at 0x7f36e8ae1a60>

    def test_static_cf(self):
        """ Test static CF syntax """
        cursor = self.prepare()
    
        # Create
        cursor.execute("""
                CREATE TABLE users (
                    userid uuid PRIMARY KEY,
                    firstname text,
                    lastname text,
                    age int
                );
            """)
    
        for is_upgraded, cursor in self.do_upgrade(cursor):
            logger.debug("Querying {} node".format("upgraded" if is_upgraded else "old"))
            cursor.execute("TRUNCATE users")
    
            # Inserts
            cursor.execute("INSERT INTO users (userid, firstname, lastname, age) VALUES (550e8400-e29b-41d4-a716-446655440000, 'Frodo', 'Baggins', 32)")
            cursor.execute("UPDATE users SET firstname = 'Samwise', lastname = 'Gamgee', age = 33 WHERE userid = f47ac10b-58cc-4372-a567-0e02b2c3d479")
    
            # Queries
            assert_one(cursor, "SELECT firstname, lastname FROM users WHERE userid = 550e8400-e29b-41d4-a716-446655440000", ['Frodo', 'Baggins'])
    
            assert_one(cursor, "SELECT * FROM users WHERE userid = 550e8400-e29b-41d4-a716-446655440000", [UUID('550e8400-e29b-41d4-a716-446655440000'), 32, 'Frodo', 'Baggins'])
    
            assert_all(cursor, "SELECT * FROM users", [[UUID('f47ac10b-58cc-4372-a567-0e02b2c3d479'), 33, 'Samwise', 'Gamgee'],
                                                       [UUID('550e8400-e29b-41d4-a716-446655440000'), 32, 'Frodo', 'Baggins']])
    
            # Test batch inserts
>           cursor.execute("""
                    BEGIN BATCH
                        INSERT INTO users (userid, age) VALUES (550e8400-e29b-41d4-a716-446655440000, 36)
                        UPDATE users SET age = 37 WHERE userid = f47ac10b-58cc-4372-a567-0e02b2c3d479
                        DELETE firstname, lastname FROM users WHERE userid = 550e8400-e29b-41d4-a716-446655440000
                        DELETE firstname, lastname FROM users WHERE userid = f47ac10b-58cc-4372-a567-0e02b2c3d479
                    APPLY BATCH
                """)

upgrade_tests/cql_tests.py:74: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
../venv/src/cassandra-driver/cassandra/cluster.py:2618: in execute
    return self.execute_async(query, parameters, trace, custom_payload, timeout, execution_profile, paging_state, host, execute_as).result() {code}
Bug: cassandra-harry: the cassandra-harry script uses the wrong way to check if the variable is set or not
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 19/Jan/22 10:48
Resolved: 12/Apr/22 12:18

For more information please check the following link:
[https://stackoverflow.com/questions/3601515/how-to-check-if-a-variable-is-set-in-bash]

 

https://github.com/apache/cassandra-harry/pull/13
Bug: Security enforcement by enabling "two-person concept" authorization
Status: Triage Needed
Priority: Normal
Created: 30/Mar/22 17:13

Inspired by the [discussion|https://lists.apache.org/thread/4p92o2obvztkl12hvnrrmlw0cgtl391k] about improving security administration the idea came up to enforce "two-person concept" (a.k.a. two-man rule, four-eyes principle) grant of roles.

Explanation from [Wikipedia|https://en.wikipedia.org/wiki/Two-man_rule]:
{quote}The two-man rule is a control mechanism designed to achieve a high level of security for especially critical material or operations. Under this rule access and actions require the presence of two or more authorized people at all times.{quote}

The idea summarise as having an option - e.g. GRANTORS - on roles to define how many grantors does it need for a user to have a specific role granted.

Think about a keyspace containing highly sensitive data (e.g. patientdata) and a role - r_patientdata_access - allowing its grantees to access the data.
{code}
CREATE KEYSPACE patientdata …;
CREATE ROLE r_patientdata_access WITH GRANTORS=2;
GRANT SELECT, MODIFY ON patientdata TO r_patientdata_access;

CREATE ROLE r_security_admin;
GRANT AUTHORIZE r_patientdata_access TO r_security_admin;
GRANT r_security_admin TO security_admin_1;
GRANT r_security_admin TO security_admin_2;
GRANT r_security_admin TO security_admin_3;
{code}
Security admins are allowed to grant the role, but it would need at least two of them (as defined by GRANTORS) to do so to allow the user to actually access the data.

Thus,
{code}
GRANT r_patientdata_access TO doctor_house;
{code}
must be conducted by at least two different security admins of the available ones above.

When GRANTORS defaults to 1, the default behaviour of roles doesn't change.
Bug: Do not call FBU.getXXXAddressAndPort in static initializers
Status: Triage Needed
Priority: Normal
Created: 31/Mar/22 07:38

{{FBUtilities.getLocalAddressAndPort}} as well as {{FBUtilites.getBroadcastAddressAndPort}} may cache unexpected value when called before {{DatabaseDescriptor}} initialization. It may happen especially when the mentioned methods are used in static initializers of some classes where we have very little or no control over the time they get loaded. 

The current situation may result in weird flakiness, where we bind to some unexpected address and then, the nodes may not be able to connect. 

In the scope of this ticket, I'd do the following:
1. make {{DatabaseDescriptor.conf}} field {{volatile}}
2. refactor usages of the mentioned methods in static initializers of classes
3. forbid using those methods before {{DatabaseDescriptor}} is initialized by throwing assertion error
Bug: WEBSITE - Docker steps in Quickstart guide are not clear
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 25/Mar/22 08:14
Resolved: 28/Mar/22 07:27

In Step 2 of the [documentation|[https://cassandra.apache.org/_/quickstart.html],] there are two commands mentioned.

The commands are:

> docker run --name cassandra cassandra

> docker run --rm -d --name cassandra --hostname cassandra --network cassandra cassandra

 

Both these commands start the cassandra container. If we run first command followed by second command, the second command errors out with message "container with same name already running".

If we run the second command directly, the error message says that the network is not created.
Bug: Intermittent failure on org.apache.cassandra.index.internal.CassandraIndexTest.indexCorrectlyMarkedAsBuildAndRemoved
Status: Triage Needed
Priority: Normal
Created: 25/Mar/22 12:17

Intermittent failure on {{org.apache.cassandra.index.internal.CassandraIndexTest.indexCorrectlyMarkedAsBuildAndRemoved}} in 3.0:

* https://ci-cassandra.apache.org/job/Cassandra-3.0/242/testReport/org.apache.cassandra.index.internal/CassandraIndexTest/indexCorrectlyMarkedAsBuildAndRemoved/
* https://ci-cassandra.apache.org/job/Cassandra-3.0/259/testReport/org.apache.cassandra.index.internal/CassandraIndexTest/indexCorrectlyMarkedAsBuildAndRemoved_compression/

{code}
Failed 1 times in the last 3 runs. Flakiness: 50%, Stability: 66%
Error Message
expected:<1> but was:<0>
Stacktrace
junit.framework.AssertionFailedError: expected:<1> but was:<0>
	at org.apache.cassandra.index.internal.CassandraIndexTest.indexCorrectlyMarkedAsBuildAndRemoved(CassandraIndexTest.java:545)
{code}

The failure can be reproduced with 500 iterations of the entire {{CassandraIndexTest}} on CircleCI test multiplexer:

https://app.circleci.com/pipelines/github/adelapena/cassandra/1430/workflows/4f6d8928-0345-493a-af11-c63012b7b232

That run only hits the failure once, so it seems that flakiness is quite low. On the other hand, two 1000-iterations of {{CassandraIndexTest.indexCorrectlyMarkedAsBuildAndRemoved}} don't hit the failure, so it might be that the failure depends on the execution of other tests in the suite:

* https://app.circleci.com/pipelines/github/adelapena/cassandra/1434/workflows/7e680336-3ff2-424d-9a32-8e89a8909bb4
* https://app.circleci.com/pipelines/github/adelapena/cassandra/1434/workflows/5067e77e-16d9-4147-9fa9-c9805ed95ae2