av9ash/GitBugs huggingface dataset:
Bug: Consider removing MAXWRITETIME function
Status: Open
Priority: Normal
Created: 29/Nov/22 12:53

CASSANDRA-17425 added a new {{MAXWRITETIME}} function that allows to retrieve the maximum timestamp of a multi-cell column. For example:
{code:java}
> CREATE TABLE t (k int PRIMARY KEY, v set<int>);
> INSERT INTO t (k, v) VALUES (1, {1, 2}) USING TIMESTAMP 100;
> UPDATE t USING TIMESTAMP 200 SET v += {3} WHERE k=1;
> SELECT maxwritetime(v) FROM t;

 maxwritetime(v)
-----------------
             200
{code}
Later, CASSANDRA-8877 added the means to retrieve the write times and TTLs of each of the cells in a multi-cell column:
{code:java}
> SELECT writetime(v) FROM t;

 writetime(v)
-----------------
 [100, 100, 200]

> SELECT writetime(v[1]) FROM t;

 writetime(v[1])
-----------------
             100
{code}
Quite recently, CASSANDRA-18060 has added generic CQL functions to get the min and max items in a collection. Those functions can be used in combination with the classic {{writetime}} function to get the same results as the new {{maxwritetime}} function:
{code:java}
> SELECT collection_max(writetime(v)) FROM t;

 system.collection_max(writetime(v))
-------------------------------------
                                 200
{code}
Those new functions can also be used to get the min timestamp, or the min/max TTL, for which there isn't a specific function:
{code:java}
SELECT collection_min(writetime(v)) FROM t;
SELECT collection_max(writetime(v)) FROM t;
SELECT collection_avg(writetime(v)) FROM t;
SELECT collection_min(ttl(v)) FROM t;
SELECT collection_max(ttl(v)) FROM t;
SELECT collection_avg(ttl(v)) FROM t;
{code}
I think this makes the new {{maxwritetime}} mostly redundant, since the new functions can achieve the same results in a more generic way. Since the new {{maxwritetime}} function is only on trunk, we should consider whether we want to remove it in favour of the generic functions.
Bug: Allow DB role names to prefix with a number
Status: Resolved
Priority: Normal
Resolution: Not A Problem
Created: 05/Dec/22 13:26
Resolved: 13/Jun/24 10:35

{{*Works -* CREATE ROLE IF NOT EXISTS test WITH PASSWORD='somepassword' AND LOGIN=true;}}
 
{{*Works* - CREATE ROLE IF NOT EXISTS test123 WITH PASSWORD='somepassword' AND LOGIN=true;}}
 
{{*Breaks* - CREATE ROLE IF NOT EXISTS 123test WITH PASSWORD='somepassword' AND LOGIN=true;}}
{color:#de350b}{{SyntaxException: line 1:26 no viable alternative at input '123' (CREATE ROLE IF NOT EXISTS [123]...)}}{color}{{{{}}{}}}
 
It would be helpful and more consistent to be able to prefix roles with a numeric value instead of only being able to do this as a suffix.

Env Details are:

[cqlsh 6.0.0 | Cassandra 4.0.3 | CQL spec 3.4.5 | Native protocol v5]
Bug: Update CCM for JDK17 and revise current JDK detection strategy
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 09/Dec/22 16:42
Resolved: 14/Mar/23 14:59

As part of CASSANDRA-16895 initial POC an initial version of CCM patch was created. This needs to be revisited and reviewed

Recently we closed CASSANDRA-18039 which brought questions, probably we need to revise how we detect JDK versions in CCM and whether it is correct. To the best of my knowledge there are certain tests in the repo around that and they pass so my guess is we need to revise just the strategy and maybe document it explicitly or consider if we want any changes to be applied. Also, we need to be careful with breaking changes.
Bug: Data loss after a system restart of 3.11.17/4.1.4
Status: Open
Priority: Normal
Created: 09/Dec/22 21:49

When we upgrade Cassandra from 3.11.17 to 4.0.12, we found a data loss during the upgrade process. This bug can also be triggered if simply performing a system restart for 3.11.17, 4.0.12 or 4.1.4.
h1. Steps to reproduce

Start a 3.11.15 or 4.1.4 Cassandra node using default configurations. Execute the following cqlsh commands.
{code:java}
CREATE KEYSPACE  ks WITH REPLICATION = { 'class' : 'SimpleStrategy', 'replication_factor' : 1 };
CREATE TABLE IF NOT EXISTS ks.tb (c1 INT,c3 INT,c2 TEXT, PRIMARY KEY (c1 )) WITH speculative_retry = 'ALWAYS';
INSERT INTO ks.tb (c1, c2) VALUES (2,'val');
ALTER TABLE ks.tb DROP c2 ;
ALTER TABLE ks.tb RENAME c1 TO c2; {code}
Then execute a SELECT command, we get the correct data
{code:java}
cqlsh> SELECT *  FROM ks.tb;
 c2 | c3
----+------
  2 | null

(1 rows){code}
Flush and stop the Cassandra daemon.
{code:java}
bin/nodetool flush
bin/nodetool stopdaemon{code}
Then restart the node.
{code:java}
bin/cassandra{code}
Start cqlsh, and execute the same SELECT command. The data in ks.tb is lost.
{code:java}
cqlsh> SELECT *  FROM ks.tb;

 c2 | c3
----+----

(0 rows){code}
During the node restart, we found an error log about initializing the table, but it didn't prevent the system from starting up.
{code:java}
INFO  [main] 2022-12-09 21:37:54,234 ColumnFamilyStore.java:432 - Initializing ks.tb
ERROR [SSTableBatchOpen:1] 2022-12-09 21:37:54,237 CassandraDaemon.java:244 - Exception in thread Thread[SSTableBatchOpen:1,5,main]
java.lang.AssertionError: null
	at org.apache.cassandra.db.PartitionColumns$Builder.add(PartitionColumns.java:161)
	at org.apache.cassandra.db.SerializationHeader$Component.toHeader(SerializationHeader.java:340)
	at org.apache.cassandra.io.sstable.format.SSTableReader.open(SSTableReader.java:522)
	at org.apache.cassandra.io.sstable.format.SSTableReader.open(SSTableReader.java:385)
	at org.apache.cassandra.io.sstable.format.SSTableReader$3.run(SSTableReader.java:570)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
	at org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:84)
	at java.lang.Thread.run(Thread.java:750) {code}
This bug can also be triggered if we perform an upgrade (with drain) from 3.11.17 to 4.0.12 or 4.1.4 and execute the SELECT command in the new version.
Bug: Update JNA
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 15/Nov/22 15:45
Resolved: 10/Feb/23 11:47

JNA needs to be updated for JDK 17 support. There was an update pre-4.0 but not to the latest version (confirmed with the people involved, there was no particular reason not to update to the latest version, just missed on rebase of older PR)
More details to come, opening this as a placeholder for now
Bug: Cassandra code style and static analysys
Status: Triage Needed
Priority: Normal
Created: 04/Dec/22 20:05

This is an umbrella ticket that aggregates all activities related to improving code style guides as well as adding new tools for code analysis.

Despite the fact that expanding the code style rules and adding such checks to the source code may take a long time, the main goals for this epic are:
- add a static code analysis automatic checks support (SpotBug) to the build;
- in terms of automatic code checking make GitHub pull requests more convenient;
- update the checkstyle configuration;


*Cassandra code style guide*:
[https://cassandra.apache.org/_/development/code_style.html]
https://cwiki.apache.org/confluence/display/CASSANDRA2/CodeStyle


Discussion _Code style and static analysis_ on the dev list: 
[https://lists.apache.org/thread/11j0hrv2bkx60xk7zvlgqgjwo982qv6h]

Discussion _Add SpotBugs to the build_ on the dev list:
[https://lists.apache.org/thread/1ro1mvkpvt4vr24nw7dbpdlxo82mq3hz]
Bug: Test failure: org.apache.cassandra.service.LeaveAndBootstrapTest.testSimultaneousMove
Status: Open
Priority: Normal
Created: 14/Nov/22 20:52

Flaky tests on trunk, seen [here|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2129/workflows/1d772092-d5dc-4677-8ba8-23fdca42a221/jobs/16705/tests#failed-test-0]


{code:java}
 java.lang.NullPointerException
	at org.apache.cassandra.service.StorageService.updatePeerInfo(StorageService.java:2645)
	at org.apache.cassandra.service.StorageService.handleStateNormal(StorageService.java:3020)
	at org.apache.cassandra.service.StorageService.onChange(StorageService.java:2522)
	at org.apache.cassandra.service.LeaveAndBootstrapTest.testSimultaneousMove(LeaveAndBootstrapTest.java:354)
	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)
{code}
Bug: Test failure: o.a.c.distributed.test.PaxosRepair2Test.legacyPurgeRepairLoop
Status: Open
Priority: Normal
Created: 14/Nov/22 22:47

This test was introduced by CASSANDRA-18029
{code:java}
junit.framework.AssertionFailedError
	at org.apache.cassandra.distributed.test.PaxosRepair2Test.lambda$null$12(PaxosRepair2Test.java:528)
	at org.apache.cassandra.service.paxos.PaxosState.updateStateUnsafe(PaxosState.java:557)
	at org.apache.cassandra.distributed.test.PaxosRepair2Test.lambda$legacyPurgeRepairLoop$1b03105c$1(PaxosRepair2Test.java:522)
	at org.apache.cassandra.concurrent.FutureTask$1.call(FutureTask.java:96)
	at org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:61)
	at org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:71)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
	at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
	at java.lang.Thread.run(Thread.java:748) {code}
Bug: Column update lost after a full stop upgrade from 4.0.7 to 4.1.0
Status: Resolved
Priority: Normal
Resolution: Not A Problem
Created: 05/Dec/22 01:13
Resolved: 13/Sep/23 00:12

When we performed a full-stop upgrade from release 4.0.7 to 4.1.0, we executed the same read command before and after the upgrade and found that some column updates were lost after the upgrade.

This inconsistency is likely related to timing and cannot be reproduced deterministically. Though it's non-deterministic, this failure happens reliably once every ten times when executing the following command sequence. *I wrote a [script|https://github.com/hanke580/cass_18091] to reproduce it automatically.*
h2. Steps to reproduce

1. Set up a 4.0.7 3-node cluster. (N0: seed node, N1, N2). Default configurations, set num_tokens to 256.

2. Execute the following cqlsh command at N0

    (The test commands use random parameters because it is generated by our testing tool)
{code:java}
CREATE KEYSPACE  uuid5f86250110a247d48c481c5579cb2ea1 WITH REPLICATION = { 'class' : 'SimpleStrategy', 'replication_factor' : 1 };
CREATE TABLE  uuid5f86250110a247d48c481c5579cb2ea1.kattmG (kattmG TEXT,VldG TEXT,Ajqm TEXT,lTQSQ INT,EVzlSKrbkUGyhJshH TEXT, PRIMARY KEY (lTQSQ ));
DELETE FROM uuid5f86250110a247d48c481c5579cb2ea1.kattmG WHERE lTQSQ = 2;
ALTER TABLE uuid5f86250110a247d48c481c5579cb2ea1.kattmG DROP kattmG ;
INSERT INTO uuid5f86250110a247d48c481c5579cb2ea1.kattmG (Ajqm, EVzlSKrbkUGyhJshH, lTQSQ) VALUES ('nZJzNjYnXOwPLpVoFSVwxcvznsDFBYqmlprrVXYJQLzYvYkrmfEsiuAcCtggypnxIkIevRHyPQGOWrIZNObJ','RaAhbVKUQzgJaupaupKPVnNLLYDaZEaMyFteVwhLePqZwikuBEsVDxTuTqBfkFYmeMMsOFXjVkObZduPfAFsLzuYlrgpYsPPxDNQCRzzPaEdWHARnnWbAFAUUnbYnvEESeHDRHSkEhSnoREprrHWasYLMSocIYiMGQXjzsaKptqbtPgrztIdpQLgDAZOPfhJIblmwTFAWiFbzrbTkFwJGP',1693380861);
DELETE FROM uuid5f86250110a247d48c481c5579cb2ea1.kattmG WHERE lTQSQ = 1693380861;
INSERT INTO uuid5f86250110a247d48c481c5579cb2ea1.kattmG (lTQSQ) VALUES (2);
ALTER TABLE uuid5f86250110a247d48c481c5579cb2ea1.kattmG DROP VldG ;
INSERT INTO uuid5f86250110a247d48c481c5579cb2ea1.kattmG (lTQSQ) VALUES (1693380861);
INSERT INTO uuid5f86250110a247d48c481c5579cb2ea1.kattmG (Ajqm, lTQSQ) VALUES ('ldrsHa',1693380861);
ALTER TABLE uuid5f86250110a247d48c481c5579cb2ea1.kattmG DROP Ajqm ;{code}
3. Execute a SELECT command at N0, and get results
{code:java}
SELECT lTQSQ FROM uuid5f86250110a247d48c481c5579cb2ea1.kattmG;

 ltqsq
------------
 1693380861
          2
(2 rows){code}
4. Perform a full-stop upgrade. (Set num_tokens to 256)
   1. Drain N0, stop N0.
   2. Drain N1, stop N1.
   3. Drain N2, stop N2.
   4. Start up N0.
   5. Start up N1.
   6. Start up N2.

5. Execute the same SELECT command at N0, and get results
{code:java}
SELECT lTQSQ FROM uuid5f86250110a247d48c481c5579cb2ea1.kattmG;

 ltqsq
-------
     2
(1 rows){code}
Or
{code:java}
SELECT lTQSQ FROM uuid5f86250110a247d48c481c5579cb2ea1.kattmG;

 ltqsq
-------

(0 rows){code}
 

The new result is inconsistent with the old version's result. The insert update is lost.
Bug: Improve memtable allocator accounting when updating AtomicBTreePartition
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 19/Dec/22 12:46
Resolved: 07/Mar/23 17:58

On two nodes (on a 5 nodes cluster) on the cluster I'm running, I got the following exception. It occurred at 3,5 minutes interval.

{code}
MemtableReclaimMemory:2625 org.apache.cassandra.service.CassandraDaemon uncaughtException - Exception in thread Thread[MemtableReclaimMemory:2625,5,main]java.lang.AssertionError: null
	at org.apache.cassandra.utils.memory.MemtablePool$SubPool.released(MemtablePool.java:193)
	at org.apache.cassandra.utils.memory.MemtableAllocator$SubAllocator.releaseAll(MemtableAllocator.java:151)
	at org.apache.cassandra.utils.memory.MemtableAllocator$SubAllocator.setDiscarded(MemtableAllocator.java:142)
	at org.apache.cassandra.utils.memory.MemtableAllocator.setDiscarded(MemtableAllocator.java:93)
	at org.apache.cassandra.utils.memory.SlabAllocator.setDiscarded(SlabAllocator.java:120)
	at org.apache.cassandra.db.Memtable.setDiscarded(Memtable.java:201)
	at org.apache.cassandra.db.ColumnFamilyStore$Flush$1.runMayThrow(ColumnFamilyStore.java:1216)
	at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
	at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
	at java.base/java.lang.Thread.run(Thread.java:829)

{code} 

{code}
$ nodetool info
ID                     : 
Gossip active          : true
Native Transport active: true
Load                   : 204.67 GiB
Generation No          : 1670343179
Uptime (seconds)       : 1110514
Heap Memory (MB)       : 7218.07 / 24576.00
Off Heap Memory (MB)   : 784.06
Data Center            : par
Rack                   : e1
Exceptions             : 1
Key Cache              : entries 802712, size 100 MiB, capacity 100 MiB, 774541004 hits, 914207516 requests, 0.847 recent hit rate, 14400 save period in seconds
Row Cache              : entries 0, size 0 bytes, capacity 0 bytes, 0 hits, 0 requests, NaN recent hit rate, 0 save period in seconds
Counter Cache          : entries 0, size 0 bytes, capacity 50 MiB, 0 hits, 0 requests, NaN recent hit rate, 7200 save period in seconds
Percent Repaired       : 2.3272298419424144E-5%
Token                  : (invoke with -T/--tokens to see all 8 tokens)

$ java -version
openjdk version "11.0.16" 2022-07-19 LTS
OpenJDK Runtime Environment (Red_Hat-11.0.16.0.8-1.el7_9) (build 11.0.16+8-LTS)
OpenJDK 64-Bit Server VM (Red_Hat-11.0.16.0.8-1.el7_9) (build 11.0.16+8-LTS, mixed mode, sharing)
$ nodetool version
ReleaseVersion: 4.0.6
{code}
Bug: Guardrail: allow_filtering_custom_error_message
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 18/Oct/22 00:08
Resolved: 18/Nov/22 13:14

in Apache Cassandra Release Version 4.1 :
with "allow_filtering_enabled: false" option under guardrails :
regular users cannot run queries with allow filtering clause in SELECT commands. Users get following error message :
<stdin>:1:InvalidRequest: Error from server: code=2200 [Invalid query] message="Guardrail allow_filtering violated: Querying with ALLOW FILTERING is not allowed"

I propose for a new parameter in conf file : something like : allow_filtering_custom_error_message and allow cluster operators to configure custom message
so if someone runs a SELECT command along with "ALLOW FILTERING"
it should print ERROR : InvalidRequest:code=2202:message="STOP using allow_filtering clause"

so this will allow the operators to stop users from running allow filtering as well as give them to configure a custom error message.
Bug: Splitter sometimes creates different number of splits than requested
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 03/Nov/22 15:41
Resolved: 09/Nov/22 16:29

{{Splitter}} in some cases may produce one split more than requested. When it happens, it  fails with assertion error when assertions are enabled.

Test to reproduce the issue:

{code:java}
        Splitter splitter = getSplitter(Murmur3Partitioner.instance);
        long lt = 0;
        long rt = 31;
        Range<Token> range = new Range<>(getWrappedToken(Murmur3Partitioner.instance, BigInteger.valueOf(lt)),
                                         getWrappedToken(Murmur3Partitioner.instance, BigInteger.valueOf(rt)));

        for (int i = 1; i <= (rt - lt); i++)
        {
            List<Token> splits = splitter.splitOwnedRanges(i, Arrays.asList(new Splitter.WeightedRange(1.0d, range)), false);
            logger.info("{} splits of {} are: {}", i, range, splits);
            Assertions.assertThat(splits).hasSize(i);
        }
{code}
Bug: Update Chronicle Queue
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 15/Nov/22 15:40
Resolved: 22/Mar/23 08:05

According to [this|https://chronicle.software/chronicle-support-java-17] article:
{code:java}
Starting from chronicle-bom-2.22ea26, all new releases can be run under Java 17 when run on the class path (but not yet under the module path).{code}
This BOM is newer than what we currently have in both 4.1 and trunk. 4.1 points in comments to [https://mvnrepository.com/artifact/net.openhft/chronicle-bom/1.16.23] which I believe was just forgotten to be updated/removed. The versions we see correspond to this BOM [https://mvnrepository.com/artifact/net.openhft/chronicle-bom/2.20.226]

It is still older than chronicle-bom-2.22ea26 so we need to upgrade. I suggest we also add a comment again which BOM is considered, this makes things easier.

Further to running CI, review of the CHANGE logs needs to happen to ensure we do not miss anything that can impact us and it is not caught by our tests.

For testing with JDK17, please, contact [~e.dimitrova] for latest branch and CI config (at this point feature branch in the cassandra repo does not exist)
Bug: Config parameter keystore_password should be nullable
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 16/Dec/22 15:09
Resolved: 17/Apr/23 09:14

Some SSL configuration may pass unencrypted private keys. PEMReader might accept that by assuming keyPassword to be null in that case (e.g. https://github.com/apache/cassandra/blob/f9e033f519c14596da4dc954875756a69aea4e78/src/java/org/apache/cassandra/security/PEMReader.java#L103).

Current configuration reader does not accept keystore_password parameter to be set null or empty in the cassandra.yaml.
Bug: Add aggregation scalar functions on collections
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 18/Nov/22 10:58
Resolved: 25/Nov/22 14:12

The new mechanism for dynamically building native functions introduced by CASSANDRA-17811 can be used to provide within-collection aggregation functions. We can use that mechanism to add new CQL functions to get:
 * The number of items in a collection.
 * The max/min items of a collection.
 * The sum/avg of the items of a numeric collection.
 * The keys or the values of a map.

For example:
{code:java}
CREATE TABLE k.t (k int PRIMARY KEY, l list<int>, m map<int, int>);
INSERT INTO t(k, l, m) VALUES (0, [1, 2, 3], {1:10, 2:20, 3:30});

> SELECT map_keys(m), map_values(m) FROM t;

 system.map_keys(m) | system.map_values(m)
--------------------+----------------------
          {1, 2, 3} |         [10, 20, 30]

> SELECT collection_count(m), collection_count(l) FROM t;

 system.collection_count(m) | system.collection_count(l)
----------------------------+----------------------------
                          3 |                          3

> SELECT collection_min(l), collection_max(l) FROM t;

 system.collection_min(l) | system.collection_max(l)
--------------------------+--------------------------
                        1 |                        3

> SELECT collection_sum(l), collection_avg(l) FROM t;

 system.collection_sum(l) | system.collection_avg(l)
--------------------------+--------------------------
                        6 |                        2
{code}
Note that this type of aggregation is different from the kind of aggregation provided by {{min}}, {{max}}, {{sum}} and {{avg}}, which aggregate entire collections across rows. Here we only aggregate the items of a collection row per row.
Bug: CircleCI: Add jobs for running specialized unit tests with Java 11
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 24/Oct/22 12:26
Resolved: 03/Nov/22 11:51

CircleCI has a set of jobs for running specialiazed unit tests that are only run with Java 8:
 * utests_compression
 * utests_system_keyspace_directory
 * utests_trie
 * utests_stress
 * utests_long
 * utests_fqltool

It should probably be possible to run these tests with Java 11 tool.

Rather than creating a ticket for every job, it's probably easier to use a single ticket for all of them. This should give us an overall vision for deciding job names, approval steps, etc. Also, the required config changes should be quite minimal and doing all of them at once should save us both effort and test runs.
Bug: Remove ProtocolVersion entirely from the CollectionSerializer ecosystem
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 13/Dec/22 19:32
Resolved: 12/Jan/23 21:58

{{CollectionSerializer}} and its subclasses have completely ignored {{ProtocolVersion}} for a very long time. It’s possible we may need to version their behavior in the future, but there’s no reason to keep the dead code in the meantime, as it causes confusion around whether code that uses these classes needs to provide a version.
Bug: Opcodes.ASM7 to be updated when JDK17 support is added for Cassandra
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 18/Oct/22 20:29
Resolved: 09/Mar/23 09:23

In CASSANDRA-17873 we updated the ASM opcode inconsistencies for JDK11, we need to revise it again before we switch fro jdk8&11 to jdk11&17
Bug: cassandra-stress: not all contact point are passed down to driver
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 08/Nov/22 15:23
Resolved: 19/May/23 18:22

Seem like c-s is randomly selecting a node from the nodes passed down to it in the command line, and use that node as contact point to the driver.

 

When using c-s together with other management operations (for example expending/shrinking the cluster), we can get into situation some of the nodes mentioned in the command line aren't reachable/available, and c-s instead of applying the best practice of having multiple contact points, pass down only one that can be unavailable and fail completely without trying any of the other nodes mentioned in the command line

we just fixed that in our fork of cassandra-stress:

[https://github.com/scylladb/scylla-tools-java/pull/314]