av9ash/GitBugs huggingface dataset:
Bug: File access errors on Windows 7 with version 3.15 and 3.16 - NoHostAvailable
Status: Triage Needed
Priority: Normal
Created: 30/May/20 15:26

I was trying out Cassandra 3.15 on Windows 7 it doesn't start with IOException, I googled it it seems it's known issue.

Then I switched to 3.14 on same Windows 7 it worked 2 months without any errors.

When 3.16 was released I switched to it on same Windows 7 and it turned out to be very unstable. I found that sometimes *server shutdowns listening socket* though the process still runs and nothing is written to console. In logs I found that server shutdown happens *due to file access error*. Most of the time this happens when dropping keyspace. I run often automated test that create and drop keyspace before and after test run.
Bug: Potential duplicate rows on 2.X->3.X upgrade when multi-rows range tombstones interacts with collection tombstones
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 12/May/20 15:12
Resolved: 27/May/20 15:23

The legacy reading code ({{LegacyLayout}} and {{UnfilteredDeserializer.OldFormatDeserializer}}) does not handle correctly the case where a range tombstone covering multiple rows interacts with a collection tombstone.

A simple example of this problem is if one runs on 2.X:
{noformat}
CREATE TABLE t (
  k int,
  c1 text,
  c2 text,
  a text,
  b set<text>,
  c text,
  PRIMARY KEY((k), c1, c2)
);

// Delete all rows where c1 is 'A'
DELETE FROM t USING TIMESTAMP 1 WHERE k = 0 AND c1 = 'A';
// Inserts a row covered by that previous range tombstone
INSERT INTO t(k, c1, c2, a, b, c) VALUES (0, 'A', 'X', 'foo', {'whatever'}, 'bar') USING TIMESTAMP 2;
// Delete the collection of that previously inserted row
DELETE b FROM t USING TIMESTAMP 3 WHERE k = 0 AND c1 = 'A' and c2 = 'X';
{noformat}

If the following is ran on 2.X (with everything either flushed in the same table or compacted together), then this will result in the inserted row being duplicated (one part containing the {{a}} column, the other the {{c}} one).

I will note that this is _not_ a duplicate of CASSANDRA-15789 and this reproduce even with the fix to {{LegacyLayout}} of this ticket. That said, the additional code added to CASSANDRA-15789 to force merging duplicated rows if they are produced _will_ end up fixing this as a consequence (assuming there is no variation of this problem that leads to other visible issues than duplicated rows). That said, I "think" we'd still rather fix the source of the issue.
Bug: nodetool garbagecollect could leave LCS level intact
Status: Triage Needed
Priority: Normal
Created: 26/May/20 15:39

The nodetool command `garbagecollect` will run a single-sstable compaction for every sstable in a cf, while using other sstables on the side to allow for dropping tombstoned data. However, in doing so, it resets all LCS levels back to 0, causing a significant write amplification.

Fundamentally there's no reason why LCS levels have to be changed here, since these are single-sstable compactions. When the expected reduction in data set size is small (say, 10%) it may be preferable for sstables to remain in place instead of having to go through the entire compaction process again.
Bug: Upgrade to Jackson Databind 2.9.10.4 or later to address CVEs
Status: Triage Needed
Priority: Normal
Created: 21/May/20 22:07

Recent scan results identified the following CVEs that require this upgrade to address

[https://nvd.nist.gov/vuln/detail/CVE-2020-8840] 
[https://nvd.nist.gov/vuln/detail/CVE-2020-9548] 
[https://nvd.nist.gov/vuln/detail/CVE-2020-9547] 
[https://nvd.nist.gov/vuln/detail/CVE-2020-9546] 
[https://nvd.nist.gov/vuln/detail/CVE-2020-10673] 
[https://nvd.nist.gov/vuln/detail/CVE-2020-10672] 
[https://nvd.nist.gov/vuln/detail/CVE-2020-10968] 
[https://nvd.nist.gov/vuln/detail/CVE-2020-10969] 
[https://nvd.nist.gov/vuln/detail/CVE-2020-11112] 
[https://nvd.nist.gov/vuln/detail/CVE-2020-11113] 
[https://nvd.nist.gov/vuln/detail/CVE-2020-11111] 
[https://nvd.nist.gov/vuln/detail/CVE-2020-11619] 
[https://nvd.nist.gov/vuln/detail/CVE-2020-11620]
Bug: Fix Python SyntaxWarning: "is not" with a literal. Did you mean "!="
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 16/Apr/20 07:43
Resolved: 17/Apr/20 09:02

With the upgrade to Python 3.8 there are SyntaxWarnings now showing up in the tests, which should be fixed.

{code}
/home/cassandra/cassandra/cassandra-dtest/conftest.py:207: SyntaxWarning: "is not" with a literal. Did you mean "!="?
  if len(errors) is not 0:
/home/cassandra/cassandra/cassandra-dtest/conftest.py:240: SyntaxWarning: "is not" with a literal. Did you mean "!="?
  if len(logs) is not 0:
/home/cassandra/cassandra/venv/src/ccm/ccmlib/repository.py:393: SyntaxWarning: "is not" with a literal. Did you mean "!="?
  while attempt < 3 and ret_val is not 0:
/home/cassandra/cassandra/venv/src/ccm/ccmlib/repository.py:399: SyntaxWarning: "is not" with a literal. Did you mean "!="?
  if ret_val is not 0:
/home/cassandra/cassandra/venv/src/ccm/ccmlib/repository.py:422: SyntaxWarning: "is not" with a literal. Did you mean "!="?
  if ret_val is not 0:
/home/cassandra/cassandra/venv/src/ccm/ccmlib/repository.py:425: SyntaxWarning: "is not" with a literal. Did you mean "!="?
  if ret_val is not 0:
/home/cassandra/cassandra/cassandra-dtest/dtest_setup.py:124: SyntaxWarning: "is not" with a literal. Did you mean "!="?
  if len(filtered_errors) is not 0:
/home/cassandra/cassandra/cassandra-dtest/dtest_setup.py:152: SyntaxWarning: "is not" with a literal. Did you mean "!="?
  if len(logs) is not 0:
/home/cassandra/cassandra/cassandra-dtest/dtest_setup.py:286: SyntaxWarning: "is not" with a literal. Did you mean "!="?
  if len(errors) is not 0:
{code}
Bug: cqlsh -e parsing bug
Status: Resolved
Priority: Normal
Resolution: Duplicate
Created: 06/Apr/20 20:57
Resolved: 07/Apr/20 08:23

{{cqlsh -e}} no longer works on trunk after the introduction of python 3 support (CASSANDRA-10190). Examples below. 

{code}
$ ./bin/cqlsh -e 'select * from foo;'
Usage: cqlsh.py [options] [host [port]]

cqlsh.py: error: ‘CHANGES.txt' is not a valid port number.

$ ./bin/cqlsh -e 'select id from foo;'
Usage: cqlsh.py [options] [host [port]]

cqlsh.py: error: 'from' is not a valid port number.

{code}
Bug: Tunable RangeTombstoneList initial size and resize factor
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 27/Apr/20 18:49
Resolved: 06/May/20 23:03

Cassandra allocates a backing array with a fixed size of one when creating a new RangeTombstoneList object. The resize factor is fixed to 1.5.
The initial size and resize factor could be made tunable so it could reduce cost in some cases.
Bug: DOC - Update details of new book "Cassandra: The Definitive Guide"
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 15/Apr/20 18:10
Resolved: 29/Apr/20 06:29

There is a new edition of the book "Cassandra: The Definitive Guide" by Jeff Carpenter and Eben Hewitt. 
* 3rd edition
* updated for Cassandra 4.0
* https://www.amazon.com/gp/product/1098115163/

Need to update the Community page.
Bug: dtests fix due to cqlsh behavior change
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 19/Apr/20 22:55
Resolved: 22/Apr/20 19:47

dtests are failing due to a behavior change in cqlsh that was introduced as part of 15623. This patch fixes the issue. It also fixes some issues that were surfaced that were silent failures earlier. For example, the UTF-8 encoding issues with Python 2.7 on trunk was caught. We also caught an issue with ccm which ccm subsequently [fixed|https://github.com/riptano/ccm/pull/712].

|[cassandra|https://github.com/dineshjoshi/cassandra/tree/15623-fix-tests]|
|[cassandra-dtests|https://github.com/dineshjoshi/cassandra-dtest-1/tree/15623-fix-tests]|
|[utests &amp; dtests|https://circleci.com/workflow-run/65ae49dd-e52f-4af0-b310-7e09f2c204ea]|


 !15623-pipeline.png!
Bug: Generate compiler options file to support Java11 in IDEA.
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 17/Apr/20 22:59
Resolved: 18/Apr/20 03:33

The change to JMX in CASSANDRA-15653 prevents the generated IDEA project from compiling under JDK11.

Fix by adding options for a module (named after the checkout dir)

{code}
<?xml version="1.0" encoding="UTF-8"?>
<project version="4">
  <component name="JavacSettings">
    <option name="ADDITIONAL_OPTIONS_OVERRIDE">
      <module name="trunk" options="--add-exports java.rmi/sun.rmi.registry=ALL-UNNAMED" />
    </option>
  </component>
{code}
Bug: CustomIndexTest.indexBuildingPagesLargePartitions is flaky
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 24/Apr/20 22:45
Resolved: 07/May/20 16:26

CustomIndexTest.indexBuildingPagesLargePartitions is flaky. Failed in CI and was able to reproduce failure inside IntelliJ by setting test Repeat to ‘Run Until Failure’. Failed after 459 iterations.

{code}
java.lang.AssertionError
	at org.junit.Assert.fail(Assert.java:86)
	at org.junit.Assert.assertTrue(Assert.java:41)
	at org.junit.Assert.assertTrue(Assert.java:52)
	at org.apache.cassandra.index.CustomIndexTest.lambda$indexBuildingPagesLargePartitions$1(CustomIndexTest.java:687)
	at java.base/java.util.ArrayList.forEach(ArrayList.java:1540)
	at org.apache.cassandra.index.CustomIndexTest.indexBuildingPagesLargePartitions(CustomIndexTest.java:687)
	at jdk.internal.reflect.GeneratedMethodAccessor14.invoke(Unknown Source)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:566)
	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
	at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
	at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
	at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
	at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
	at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
	at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
	at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
	at com.intellij.rt.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:53)
	at com.intellij.rt.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:230)
	at com.intellij.rt.junit.JUnitStarter.main(JUnitStarter.java:58)
{code}
Bug: Regression in traceOutgoingMessage printing message size in tracing
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 02/Apr/20 21:22
Resolved: 18/Apr/20 05:58

The internode messaging refactor (CASSANDRA-15066) introduced a tiny regression to tracing. Previously CASSANDRA-13028 had changed the message emitted by traceOutgoingMessage to include the number of bytes.
{code}
"Sending %s message to %s"
{code}
to
{code}
"Sending %s message to %s message size %d bytes"
{code}

But the change was dropped during the refactor, it's easy to put it back.
Bug: Add additional logging around FileUtils and compaction leftover cleanup
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 07/Apr/20 23:42
Resolved: 09/Apr/20 23:15

Add logging that will help us troubleshoot problems where we delete both the source and destination files from a compaction on startup.

[Circle CI|https://circleci.com/gh/dcapwell/cassandra/tree/improvement%2FCASSANDRA-15705]
Bug: Fix flakiness of DecayingEstimatedHistogramReservoirTest#testStriping and apply the same "fix" to other tests
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 04/May/20 08:25
Resolved: 04/May/20 15:01

The unit test {{DecayingEstimatedHistogramReservoirTest#testStriping}} is flaky, especially when many tests are running concurrently, because the used thread-pool can still be running when the assertions are tested (i.e. the {{ExecutorService.awaitTermination()}} returned false).

The "fix" is rather a band aid: extend the wait-period to 1 minute, check the return value of {{awaitTermination}} and apply the same change to some other tests that _might_ be affected as well.
Bug: Increase test coverage of batch counters
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 21/Apr/20 22:50
Resolved: 22/Apr/20 02:46

Add tests for UNLOGGED BATCH updates to counter columns.

[Branch|https://github.com/jonmeredith/cassandra/tree/15747] CircleCI [Java8|https://app.circleci.com/pipelines/github/jonmeredith/cassandra/341/workflows/a6b60116-970f-4791-ac6b-b85e1783db5d] [Java11|https://app.circleci.com/pipelines/github/jonmeredith/cassandra/341/workflows/d7e3042f-5d62-43d6-b95f-2eb4d6e103c1]
Bug: FBUtilitities.testWaitFirstFuture is flaky
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 21/Apr/20 11:07
Resolved: 21/Apr/20 14:18

The unit test FBUtilitities.testWaitFirstFuture 

Example failure message: {{junit.framework.AssertionFailedError: expected:<40> but was:<10>}}
Bug: Less test stderr spam when running tests w/ java 11
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 04/May/20 08:16
Resolved: 04/May/20 18:53

There are a bunch of tests that, when run with Java 11, emit the boilerplate {{WARNING: An illegal reflective access operation has occurred}} messages.

The proposed change just adds more invocations to {{org.apache.cassandra.utils.FBUtilities#preventIllegalAccessWarnings}} to get rid of many of those.
Bug: Entire SSTable transfers don't work over SSL
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 19/Apr/20 23:05
Resolved: 23/Apr/20 05:09

Entire SSTable transfers do not function when SSL handler is present in the Netty pipeline. This is a trivial fix to allow it to proceed over SSL there by extending benefits over SSL.

||ssl||
|[cassandra|https://github.com/dineshjoshi/cassandra/tree/zcs-with-ssl]|
|[dtest|https://github.com/dineshjoshi/cassandra-dtest-1/tree/zcs-with-ssl]|
|[utests &amp; dtests|https://circleci.com/gh/dineshjoshi/workflows/cassandra/tree/zcs-with-ssl]|
Bug: Conflicting LWT transactions may be committed during topology change
Status: Open
Priority: Normal
Created: 21/Apr/20 13:30

Let's consider a cluster which consists of replicas A, B and C.
We're adding replica D which replaces A.

A scenario is possible when two conflicting transactions, CAS1 and CAS2, may be committed during replace:

CAS2 ballot > CAS1 ballot
CAS2 and CAS1 conflict  on LWT condition, yet both of them may be committed in  case of the following sequence of events:

Topology change starts, advertises on C
CAS1 starts on node C, uses {A, B, C, D}
CAS2 starts on node A, still uses {A, B, C}
Topology change is advertised on A
CAS1 prepares on {B, C, D}
CAS2 prepares and accepts on {A, B}, commits on A
CAS1 accepts on D, then stops
Streaming starts, topology change finishes, A is removed
CAS3 prepares using C and D. It sees the accept of CAS1 and replays it
Both CAS1 and CAS2 are committed.
Bug: Ant publish still trying to fetch maven dependencies using HTTP
Status: Triage Needed
Priority: Normal
Created: 13/May/20 06:22

Currently maven central repo is not accepting HTTP requests anymore and have fully switched to HTTPS. This has been addressed in this commit: [https://github.com/apache/cassandra/commit/63ff65a8dd3a31e500ae5ec6232f1f9eade6fa3d]

However `maven-ant-tasks` has been deprecated and is still fetching dependencies using HTTP, which fails when trying to publish the Cassandra jar. Basically, an alternative solution to `maven-ant-tasks` needs to be implemented for deployment.

I have attached the log from running `ant publish`.
Bug: BinLog deadlock on stopping when the sample queue is full
Status: Resolved
Priority: Normal
Resolution: Not A Bug
Created: 09/May/20 23:42
Resolved: 11/May/20 07:33

A deadlock can happen when 1) the BinLog is being stoped and 2) the BinLog's internal sample queue is full. 

When stopping, BinLog first set the flag shouldContinue to false, so that the internal consumer thread stop consuming. It is possible to leave the queue being full.
Then, the BinLog puts one extra object NO_OP into the sample queue. However, the queue is already full, so the put operation blocks, and the stop method never returns. 
Therefore, we got a deadlock.

BinLog is used by Cassandra 40 new features such as audit logging and full query logging. 
If such deadlock happens, the thread cannot be not joined and the referenced items in the queue are never released, hence memory leak.
Bug: Get-by-index introduced in CASSANDRA-15394 could have negative performance impact on non-RandomAccess List
Status: Open
Priority: Normal
Created: 27/Apr/20 18:52

CASSANDRA-15394 replaced the iterator based iteration with the get-by-index one to avoid allocation iterators. 
It works for the lists that support RandomAccess, i.e. the big O of {{get()}} is {{O(1)}}. 
However, it fails when the list does not support RandomAccess. The {{get()}} method's time complexity can be linear, and it leads to {{O(n^2)}} for the overall iteration. 
The implementation should provide different behaviors based on the property.
Bug: 3.11.6 Image Vulnerabilities
Status: Resolved
Priority: Normal
Resolution: Won't Fix
Created: 04/May/20 18:07
Resolved: 05/May/20 16:13

My team has taken the Bitnami Cassandra image, 3.11.6, and scanned it using our image vulnerability scanner, and discovered 4 issues. These are CVE-2019-5436, CVE-2019-5481, CVE-2019-5482, CVE-2020-1967. The solutions entail updating 1) curl and 2) openssl in the image, as described in the attached image.
Bug: CQLSH doesn't exit with proper code with multiple SOURCE directives.
Status: Triage Needed
Priority: Normal
Created: 04/May/20 20:46

When I have the following files;

 
{code:java}
# master.sql

CREATE TABLE asdf (  id text,  primary key (id));{code}
{code:java}
# a.sql

SOURCE './master.sql';

CREATE TABLE asdf (  id text,  primary key (id));{code}
{code:java}
# b.sql

SOURCE './a.sql';{code}
 
 and execute
{code:java}
cqlsh --keyspace example --file ./b.sql{code}
 

I don't get returned the proper status code. This happens because when multiple SOURCE commands are chained together like in the example above, the error doesn't get passed through to the final 'shell'. 

 

Subshell that needs to pass the statement error value to the parent shell: https://github.com/apache/cassandra/blob/trunk/bin/cqlsh.py#L1776
 final statement error check which returns the parent shell statement error: [https://github.com/apache/cassandra/blob/trunk/bin/cqlsh.py#L2474]
Bug: Implement resultMetadata flag for a conditional statement or batch
Status: Triage Needed
Priority: Normal
Created: 21/Apr/20 13:44

The way Paxos protocol works is that if two queries attempt to update the same key from different coordinators, they will start two independent Paxos rounds. Each round will be assigned a timestamp, and the coordinator who has the highest timestamp will win.
If rounds are started at different nodes, the coordinator with lower ballot sleeps a random interval and retries.

If the key is contended this leads to a lot of retries to make an update, since most client drivers will round-robin over different coordinators.

Instead, for LWT queries the driver should choose coordinators in a pre-defined order, so that in case of contention they will queue up at the coordinator, rather than compete: choose the primary replica first, then, if the primary is known to be down, the first secondary, then the second secondary, and so on.
This will reduce contention over hot keys and thus increase LWT performance.

Unfortunately, the driver is not aware it works with an LWT statement. Identifying such statement purely on the client is also difficult: it requires parsing the statement text. LWT statements require a flag  set to always include result set metadata, so most applications have the extra burden of detecting LWT and setting this flag.

So, in order to make it easy for the driver to choose the replica in a pre-defined order, and avoid contention, as well as avoid having to parse the CQL on the client to set DisableSkipMetadata flag on the query, Cassandra should return LWT flag in resultMetadata flags for LWT statements. This is a backward compatible change which can be done in any version of the server, since drivers are already ignoring unknown flags.
Bug: Mutation size exceeds max limit - clients get timeout?
Status: Triage Needed
Priority: Normal
Created: 20/Apr/20 05:48

Raising this ticket based on the discussion from CASSANDRA-14781 to validate that co-oridinator returns timeout when mutation size exceeds maximum limit (need to add a jvm-dtest to confirm). If it throws timeout or any other exception which doesn't reflect properly, then response should be modified to throw meaningful exception immediately.
Bug: Modify cassandra.yaml and replace the default data location, still data stored in default location
Status: Resolved
Priority: Normal
Resolution: Works for Me
Created: 14/Apr/20 06:36
Resolved: 15/Apr/20 15:12

I have created a separated directory (/mnt/) for cassandra data, commit log, hint and saved_cache. But data are not created on created directory, stored in default location /var/lib/cassandra/data.

 

*Configuration File:*

[root@node-master cassandra]# cat /etc/cassandra/default.conf/cassandra.yaml | grep /mnt/

hints_directory: */mnt/*hints

    - */mnt/*data

commitlog_directory: */mnt/*commitlog

cdc_raw_directory: */mnt/*cdc_raw

saved_caches_directory: */mnt/*saved_caches

 

Please help me to resolve this issue.