av9ash/GitBugs huggingface dataset:
Bug: Fully purged static row causes NPE in repaired data tracking
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 03/Jun/20 11:16
Resolved: 09/Jun/20 14:20

During repaired data tracking, if the result of applying the purge function to a static row is null, an exception is thrown from RepairedDataInfo. This will cause a read exception from the replica and could lead to unavailable results if hit on multiple replicas. A workaround is to disable repaired data tracking.
Bug: Add bytebuddy support for in-jvm dtests
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 04/Jun/20 07:46
Resolved: 10/Jul/20 08:40

Old python dtests support byteman, but that is quite horrible to work with, [bytebuddy|https://bytebuddy.net/#/] is much better, so we should add support for that in the in-jvm dtests.
Bug: Delete and save with same keys
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 18/Jun/20 20:38
Resolved: 09/Dec/20 14:20

I have a table like this: key1, key2, key3, column1, column2.

 

When I delete a row with keys 1, 2, 3. and then insert a new row almost immediately with the same keys, cassandra does not store the new row even though the query executes successfully. 

How can I force Cassandra to store the new row, or do I have to change my data model?

EDIT:

I'm running Cassandra 3.11.6 in Docker, a single instance for development purposes.

This has happen already with 3 tables.
{code:java}
// CREATE TABLE my_keyspace.my_chat ( country text, user_id timeuuid, chat_id bigint, email text, first_name text, last_name text, username text, PRIMARY KEY (country, user_id, chat_id));
{code}
{code:java}
// CREATE TABLE my_keyspace.my_profile (CREATE TABLE my_keyspace.my_profile ( country text, user_id timeuuid, profile_code text, id_doc text, id_doc_type text, user_email text, user_name text, PRIMARY KEY (country, user_id)) WITH CLUSTERING ORDER BY ( user_id DESC );
{code}
{code:java}
// CREATE TABLE my_keyspace.role ( realm text, business_id timeuuid, user_id timeuuid, owner_id timeuuid, name text, status text, icon text, url text, description text, owner_email text, owner_name text, scope_id timeuuid, scope_name text, scopes SET<text>, authorization boolean, user_email text, user_name text, views SET<FROZEN<my_dt>>, PRIMARY KEY (realm, business_id, user_id, owner_id, name, status)) WITH CLUSTERING ORDER BY ( business_id DESC, user_id DESC, owner_id DESC, name DESC, status DESC);
{code}
The value of the keys for this tables come from other tables or outside immutable data.

 

I'm also using the Datastax OSS Java Driver v4.7.0 for comunications with Cassandra, but the problem have also presented using cqlsh.

 

The queries I use are standard read by partition key, insert the whole row and delete by full partiion key.
Bug: Statistics upon streaming of entire SSTables in Netstats is wrong
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 06/Apr/20 08:04
Resolved: 22/Apr/20 21:29

There is a bug in the current code (trunk on 6th April 2020) as if we are streaming entire SSTables via CassandraEntireSSTableStreamWriter and CassandraOutgoingFile respectively, there is not any update on particular components of a SSTable as it counts only "db" file to be there. That introduces this bug:

 
{code:java}
Mode: NORMAL
Rebuild 2c0b43f0-735d-11ea-9346-fb0ffe238736
    /127.0.0.2 Sending 19 files, 27664559 bytes total. Already sent 133 files, 27664559 bytes total
        /tmp/dtests15682026295742741219/node2/data/distributed_test_keyspace/cf-196b3...
        ....
{code}
Basically, number of files to be sent is lower than files sent.

 

The straightforward fix here is to distinguish when we are streaming entire sstables and in that case include all manifest files into computation. 

 

This issue depends on CASSANDRA-15657 because the resolution whether we stream entirely or not is got from a method which is performance sensitive and computed every time. Once CASSANDRA-15657  (hence CASSANDRA-14586) is done, this ticket can be worked on.

 

branch with fix is here: [https://github.com/smiklosovic/cassandra/tree/CASSANDRA-15694]
Bug: test_optimized_primary_range_repair - transient_replication_test.TestTransientReplication
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 04/May/20 13:46
Resolved: 26/May/20 08:29

Dtest failure.
Example:
https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/118/workflows/9e57522d-52fa-4d44-88d8-5cec0e87f517/jobs/585/tests
Bug: Single partition queries can mistakenly omit partition deletions and resurrect data
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 03/Apr/20 17:57
Resolved: 16/Apr/20 17:48

We have logic that allows us to exclude sstables with partition deletions that are older than the minimum collected timestamp in a local request. However, it’s possible that another node could have rows that aren’t known to the local node that are in turn older than the excluded partition deletion. In such a scenario, those will be mistakenly resurrected, which is a correctness issue.
Bug: Improve BatchMetricsTest 
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 13/Apr/20 14:45
Resolved: 28/Apr/20 04:05

As noted in CASSANDRA-15582 {{BatchMetricsTest}} should test {{BatchStatement.Type.COUNTER}} to cover all the {{BatchMetrics}}.  Some changes were introduced to make this improvement at:

https://github.com/apache/cassandra/compare/trunk...spmallette:CASSANDRA-15582-trunk-batchmetrics

and the following suggestions were made in review (in addition to the suggestion that a separate JIRA be created for this change) by [~dcapwell]:

{quote}
* I like the usage of BatchStatement.Type for the tests
* honestly feel quick theories is better than random, but glad you added the seed to all asserts =). Would still be better as a quick theories test since you basically wrote a property anyways!
* https://github.com/apache/cassandra/compare/trunk...spmallette:CASSANDRA-15582-trunk-batchmetrics#diff-8948cec1f9d33f10b15c38de80141548R131 feel you should rename to expectedPartitionsPerLoggedBatch {Count,Logged,Unlogged}
* . pre is what the value is, post is what the value is expected to be (rather than what it is).
* 
* https://github.com/apache/cassandra/compare/trunk...spmallette:CASSANDRA-15582-trunk-batchmetrics#diff-8948cec1f9d33f10b15c38de80141548R150 this doesn't look correct. the batch has distinctPartitions mutations, so shouldn't max reflect that? I ran the current test in a debugger and see that that is the case (aka current test is wrong).
most of the comments are nit picks, but the last one looks like a test bug to me
{quote}
Bug: Attach cluster type to the error message in cassandra-diff
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 13/Apr/20 22:52
Resolved: 14/Apr/20 08:21

The exceptions get logged in the cassandra-diff do not contain cluster type. 
It is hard to tell whether the exceptions are caused by requesting the SOURCE or TARGET cluster. 
The error message could be more informative by including the cluster type.
Bug: Does  Cassandra 3.11.3/3.11.5  is affected by CVE-2019-10712 or not ?
Status: Resolved
Priority: Normal
Resolution: Invalid
Created: 07/Apr/20 13:35
Resolved: 20/Apr/20 15:50

Because  cassandra 3.11.3/3.11.5 rely on jackson-mapper-asl-1.9.13.jar which has been reported a vulnerability CVE-2019-10172, [https://nvd.nist.gov/vuln/detail/CVE-2019-10172], so I want to know if it has an impact to cassandra. Thanks!
Bug: InstanceClassLoader fails to load with the following previously initiated loading for a different type with name "org/w3c/dom/Document"
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 10/Apr/20 22:26
Resolved: 20/Apr/20 20:41

java.lang.LinkageError: loader constraint violation: loader (instance of org/apache/cassandra/distributed/shared/InstanceClassLoader) previously initiated loading for a different type with name "org/w3c/dom/Document”

This is caused when using dtest outside of the normal Cassandra context.  There is no API to add more exclusions so unable to work around this.
Bug: in-jvm dtest IInstance and ICoordinator should use QueryResult as the base API
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 23/Apr/20 16:32
Resolved: 06/May/20 20:23

ICoordinator was modified to have a executeWithResult which returns a QueryResult, but not all query APIs have this. We should fix it so the base interface is executeWithResult and return QueryResult, but update all Object[][] methods to default to calling this.

This would be a breaking change so would need to be updated in each branch.
Bug: Fix unit tests to load test/conf/cassandra.yaml (so to listen on a valid ip)
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 25/Jun/20 12:48
Resolved: 07/Jul/20 09:32

Many of the ci-cassandra jenkins runs fail on {{ip-10-0-5-5: Name or service not known}}. CASSANDRA-15622 addressed some of these but many still remain. Currently test C* nodes are either failing or listening on a public ip depending on which agent they end up.

The idea behind this ticket is to make ant force the private VPC ip in the cassandra yaml when building, this will force the nodes to listen on the correct ip.
Bug: Invalid version value: 4.0~alpha4 during startup
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 22/May/20 08:49
Resolved: 29/May/20 13:20

Hi:

We are testing the latest cassandra-4.0 on Centos 7 using a clean database.  When we started cassandra the first time, everything is fine.  However, when we stop and restart cassandra, we got the following error and the db refuses to startup:

{code}
ERROR [main] 2020-05-22 05:58:18,698 CassandraDaemon.java:789 - Exception encountered during startup
java.lang.IllegalArgumentException: Invalid version value: 4.0~alpha4
 at org.apache.cassandra.utils.CassandraVersion.<init>(CassandraVersion.java:64)
 at org.apache.cassandra.io.sstable.SSTableHeaderFix.fixNonFrozenUDTIfUpgradeFrom30(SSTableHeaderFix.java:84)
 at org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:250)
 at org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:650)
 at org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:767)
{code}

The only way to get the node up and running again is by deleting all data under /var/lib/cassandra.

 

Is that a known issue?

Thanks, Eric
Bug: Add token to tombstone warning and error log message
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 22/Jun/20 17:25
Resolved: 23/Jun/20 19:11

If Cassandra scans too many tombstones while reading a partition, then it prints log messages with query based on warning/failure thresholds. The token is not printed in the log message. If tombstones are hurting the instance/replica set, then running force compaction for the partition ("nodetool compact" using start and end tokens i.e. token -/+ some delta) is one of the actions taken to recover. In order to find out the token, someone has to manually connect to cluster and run SELECT TOKEN query. Printing token with the log message helps to avoid manual effort and execute force compaction quickly.
Bug: Avoid per-host hinted-handoff throttle being rounded to 0 in large cluster
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 06/Jun/20 17:26
Resolved: 10/Jul/20 13:49

When "hinted_handoff_throttle_in_kb" is sufficiently small or num of nodes in the cluster is sufficiently large, the per-host throttle will be rounded to 0, aka. unthrottled.

 
{code:java|title=HintsDispatchExecutor.java}
int throttleInKB = DatabaseDescriptor.getHintedHandoffThrottleInKB() / nodesCount;
this.rateLimiter = RateLimiter.create(throttleInKB == 0 ? Double.MAX_VALUE : throttleInKB * 1024);
{code}
[trunk-patch|https://github.com/apache/cassandra/pull/616]
Bug: Warn or fail to start server when G1 is used and Xmn is set
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 29/May/20 05:58
Resolved: 24/Jun/20 11:01

In jvm.options, we currently have a comment above where Xmn is set that says that you shouldn't set Xmn with G1 GC.  That isn't enough - we should either warn in the logs or fail startup when they are set together.
Bug: cqlsh_tests.test_cqlsh.TestCqlsh.test_pycodestyle_compliance fails on trunk
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 16/Apr/20 07:17
Resolved: 17/Apr/20 08:56

This recently started to fail with Python 3.8 as can be seen [here|https://ci-cassandra.apache.org/job/Cassandra-trunk/73/testReport/junit/cqlsh_tests.test_cqlsh/TestCqlsh/test_pycodestyle_compliance/]
Bug: Ec2Snitch fails on upgrade in legacy mode
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 16/Jun/20 15:12
Resolved: 29/Jun/20 16:26

CASSANDRA-7839 changed the way the EC2 DC/Rack naming was handled in the Ec2Snitch to match AWS conventions.

The "legacy" mode was introduced to allow upgrades from Cassandra 3.0/3.x and keep the same naming as before (while the "standard" mode uses the new naming convention).

When performing an upgrade in the us-west-2 region, the second node failed to start with the following exception:

 
{code:java}
ERROR [main] 2020-06-16 09:14:42,218 Ec2Snitch.java:210 - This ec2-enabled snitch appears to be using the legacy naming scheme for regions, but existing nodes in cluster are using the opposite: region(s) = [us-west-2], availability zone(s) = [2a]. Please check the ec2_naming_scheme property in the cassandra-rackdc.properties configuration file for more details.
ERROR [main] 2020-06-16 09:14:42,219 CassandraDaemon.java:789 - Exception encountered during startup
java.lang.IllegalStateException: null
	at org.apache.cassandra.service.StorageService.validateEndpointSnitch(StorageService.java:573)
	at org.apache.cassandra.service.StorageService.checkForEndpointCollision(StorageService.java:530)
	at org.apache.cassandra.service.StorageService.prepareToJoin(StorageService.java:800)
	at org.apache.cassandra.service.StorageService.initServer(StorageService.java:659)
	at org.apache.cassandra.service.StorageService.initServer(StorageService.java:610)
	at org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:373)
	at org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:650)
	at org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:767)
{code}
 

The exception leads back to [this piece of code|https://github.com/apache/cassandra/blob/cassandra-4.0-alpha4/src/java/org/apache/cassandra/locator/Ec2Snitch.java#L183-L185].

After adding some logging, it turned out the DC name of the first upgraded node was considered invalid as a legacy one:
{code:java}
INFO  [main] 2020-06-16 09:14:42,216 Ec2Snitch.java:183 - Detected DC us-west-2
INFO  [main] 2020-06-16 09:14:42,217 Ec2Snitch.java:185 - dcUsesLegacyFormat=false / usingLegacyNaming=true
ERROR [main] 2020-06-16 09:14:42,217 Ec2Snitch.java:188 - Invalid DC name us-west-2
{code}
 

The problem is that the regex that's used to identify legacy dc names will match both old and new names : 
{code:java}
boolean dcUsesLegacyFormat = !dc.matches("[a-z]+-[a-z].+-[\\d].*");
{code}
Knowing that some dc names didn't change between the two modes (us-west-2 for example), I don't see how we can use the dc names to detect if the legacy mode is being used by other nodes in the cluster.
  
 The rack names on the other hand are totally different in the legacy and standard modes and can be used to detect mismatching settings.
  
 My go to fix would be to drop the check on datacenters by removing the following lines: [https://github.com/apache/cassandra/blob/cassandra-4.0-alpha4/src/java/org/apache/cassandra/locator/Ec2Snitch.java#L172-L186]
Bug: Code comment with issue number
Status: Triage Needed
Priority: Normal
Created: 23/Jun/20 07:25

When I read the code of cassandra, I find some comments with issue numbers. One of them comes from JavaDriverClient.java:
{code:java}
public JavaDriverClient(StressSettings settings, String host, int port, EncryptionOptions encryptionOptions){
   ...
   //Always allow enough pending requests so every thread can have a request pending
    //See https://issues.apache.org/jira/browse/CASSANDRA-7217
    int requestsPerConnection = (maxThreadCount / connectionsPerHost) + connectionsPerHost;        
    maxPendingPerConnection = settings.mode.maxPendingPerConnection == null ? Math.max(128, requestsPerConnection ) : settings.mode.maxPendingPerConnection;
}{code}
These comments are quite useful for other programmers and me to understand the code, but I notice that not all issue numbers are written in code comments. It can be already quite tedious to write them into commit messages :)

 

To handle the problem, I implemented a tool to automatically instrument issue numbers into code comments. I tried my tool on activemq, and the instrumented version is [https://github.com/ackelcn/cassandra] 

 

To avoid confusion, if there is already an issue number in code comments, my tool ignored the issue number. All my generated comments start from //IC, so it is easy to find them.

 

Would you please some feedbacks to my tool? Please feel free to merge my generated comments in your code, if you feel that some are useful.
Bug: Jenkins pipeline small fixes: slack notification body, StabilityTestDataPublisher, archive cassandra-test-report.txt
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 13/Jun/20 15:54
Resolved: 24/Jun/20 10:26

1) The slack notification bodies contain an array of SHA commit messages involved in the build. The array needs to be formatting.
See https://the-asf.slack.com/archives/CS6CA748J/p1592029643136500

2) Remove cassandra-builds directory in Summary stage, so 'Restart from Stage' builds work. If the pipeline gets into the final Summary stage it will clone the cassandra-builds directory. Once this happens it is not possible to restart the pipeline. Restarting from a given stage is useful if one of the test stages failed for unknown/infrastructure reasons.

3) Archive the cassandra-test-report.txt artifact. This plaintext report was added under CASSANDRA-15729. It should also be made easily available as a downloadable artefact on the build.

4) Add StabilityTestDataPublisher to the pipeline junit results. This provides the flakey info next to each test on the test results page. The individual test stages had this enabled, but not the pipeline. For example here: https://github.com/apache/cassandra-builds/blob/master/jenkins-dsl/cassandra_job_dsl_seed.groovy#L252
Bug: Followup on CASSANDRA-15600
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 15/Jun/20 22:06
Resolved: 23/Jun/20 19:19

As part of CASSANDRA-15600  generateSplits method replaced the generateRandomTokens for NoReplicationAwareTokenAllocator.  generateSplits should be used also in ReplicationAwareTokenAllocator.
Bug: sstablemetadata should show tombstone timestamp not just the local drop time
Status: Resolved
Priority: Normal
Resolution: Invalid
Created: 18/Jun/20 13:01
Resolved: 22/Jun/20 22:34

issue/request:

sstablemetadata should show tombstone timestamp not just the local drop time

 

I'm  not sure what all versions this exists in but the sstablemetadata tombstone "drop time" only just shows the local delete time of the tombstones.  What's more important (what the tombstone expiration time depends on) is the tombstone writetime (tombstone timestamp).  It's possible to, and a surprising number of users have done this, write a tombstone with a timetamp in the future (by doing "DELETE...USING TIMESTAMP <future_timestamp>").  When this happens, the tombstone hangs around in sstables for a lot longer than users expect because
{code:java}
tombstone_expiration_time = gc_grace_seconds + tombstone_timestamp{code}
NOT
{code:java}
 tombstone_expiration_time = gc_grace_seconds + tombstone_local_delete_time{code}
and the sstablemetadata output doesn't help here because it only shows the local delete time, not the actual tombstone timestamp that's used to calculate tombstone expiration time.
Bug: All test targets to set jvm arg "java.io.tmpdir" according to ${tmp.dir}
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 30/Apr/20 11:43
Resolved: 30/Apr/20 17:50

Make all test targets declare the temp directory (java.io.tmpdir) as defined by tmp.dir

This was originally done in CASSANDRA-7712 but has been eroded over time as the test targets evolved.

The attached patch moves the 
{code}<jvmarg value="-Djava.io.tmpdir=${tmp.dir}"/>{code}
into the {{testmacrohelper}} macrodef.

Like CASSANDRA-7712, jenkins agents are filling up their root volumes because of what's left behind under {{"/tmp"}}

The build scripts have already been configured to define the temp directory to be within the jenkins job's workspace: https://github.com/apache/cassandra-builds/commit/33ba1e30ea196180f7d70f8e6ec47fdf6844f3f6#diff-91876f5f158ec50dab9a70cc06c06922
Bug: Fix flaky junit.framework.TestSuite.org.apache.cassandra.io.sstable.CQLSSTableWriterTest-cdc
Status: Resolved
Priority: Normal
Resolution: Duplicate
Created: 01/Jun/20 08:55
Resolved: 09/Jun/20 08:45

Failing for the past [29 buils|https://ci-cassandra.apache.org/job/Cassandra-trunk/154/testReport/junit.framework/TestSuite/org_apache_cassandra_io_sstable_CQLSSTableWriterTest_cdc/]

java.lang.NullPointerException
	at org.apache.cassandra.db.commitlog.CommitLogSegmentManagerCDC$CDCSizeTracker.shutdown(CommitLogSegmentManagerCDC.java:312)
	at org.apache.cassandra.db.commitlog.CommitLogSegmentManagerCDC.shutdown(CommitLogSegmentManagerCDC.java:89)
	at org.apache.cassandra.db.commitlog.AbstractCommitLogSegmentManager.stopUnsafe(AbstractCommitLogSegmentManager.java:413)
	at org.apache.cassandra.db.commitlog.CommitLog.stopUnsafe(CommitLog.java:467)
	at org.apache.cassandra.SchemaLoader.cleanupAndLeaveDirs(SchemaLoader.java:785)
	at org.apache.cassandra.io.sstable.CQLSSTableWriterTest.setup(CQLSSTableWriterTest.java:62)
Bug: [CQL help] URL for help topic CREATE_KEYSPACE is leading to page that does not exist
Status: Triage Needed
Priority: Normal
Created: 11/Apr/20 19:18

URL for help topic CREATE_KEYSPACE is leading to page that does not exist
{code:java}
cqlsh> SHOW VERSION;
[cqlsh 5.0.1 | Cassandra 3.11.6 | CQL spec 3.4.4 | Native protocol v4]
cqlsh> HELP CREATE_KEYSPACE;
*** No browser to display CQL help. URL for help topic CREATE_KEYSPACE : https://cassandra.apache.org/doc/cql3/CQL-3.2.html#createKeyspaceStmt
{code}
Page "https://cassandra.apache.org/doc/cql3/CQL-3.2.html#createKeyspaceStmt" is showing 404 "Not Found". (see screenshot attachment)

How did I install C* (From the book "Cassandra The Definitive Guide, Third Edition, page 53")
{code:java}
docker pull cassandra
docker run --name c-seed cassandra
docker exec -it c-seed cqlsh
HELP CREATE_KEYSPACE;
{code}
 It is probably related to this part of code: [https://github.com/apache/cassandra/blob/d069fd235f3553ef6e3267efc9cf3b9b2fe4e70e/bin/cqlsh.py#L76]

Probably we need to replace:

CASSANDRA_CQL_HTML_FALLBACK = 'https://cassandra.apache.org/doc/cql3/CQL-3.2.html'

with

CASSANDRA_CQL_HTML_FALLBACK = 'https://cassandra.apache.org/doc/old/CQL-3.0.html'
Bug: Add deb and rpm packaging to artifacts test script
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 28/May/20 21:39
Resolved: 04/Jun/20 15:24

Currently we have no way of testing debian or rpm packaging. This is a problem, it hurts when cutting releases as well as afterwards (like CASSANDRA-15830). 

This ticket is to add testing of debian or rpm packaging into the artifacts test script.

This will also provide "nightly" build artifacts for the deb and rpm packages.