av9ash/GitBugs huggingface dataset:
Bug: Upgrade to logback 1.2.3 to address CVE-2017-5929
Status: Resolved
Priority: High
Resolution: Duplicate
Created: 21/May/20 22:58
Resolved: 23/Sep/21 14:02

Recent scan results identified the following CVE that requires this upgrade to address

[https://nvd.nist.gov/vuln/detail/CVE-2017-5929]
Bug: provide a configuration option such as endpoint_verification_method
Status: Open
Priority: Normal
Created: 22/Jun/20 18:57

With cassandra-9220, it's possible to configure endpoint/hostname verification when enabling internode encryption.  However, you don't have any control over what endpoint is used for the endpoint verification; instead, cassandra will automatically try to use node IP (not node hostname) for endpoint verification, so if your node certificates don't include the IP in the ssl certificate's SAN list, then you'll get an error like:
{code:java}
ERROR [MessagingService-Outgoing-/10.10.88.194-Gossip] 2018-11-13 10:20:26,903 OutboundTcpConnection.java:606 - SSL handshake error for outbound connection to 50cc97c1[SSL_NULL_WITH_NULL_NULL: Socket[addr=/<NODE_IP_ADDRESS>,port=7001,localport=47684]] 
javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No subject alternative names matching IP address <NODE_IP_ADDRESS> found 
at sun.security.ssl.Alerts.getSSLException(Alerts.java:192) {code}
From what I've seen, most orgs will not have node IPs in their certs.

So, it will be best if cassandra would provide another configuration option such as *{{endpoint_verification_method}}* which you could set to "ip" or "fqdn" or something else (eg "hostname_alias" if for whatever reason the org doesn't want to use fqdn for endpoint verification).
Bug: Update Netty 4.0.44 -> 4.1.50 (fix security/performance issues)
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 12/Jun/20 18:15
Resolved: 03/Jun/24 22:22

See https://issues.apache.org/jira/browse/CASSANDRA-15868 for the same issue on 4.0 / trunk. Attached is an OWASP dependency report for Netty 4.0.44, which identifies 3 of the same vulnerabilities as above.

 

Additionally, 4.1.50 contains aarch64 native libraries which can improve performance on ARM processors.
Bug: DOC - Primary range repair should be run on every datacenter
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 13/Apr/20 17:28
Resolved: 16/Feb/24 12:43

In the Cassandra document page: [http://cassandra.apache.org/doc/latest/operating/repair.html], there is an explanation which makes confusion on users' side:
{quote}The {{-pr}} flag will only repair the “primary” ranges on a node, so you can repair your entire cluster by running {{nodetool repair -pr}} on each node in a single datacenter.
{quote}
This made confusion that "running nodetool repair -pr on each node in a single DC" was sufficient to do a full repair on a multi-DC cluster.

The correct way to use the primary range repair should be
{quote}if you are using “nodetool repair -pr” you must run it on *EVERY* node in *EVERY* data center, no skipping allowed.
{quote}
Please make a doc fix. Thanks.
Bug: /usr/bin/cassandra looking for wrong libjemalloc.so file
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 28/Apr/20 14:31
Resolved: 15/Aug/22 08:19

In /usr/sbin/cassandra

Linux)
 if [ -z $CASSANDRA_LIBJEMALLOC ] ; then
 which ldconfig > /dev/null 2>&1
 if [ $? = 0 ] ; then
 # e.g. for CentOS
 dirs="/lib64 /lib /usr/lib64 /usr/lib `ldconfig -v 2>/dev/null | grep -v '^\s' | sed 's/^\([^:]*\):.*$/\1/'`"
 else
 # e.g. for Debian, OpenSUSE
 dirs="/lib64 /lib /usr/lib64 /usr/lib `cat /etc/ld.so.conf /etc/ld.so.conf.d/*.conf | grep '^/'`"
 fi
 dirs=`echo $dirs | tr " " ":"`
 CASSANDRA_LIBJEMALLOC=$(find_library '.*/libjemalloc\.so\(\.1\)*' $dirs)

 

However...

# find /usr/lib64 -name "*jemalloc*"
/usr/lib64/libjemalloc.so.2
Bug: Tiny documentation fix in Architecture/Overview
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 11/May/20 04:33
Resolved: 20/Jun/23 19:24

I noticed a small issue in the documentation, so I'd like to fix it.

This issue also exists to guide me to the proper way to make contributions to Cassandra, hopefully larger ones in the future, so please forgive the trivialness of this fix.
Bug: Please update Apache Cassandra Repo link in install docs
Status: Resolved
Priority: Normal
Resolution: Won't Fix
Created: 24/May/20 06:56
Resolved: 20/Jun/23 19:23

In the very first section of Install Docs

Add the Apache Cassandra repository keys to the list of trusted keys on the server:

 
$ curl https://www.apache.org/dist/cassandra/KEYS | sudo apt-key - [Not working]
 
Please change the address. I found this working:
 
curl https://downloads.apache.org/cassandra/KEYS | sudo apt-key add -
Bug:  Typo in website documentation for file "mvs.rst"
Status: Resolved
Priority: Normal
Resolution: Resolved
Created: 25/May/20 17:19
Resolved: 20/Jun/23 19:22

It appears that there is a typo in the doc for mvs.rst file.  Please refer this link - [https://cassandra.apache.org/doc/latest/cql/mvs.html#drop-materialized-view]

_Current sentence in doc:_ 

"Dropping a materialized view {color:#de350b}*users* {color}the DROP MATERIALIZED VIEW statement:"

_Expected sentence in doc:_ 

"Dropping a materialized view {color:#00875a}*using* {color}the DROP MATERIALIZED VIEW statement:"

_Patch for proposed fix:_

[https://github.com/tsingh2k15/cassandra/commit/1a56c295843bd74f2e856c01fa76a4676875dc7c]

 

Please review and let me know if this patch can be accepted as a fix?
Bug: Separate out allow filtering scanning through a partition versus scanning over the table
Status: Triage Needed
Priority: Normal
Created: 12/May/20 05:04

Currently allow filtering can mean two things in the spirit of "avoid operations that don't seek to a specific row or sequential rows of data."  First, it can mean scanning across the entire table to meet the criteria of the query.  That's almost always a bad thing and should be discouraged or disabled (see CASSANDRA-8303).  Second, it can mean filtering within a specific partition.  For example, in a query you could specify the full partition key and if you specify a criterion on a non-key field, it requires allow filtering.

The second reason to require allow filtering is significantly less work to scan through a partition.  It is still extra work over seeking to a specific row and getting N sequential rows though.  So while an application developer and/or operator needs to be cautious about this second type, it's not necessarily a bad thing, depending on the table and the use case.

I propose that we separate the way to specify allow filtering across an entire table from specifying allow filtering across a partition in a backwards compatible way.  One idea that was brought up in Slack in the cassandra-dev room was to have allow filtering mean the superset - scanning across the table.  Then if you want to specify that you *only* want to scan within a partition you would use something like

{{ALLOW FILTERING [WITHIN PARTITION]}}

So it will succeed if you specify non-key criteria within a single partition, but fail with a message to say it requires the full allow filtering.  This would allow for a backwards compatible full allow filtering while allowing a user to specify that they want to just scan within a partition, but error out if trying to scan a full table.

This is potentially also related to the capability limitation framework by which operators could more granularly specify what features are allowed or disallowed per user, discussed in CASSANDRA-8303.  This way an operator could disallow the more general allow filtering while allowing the partition scan (or disallow them both at their discretion).
Bug: MV schema version update race
Status: Open
Priority: Normal
Created: 02/Jun/20 08:12

test_populate_mv_after_insert_wide_rows fails with

{quote}
ERROR [MutationStage-2] 2020-06-02 17:31:46,414 Keyspace.java:621 - Attempting to mutate non-existant table 2afc69c0-a4e6-11ea-a44e-7941109e8480 (ks.t_by_v)
{quote}
Bug: SASI BounceIntersectionIterator should perform skipTo() using biggest token value
Status: Triage Needed
Priority: Normal
Created: 15/May/20 05:49

In {{BounceIntersectionIterator}}, it polls the {{range iterator}} which has the smallest current token from priority queue and uses the smallest token to perform skipTo() on other range iterators where their current tokens are equal to or greater than the smallest token... In this case, "skipTo()" works similarly to "next()" and no on-disk leaves will be skipped in {{TokenTreeIterator#performSkipTo()}}.

I think {{BounceIntersectionIterator}} should poll the range iterator with biggest current token and use it to perform skipTo() to improve performance.
Bug: Delay between Gossip settle and CQL port opening during the startup
Status: Open
Priority: Normal
Created: 04/Jun/20 01:46

Hello,

When I am bootstrapping/restarting a Cassandra Node, there is a delay between gossip settle and CQL port opening. Can someone please explain me where this delay is configured and can this be changed? I don't see any information in the logs

In my case if you see there is  a ~3 minutes delay and this increases if I increase the #of tables and #of nodes and DC.


{code:java}
INFO  [main] 2020-05-31 23:51:07,554 Gossiper.java:1692 - Waiting for gossip to settle...
INFO  [main] 2020-05-31 23:51:15,555 Gossiper.java:1723 - No gossip backlog; proceeding
INFO  [main] 2020-05-31 23:54:06,867 NativeTransportService.java:70 - Netty using native Epoll event loop
INFO  [main] 2020-05-31 23:54:06,913 Server.java:155 - Using Netty Version: [netty-buffer=netty-buffer-4.0.44.Final.452812a, netty-codec=netty-codec-4.0.44.Final.452812a, netty-codec-haproxy=netty-codec-haproxy-4.0.44.Final.452812a, netty-codec-http=netty-codec-http-4.0.44.Final.452812a, netty-codec-socks=netty-codec-socks-4.0.44.Final.452812a, netty-common=netty-common-4.0.44.Final.452812a, netty-handler=netty-handler-4.0.44.Final.452812a, netty-tcnative=netty-tcnative-1.1.33.Fork26.142ecbb, netty-transport=netty-transport-4.0.44.Final.452812a, netty-transport-native-epoll=netty-transport-native-epoll-4.0.44.Final.452812a, netty-transport-rxtx=netty-transport-rxtx-4.0.44.Final.452812a, netty-transport-sctp=netty-transport-sctp-4.0.44.Final.452812a, netty-transport-udt=netty-transport-udt-4.0.44.Final.452812a]
INFO  [main] 2020-05-31 23:54:06,913 Server.java:156 - Starting listening for CQL clients on /x.x.x.x:9042 (encrypted)...
{code}


Also during this 3-10 minutes delay, I see 
{noformat}
nodetool compactionstats
{noformat}
 command is hung and never respond, until the CQL port is up and running.

Can someone please help me understand the delay here?

Cassandra Version: 3.11.3


The issue can be easily reproducible with around 300 Tables and 100 nodes in a cluster.
Bug: Make SASI query safe for concurrent compaction
Status: Open
Priority: Normal
Created: 27/Apr/20 16:34

Read Request Thread:

1.) In {{QueryController#getIndexes}}, read request gets the current {{view}} of sstable indexes.
 2.) Request will try to reference the {{SSTableIndex}} from the {{view}} in {{TermIterator#build}} and skips the {{SSTableIndex}} if it cannot be referenced.

Compaction Thread:

If a compaction finishes between 1) and 2) and no other in-flight queries are holding the sstable index reference, compacted {{SSTableIndex}} will be released.
 Then in step 2, read request will not be able to reference the released {{SSTableIndex}}. We won't see a corruption error, but we'll silently not read all data.

 
----
 

Proposed fix: Read Request should make sure all {{SSTableIndexes}} from the {{View}} can be referenced; if not, it should retry with latest {{View}}.
Bug: Add serial consistency option and regular and serial consistency into profile yaml
Status: Triage Needed
Priority: Normal
Created: 16/Apr/20 07:28

Needed to be done in order to be able to control serial consistency and regular consistency levels separately.

For instance, it was not possible to set serial consistency to LOCAL_SERIAL and regular consistency to QUORUM.

We have following code handling it all over the place:

if (cl.isSerialConsistency()) statement.setSerialConsistencyLevel(JavaDriverClient.from(cl)); else statement.setConsistencyLevel(JavaDriverClient.from(cl));

With the fix it beacome possible to set serial and regular consistency separately, also it is possible to specify consistency in yaml file per query, in case you want to stress with dirrefent consistency levels, in following manner:

lwt_update_one_column:
     cql: update blogposts set lwt_ind = 10000001 where domain = ? and published_date = ? if lwt_ind < 0
     fields: samerow
     consistencyLevel: QUORUM
     serialConsistencyLevel: LOCAL_SERIAL

 

Fix: [https://github.com/apache/cassandra/pull/540]
Bug: cassandra-stress fails when we  specify a port per node
Status: Triage Needed
Priority: Normal
Created: 15/Apr/20 17:06

{code}
$ ./tools/bin/cassandra-stress write n=10 -node 127.0.0.1:9046,127.0.0.1:9048

...
java.lang.RuntimeException: java.lang.IllegalArgumentException: Failed to add contact point: 127.0.0.1:9046
	at org.apache.cassandra.stress.settings.StressSettings.getJavaDriverClient(StressSettings.java:148)
	at org.apache.cassandra.stress.settings.StressSettings.getJavaDriverClient(StressSettings.java:116)
	at org.apache.cassandra.stress.settings.SettingsSchema.createKeySpaces(SettingsSchema.java:66)
	at org.apache.cassandra.stress.settings.StressSettings.maybeCreateKeyspaces(StressSettings.java:156)
	at org.apache.cassandra.stress.StressAction.run(StressAction.java:56)
	at org.apache.cassandra.stress.Stress.run(Stress.java:143)
	at org.apache.cassandra.stress.Stress.main(Stress.java:62)
Caused by: java.lang.IllegalArgumentException: Failed to add contact point: 127.0.0.1:9046
	at com.datastax.driver.core.Cluster$Builder.addContactPoint(Cluster.java:922)
	at org.apache.cassandra.stress.util.JavaDriverClient.connect(JavaDriverClient.java:131)
	at org.apache.cassandra.stress.settings.StressSettings.getJavaDriverClient(StressSettings.java:139)
	... 6 more
Caused by: java.net.UnknownHostException: 127.0.0.1:9046: invalid IPv6 address
	at java.base/java.net.InetAddress.getAllByName(InetAddress.java:1341)
	at java.base/java.net.InetAddress.getAllByName(InetAddress.java:1298)
	at com.datastax.driver.core.Cluster$Builder.addContactPoint(Cluster.java:919)
	... 8 more

{code}
Bug: Improve range reads to query by endpoints instead of vnodes to reduce number of remote requests
Status: Open
Priority: Normal
Created: 29/Apr/20 16:28

Currently, range read queries in batches, see {{StorageProxy.RangeCommandIterator#sendNextRequests()}}. For each batch, it computes a list of merged vnode ranges up to concurrency factor and query each merged vnode range asynchronously. (note: consecutive vnode ranges can be merged if they share enough replicas to satisfy consistency level requirement)

This works fine in general, but when concurrency factor is high because returned row count is small comparing to query limit or index filtering is used, coordinator may send too many concurrent remote range requests in a batch.

We can improve it by grouping remote range requests by endpoints where each endpoint will return response corresponding to multiple non-consecutive ranges. With endpoint grouping, number of remote range requests should largely reduced and it's always capped by number of nodes in the cluster instead of number of ranges which is capped by concurrency factor.

Let's look at an example on a 5-node cluster with 10 ranges(a,b,c,d,e,f,g,h,i,h) and rf3.

Following is the range to replica mapping using round robin that should work well with consecutive range merger (consecutive range merger doesn't work well with fully random replica mapping, because it's less likely to have overlapping replicas for consecutive ranges)
{code:java}
   range-a replicas: 1, 2, 3
   range-b replicas: 2, 3, 4
   range-c replicas: 3, 4, 5
   range-d replicas: 1, 4, 5
   range-e replicas: 1, 2, 5
   range-f replicas: 1, 2, 3
   range-g replicas: 2, 3, 4
   range-h replicas: 3, 4, 5
   range-i replicas: 1, 4, 5
   range-j replicas: 1, 2, 5
{code}
With default range read implementation and consecutive range merger, we need 10 replica read requests(2 for each merged range) for quorum:
{code:java}
     range (a,b] on node [2, 3]
     range (c,d] on node [4, 5]
     range (e,f] on node [1, 2]
     range (g,h] on node [3, 4]
     range (i,j] on node [1, 5]
{code}
With group query by endpoints, we only need 4 replica read requests for quorum:
{code:java}
    * node 1: a, d, e, f, i, j
    * node 2: a, b, e, f, g, j
    * node 3: b, c, g, h
    * node 4: c, d, h, i
{code}
 
Note that there are some complexities around short-read protection which needs to know whether replica has more rows available for current range.
Bug: DOC - Installation pages, curl command for retrieving keys
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 20/Jun/20 16:29
Resolved: 22/Jun/20 14:27

I noticed that on the *getting_started/installing* page in the Debian section the curl command for retrieving the cassandra GPG KEYS does not work (the URL gets redirected and no data is returned by curl).

It might be fixed by adding '-L' to the curl command or by changing [www.apache.org|http://www.apache.org/] to downloads.apache.org on that page (commit c93c2983cd3f did this previously but is no longer in the code).

 

I have created a pull request for this issue: [https://github.com/apache/cassandra/pull/648]
Bug: JAVA 8: test_multiple_repair - repair_tests.incremental_repair_test.TestIncRepair
Status: Resolved
Priority: Normal
Resolution: Not A Problem
Created: 23/Jun/20 03:00
Resolved: 07/Jul/20 17:17

JAVA 8: test_multiple_repair - repair_tests.incremental_repair_test.TestIncRepair

Fails locally and in CircleCI:

https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/222/workflows/46515d14-9be4-4edb-8db4-5930312d2bfb/jobs/1329
Bug: Commented-out lines that end in a semicolon cause an error.
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 11/May/20 06:17
Resolved: 20/Aug/20 12:03

Commented-out lines that end in a semicolon cause an error.

For example:

/*

describe keyspaces;

*/

 

This produces an error:

SyntaxException: line 2:22 no viable alternative at input '<EOF> (...*
describe keyspaces;...)

 

It works as expected if you use syntax:

-- describe keyspaces;

 

Environment:

python:3.7.7-slim-stretch (docker image)

 

I found that this was first seen here, and was patched, but the bug appears to have resurfaced:

https://issues.apache.org/jira/browse/CASSANDRA-2488
Bug: DOC - Review Testing section, update builds info to ci-cassandra.apache.org
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 04/Apr/20 08:27
Resolved: 09/Nov/21 09:22

h2. Background
While discussing doc updates to CASSANDRA-15466 on [ASF Slack|https://the-asf.slack.com/archives/CK23JSY2K/p1585985233187200], I discovered that the [Testing|http://cassandra.apache.org/doc/latest/development/testing.html] page requires a review.

h2. Sample section
[~mck] advised that the linked CI server here:

bq. Using dtests helps us to prevent regression bugs by continually executing tests on the [CI server|https://builds.apache.org/] against new patches.

should be https://ci-cassandra.apache.org/.
Bug: Add StorageServiceMBean#setDynamicBadnessThreshold to expose dynamic badness threshold
Status: Review In Progress
Priority: Normal
Created: 16/Apr/20 16:17

https://issues.apache.org/jira/browse/CASSANDRA-12179 made the DynamicEndpointSnitch properties dynamic at runtime but didn’t expose a method to modify badness threshold. This can be useful in operations that also modify severity manually or if operators want to temporarily disable dynamic snitch behavior.
Bug: Enhance fqltool to be able to export the fql log into a format which doesn't depend on Cassandra
Status: Open
Priority: Normal
Created: 26/May/20 17:20

Currently the fql log format uses Cassandra serialization within the message, which means that reading the file also requires Cassandra classes. To make it easier for outside tools to read the fql logs we should enhance the fqltool to be able to dump the logs to a file format using thrift or protobuf.

Additionally we should support exporting the original query with a deterministic version allowing tools to have reproducible and comparable results.
Bug: Default StringTableSize parameter causes GC slowdown
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 13/May/20 15:45
Resolved: 17/Dec/20 17:11

While looking at tail latency on a Cassandra cluster, it came up that the default StringTableSize in Cassandra is set to a million:
{code:java}
# Larger interned string table, for gossip's benefit (CASSANDRA-6410)
-XX:StringTableSize=1000003{code}
This was done for CASSANDRA-6410 by [~jbellis] in '13, to optimize heap usage on a test case, running with 500 nodes and num_tokens=512.

Until Java 13, this string table is implemented as native code, and has to be traversed entirely during the GC initial marking phase, which is a STW event.

Some testing on my end shows that the pause time of a GC cycle can be reduced by approximately 10 milliseconds if we lower the string table size back to the Java 8 default of 60013 entries.

Thus, I would recommend this patch (3.11 branch, similar patch for 4.0):
{code:java}
diff --git a/conf/jvm.options b/conf/jvm.options
index 01bb1685b3..c184d18c5d 100644
--- a/conf/jvm.options
+++ b/conf/jvm.options
@@ -107,9 +107,6 @@
 # Per-thread stack size.
 -Xss256k

-# Larger interned string table, for gossip's benefit (CASSANDRA-6410)
--XX:StringTableSize=1000003
-
 # Make sure all memory is faulted and zeroed on startup.
 # This helps prevent soft faults in containers and makes
 # transparent hugepage allocation more effective.
 {code}
It does need some testing on more extreme clusters than I have access to, but I ran some Cassandra nodes with {{-XX:+PrintStringTableStatistics}} which suggested that the Java default will suffice here.
Bug: NoSpamLogger arguments building objects on hot paths
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 28/Apr/20 13:54
Resolved: 22/Jul/20 12:52

NoSpamLogger is used in hot logging paths to prevent logs being overrun.  For that to be most effective the arguments to the logger need to be cheap to construct.  During the internode messaging refactor CASSANDRA-15066, performance changes to BufferPool for CASSANDRA-14416
were accidentally reverted in the merge up from 3.11.

Reviewing other uses since, it looks like there are a few places where the arguments require some form of String building.

org.apache.cassandra.net.InboundSink#accept
org.apache.cassandra.net.InboundMessageHandler#processCorruptFrame
org.apache.cassandra.net.InboundMessageHandler.LargeMessage#deserialize
org.apache.cassandra.net.OutboundConnection#onOverloaded
org.apache.cassandra.utils.memory.BufferPool.GlobalPool#allocateMoreChunks

Formatting arguments should either be precomputed, or if expensive they should be computed after the decision on whether to noSpamLog has been made.
Bug: Flaky unit test: CorruptedSSTablesCompactionsTest
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 16/Jun/20 21:52
Resolved: 23/Jun/20 18:01

CASSANDRA-14238 addressed the failure in {{BlacklistingCompactionsTest.testBlacklistingWithSizeTieredCompactionStrategy}}, but only on 2.2. While working on CASSANDRA-14888, we’ve reproduced [the failure|https://app.circleci.com/pipelines/github/dineshjoshi/cassandra/47/workflows/de5f7cdb-06b6-4869-9d19-81a145e79f3f/jobs/2516/tests] on trunk.

It looks like this should be a clean merge forward.