av9ash/GitBugs huggingface dataset:
Bug: improve read_ahead_kb StartupCheck when using RAID disk
Status: In Progress
Priority: Normal
Created: 19/Apr/24 12:45

We believe the StartupChecks.java has a minor bug here:
[https://github.com/apache/cassandra/blob/cassandra-4.1/src/java/org/apache/cassandra/service/StartupChecks.java#L737]
{code:java}
String deviceName = blockDirComponents[2].replaceAll("[0-9]*$", "");{code}
We are using a RAID setup with two disks, so removing the "[0-9]" makes the check fail:


cat /sys/block/md/queue/read_ahead_kb
cat: /sys/block/md/queue/read_ahead_kb: No such file or directory

It should be "md0" in our case, so removing the '0' won't work.
Bug: incorrect queries showing up in queries virtual table
Status: Open
Priority: Normal
Created: 19/Apr/24 04:43

While running an easy-cass-stress workload I queried system_views.queries and got this (edited for sanity):

 
{noformat}
thread_id       | queued_micros | running_micros | task
-----------------+---------------+----------------+----
 MutationStage-2 |             0 |              0 | Mutation(keyspace='easy_cass_stress', key='3030312e302e3937363535', modifications=[\n  [easy_cass_stress.random_access] key=001.0.97655 partition_deletion=deletedAt=-9223372036854775808, localDeletion=2147483647 columns=[[] | [value]]\n    Row[info=[ts=1713501354789139] ]: row_id=291 | [value=SXFNPWZDYFHTUSBWMUQCTTRAHQWXMGYOHASTGDFYLILWMOSFQWZGKUAIPUUGCLTADKFFXZRQGKIJJLXNOQKMAIOVSSVMVSFSFAVPABIIHGQSGRPACFWCKYMZMSNZZARSBFVDASTMCRHAVAYHKQDZWFCHRUPDWZJVTEVIWKPMKLAOZGBUDFJVOPSAHLAIWOGNXZHCBVK ts=1713501354789139]\n])
     ReadStage-4 |             0 |           6216 |  SELECT * FROM easy_cass_stress.random_access WHERE partition_id = '001.0.18474' AND row_id = 746 LIMIT 5000 ALLOW FILTERING
{noformat}

What's interesting is that I supply neither a LIMIT or ALLOW FILTERING when I prepared the query.  I assume the limit is coming from the driver, and while it's technically correct from the standpoint of what it does, it's not what I prepared so it's a little weird to see it there.

The ALLOW FILTERING, on the other hand, was definitely not prepared.

{noformat}
 session.prepare("SELECT * from random_access WHERE partition_id = ? and row_id = ?")
{noformat}
Bug: [Analytics] Invalid mapping when timestamp is used as a partition key during bulk writes
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 17/Jun/24 23:43
Resolved: 20/Jun/24 21:45

When Cassandra has a table with a schema that includes a timestamp PK, i.e {{CREATE TABLE (a timestamp, b text, c text, PRIMARY KEY (a))}}, bulk writer maps the timestamp to a {{LongType}}. This causes the bulk writer job to produce a class cast exception when building the composite key during repartition and sorting of data in the spark job
Bug: Test failure: org.apache.cassandra.distributed.test.ClearSnapshotTest.clearSnapshotSlowTest-_jdk17
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 07/May/24 20:52
Resolved: 20/Jun/24 18:22

https://app.circleci.com/pipelines/github/driftx/cassandra/1625/workflows/d3849d2a-987e-49f8-9f4b-916c7ce85279/jobs/88752/tests

{quote}
junit.framework.AssertionFailedError
	at org.apache.cassandra.distributed.test.ClearSnapshotTest.clearSnapshotSlowTest(ClearSnapshotTest.java:123)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
{quote}
Bug: Avoid streams in the common case for UpdateTransaction creation
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 31/May/24 17:53
Resolved: 20/Jun/24 16:32

Some recent Accord profiling highlighted some easily addressable inefficiency in the way we create new {{UpdateTransaction}} objects in {{SecondaryIndexManager}} that have existed since the introduction of index groups for SAI. We should be able to clean this up by avoiding stream creation or even iteration over the groups when there is a single index group, which is going to be the most common case with SAI anyway. If we do have to iterate, there should also be no reason to copy the collection of index groups via {{listIndexGroups()}}, although that copying can remain in the method itself for external callers.

 !new_update_txn_streams.png!
Bug: Test failure: gossip_test.TestGossip::test_2dc_parallel_startup
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 07/May/24 20:48
Resolved: 20/Jun/24 15:17

As seen at https://app.circleci.com/pipelines/github/driftx/cassandra/1625/workflows/d3849d2a-987e-49f8-9f4b-916c7ce85279/jobs/88756/tests:

{quote}
failed on teardown with "Unexpected error found in node logs (see stdout for full details). Errors: [[node4] 'ERROR [Messaging-EventLoop-3-3] 2024-05-07 20:10:54,261 NoSpamLogger.java:110 - /127.0.0.4:7004->/127.0.0.1:7001-URGENT_MESSAGES-[no-channel] failed to connect\njava.nio.channels.ClosedChannelException: null\n\tat org.apache.cassandra.net.OutboundConnectionInitiator$Handler.channelInactive(OutboundConnectionInitiator.java:322)\n\tat io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:305)\n\tat io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:281)\n\tat io.netty.channel.AbstractChannelHandlerContext.fireChannelInactive(AbstractChannelHandlerContext.java:274)\n\tat io.netty.handler.codec.ByteToMessageDecoder.channelInputClosed(ByteToMessageDecoder.java:411)\n\tat io.netty.handler.codec.ByteToMessageDecoder.channelInactive(ByteToMessageDecoder.java:376)\n\tat io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:305)\n\tat io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:281)\n\tat io.netty.channel.AbstractChannelHandlerContext.fireChannelInactive(AbstractChannelHandlerContext.java:274)\n\tat io.netty.channel.DefaultChannelPipeline$HeadContext.channelInactive(DefaultChannelPipeline.java:1405)\n\tat io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:301)\n\tat io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:281)\n\tat io.netty.channel.DefaultChannelPipeline.fireChannelInactive(DefaultChannelPipeline.java:901)\n\tat io.netty.channel.AbstractChannel$AbstractUnsafe$7.run(AbstractChannel.java:813)\n\tat io.netty.util.concurrent.AbstractEventExecutor.runTask(AbstractEventExecutor.java:174)\n\tat io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:167)\n\tat io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:470)\n\tat io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:413)\n\tat io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:997)\n\tat io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)\n\tat io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)\n\tat java.base/java.lang.Thread.run(Thread.java:833)']"
{quote}
Bug: add jdk version and ant build date to nodetool: version
Status: Open
Priority: Normal
Created: 20/Jun/24 13:20

1. I have JDK 11, 17, and 21 installed locally, and it's sometimes inconvenient to determine which one I'm currently using. Although I can use the following approach:
 
{code:java}
➜ bin cat ../logs/system.log |grep "JDK"
INFO [main] 2024-06-18 19:11:19,801 CassandraDaemon.java:612 - JVM vendor/version: OpenJDK 64-Bit Server VM/11.0.23
 
➜ bin jcmd pid VM.version
54566:
OpenJDK 64-Bit Server VM version 11.0.23+9-LTS
JDK 11.0.23
{code}
 

2. I often build the source code locally, and I need the "ant build time" to confirm that this local cluster is using the tarball I built a few minutes ago.

 
{code:java}
The preview:
➜ bin ./nodetool version -v
ReleaseVersion: 5.1-SNAPSHOT
BuildDate: 2024-06-20 23:33:22 CST
GitSHA: 8def5d1faafca7c18cf640e19c67e5c205eb9b44
JVM vendor/version: OpenJDK 64-Bit Server VM/11.0.23
{code}
 

3. The git hash failed to add to ant MANIFEST.MF. and I fix it

 
{code:java}
How to check it:
 
jar xvf apache-cassandra-5.1-SNAPSHOT.jar | grep META-INF/MANIFEST.MF\n
cat META-INF/MANIFEST.MF
 
Manifest-Version: 1.0
Ant-Version: Apache Ant 1.10.14
Created-By: 11.0.23+9-LTS (Amazon.com Inc.)
Multi-Release: true
Implementation-Title: Cassandra
Implementation-Version: 5.1-SNAPSHOT
Implementation-Vendor: Apache
Implementation-Git-SHA: 8def5d1faafca7c18cf640e19c67e5c205eb9b44
Implementation-Build-Date: 2024-06-20 23:33:22 CST
{code}
Bug: Test failure: materialized_views_test.py::TestMaterializedViews::test_rename_column_atomicity
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 11/Jun/24 13:46
Resolved: 19/Jun/24 11:06

Breaking this out from CASSANDRA-19683.  The byteman script fails to execute in 5.0/trunk after CASSANDRA-19534.
Bug: CEP-15: (Accord) SyncPoint timeouts become a Exhausted rather than a Timeout and doesn’t get retried
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 18/Jun/24 20:30
Resolved: 18/Jun/24 23:30

In Cassandra we try to make sure coordinators return timeout if every call under it was also a timeout, this makes it easier to understand what is going on (coordination failure due to timeouts looks very different than us just timing out), but accord doesn't do this; leading to an Exhausted error (which we don't retry)
Bug: TWCS - Provide a flag to pick a time when compaction happens for the n-1 window
Status: Triage Needed
Priority: Normal
Created: 17/Jun/24 19:21

Below are the settings for the TWCS. With the settings below, the compaction for the n-1 window happens at around 00:00 UTC on all the nodes in the cluster. This causes a spike in IO utilization on the entire cluster, which in turn increases the read latencies.


{{{}compaction = { 'class' : 'org.apache.cassandra.db.compaction.TimeWindowCompactionStrategy', 'compaction_window_size' : 1, 'compaction_window_unit' : 'DAYS', 'max_threshold' : 32, 'min_threshold' : 4{}}}}


Requesting to provide a new option for TWCS where we can specify when the compaction for n-1 window happens. This way, we can provide a custom time instead of the default time(beginning of the new window) so that we can pick low-traffic hours and avoid impacting the customer.
Bug: CEP-15: (Accord) Bootstrap's LocalOnly txn can not be recreated from SerializerSupport
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 31/May/24 17:36
Resolved: 17/Jun/24 20:03

Bootstrap creates a LocalOnly txn and executes it rather than following the normal txn flow.  This has a problem as these mutations are not stored in the journal so a cache evict of the LocalOnly txn causes us to fail as we don’t know how to reconstruct it.
Bug: Support Direct I/O for SSTable writing
Status: Open
Priority: Normal
Created: 15/Jun/24 09:30

Based on the throughput improvements observed in CASSANDRA-18464, which introduced commit log Direct I/O support, it is logical to extend Direct I/O support to writing SSTables (specifically during memtable flushing and compaction).

The advantages of Direct I/O include consistent disk performance, as it eliminates reliance on the page cache for flushing dirty pages to disk, thus increasing write control. This is particularly beneficial during the writing of large SSTable files, such as during higher-tier compactions, as it prevents significant page cache thrashing with pages that are unlikely to be used again before being evicted. Additionally, Direct I/O reduces latency associated with double buffering, which occurs in both the application and the page cache in tradional buffered I/O.

This Jira ticket aims to initiate a discussion and gather feedback on this proposal. I am particularly interested in identifying any potential drawbacks that may affect specific workloads.

If the feature is agreed upon, extensive performance testing will be essential to evaluate its impact and determine its overall value.
Bug: Investigate stream pipelines in hot paths
Status: Open
Priority: Normal
Created: 31/May/24 15:17

As per discussion in (1), map where we are at with stream pipelines api. Based on that, the next step should be to get rid of them and replace it with "for-s" but we are not there yet.

 

https://lists.apache.org/thread/65glsjzkmpktzmns6j9wvr4nczvskx36
Bug: Disabling internode compression causes high CPU usage and load
Status: Triage Needed
Priority: Normal
Created: 12/Jun/24 09:20

I am not sure this is BUG or feature but cassandra is acting contrary to the belief that compression causes higher CPU usage. I have attached comparision graph - first part (left) is a identical cluster that have internode_compression={*}dc{*} and second part (right hand)  is internode_compression={*}all.{*}

Contrary to what one would thought, enabling compression causes signifficant drop in load and cpu usage.

!image001.jpg|width=532,height=327!

I am reporting it only becouse maybe there is different pipeline in cassandra that handles networking that is sub-optimal and does not handle high traffic well (just blind-shoot).

Any thoughts?
Bug: ClassCastException on selection with where clause from system.local_metadata_log
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 07/Jun/24 14:06
Resolved: 12/Jun/24 14:33

{code}
select * from system.local_metadata_log where epoch = 1;
NoHostAvailable: ('Unable to complete the operation against any hosts', {<Host: 172.19.0.12:9042 dc2>: <Error from server: code=0000 [Server error] message="java.lang.ClassCastException: class org.apache.cassandra.dht.Murmur3Partitioner$LongToken cannot be cast to class org.apache.cassandra.dht.ReversedLongLocalPartitioner$ReversedLongLocalToken (org.apache.cassandra.dht.Murmur3Partitioner$LongToken and org.apache.cassandra.dht.ReversedLongLocalPartitioner$ReversedLongLocalToken are in unnamed module of loader 'app')">})
{code}

same select but with "limit" works.
Bug: Tuple clustering slice queries return non-contiguous results for mixed asc/desc clustering columns.
Status: Triage Needed
Priority: Normal
Created: 11/Jun/24 20:31

Given the table:
{{CREATE TABLE ks.tbl (k int, c1 int, c2 int, v int, PRIMARY KEY (k, c1, c2)) WITH CLUSTERING ORDER BY (c1 ASC, c2 DESC)}}

(Note the different clustering orders of c1 and c2)

If you run a slice query with a clustering tuple like:

{{SELECT * FROM ks.tbl WHERE k=0 AND (c1, c2) >= (2, 3)}}

C* will return a non contiguous set of rows that would match the following 2 queries:
{{SELECT * FROM ks.tbl WHERE k=0 AND c1=2 AND c2 >=3}}
{{SELECT * FROM ks.tbl WHERE k=0 AND c1>2.}}

Whether a query like {{(c1, c2) >= (2, 3)}} makes sense for mixed ASC/DESC clustering columns is debateable, but there is a use case for paging type queries like this, so I’d propose that the tuple slice behavior be changed to simply use the direction of the first clustering column. In other words, {{(c1, c2) >= (2, 3) }}would start at the row where {{c1=2 and c2=3}} and continue iterating forwards, regardless of the direction of subsequent clustering columns.
Bug: Revisit disabling chronicle analytics
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 22/May/24 13:57
Resolved: 11/Jun/24 18:13

We first considered this in CASSANDRA-18538 but determined it wasn't a problem.  We have upgraded chronicle in CASSANDRA-18049 so we should reconfirm with packet analysis that nothing is phoning home, and perhaps consider taking further precautions by proactively disabling it.
Bug: Relax slow_query_log_timeout for MultiNodeSAITest
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 07/Jun/24 18:44
Resolved: 11/Jun/24 16:20

To stress the paging subsystem, we intentionally use a comically low fetch size in {{{}MultiNodeSAITest{}}}. This can lead to some very slow queries when we get matches into the hundreds of rows. It looks like CASSANDRA-19534 has gotten a little more aggressive about how the slow query timeout is triggered, and there’s a lot of noise around this in the logs, even in local runs. I think bumping the default slow query timeout and perhaps the native protocol timeout a bit should clear this up.
Bug: Investigate dtest timeouts after CASSANDRA-19534
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 05/Jun/24 16:29
Resolved: 11/Jun/24 14:01

We have seen increased dtest timeouts that don't appear to be environmental:

https://app.circleci.com/pipelines/github/driftx/cassandra/1651/workflows/738d1c92-0ffe-45e7-8ad4-f2646170ba76

https://ci-cassandra.apache.org/job/Cassandra-5.0/238/

I have confirmed these don't occur before CASSANDRA-19534
Bug: Audit Log entries are missing identity for mTLS connections
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 29/May/24 21:11
Resolved: 10/Jun/24 21:37

Audit log entries are missing the {{IDENTITY}} when an mTLS connection is established. Currently, the client state is captured as part of the audit log entries, however the additional metadata for the authenticated user does not get propagated to the entry. For the mTLS connections, this means that the identity information is not included to the log entry details.

Additionally, when a TLS connection is terminated during handshake (say a client is using an expired certificate) the error is not propagated to the audit log failure attempts.
Bug: Observed large number of Inbound / Outbound connection disconnect / reconnects in log
Status: Triage Needed
Priority: Normal
Created: 10/Jun/24 15:28

We are seeing hundreds of InboundConnection established / closed messages on several of our clusters running Apache Cassandra 4.0.10.  Looking at 'nodetool tpstats' it seems gossip is close to the time out value.  It affects both the LargeMessage and UrgentMessage connections.

Gossiper uses MessagingService to send messages from the source to destination using OutboundConnection.  Depending on the message type especially for LARGE_MESSAGES it is enqueued in a separate thread pool while URGENT_MESSAGES are delivered with Verb.Priority.P0.

In the example below this happens just 20 seconds after it connected. These two nodes are in the same datacenter, so there should be no geographical latency between them. This cluster 111 has a very standard cassandra.yaml for our environment.

 

127.10.20.88 cassandra.log:

2024-05-13 02:06:13,805 [INFO ] [Messaging-EventLoop-3-2] cluster_id=111 ip_address=127.10.20.88 InboundConnectionInitiator.java:529 - /127.10.30.171:7000(/127.10.30.171:37404)->/127.10.20.88:7000-URGENT_MESSAGES-e039a471 messaging connection established, version = 12, framing = CRC, encryption = encrypted(...)

2024-05-13 02:06:32,201 [INFO ] [Messaging-EventLoop-3-4] cluster_id=111 ip_address=127.10.20.88 OutboundConnection.java:1059 - /127.10.20.88:7000->/169.73.115.189:7000-LARGE_MESSAGES-70634968 channel closed by provider

 

127.10.30.171 log:

2024-05-13 02:05:00,300 [INFO ] [Messaging-EventLoop-3-2] cluster_id=111 ip_address=127.10.30.171 OutboundConnection.java:1059 - /127.10.30.171:7000->/169.102.147.87:7000-LARGE_MESSAGES-4b3ea69f channel closed by provider

io.netty.channel.unix.Errors$NativeIoException: readAddress(..) failed: Connection timed out

2024-05-13 02:05:46,892 [INFO ] [Messaging-EventLoop-3-4] cluster_id=111 ip_address=127.10.30.171 OutboundConnection.java:1059 - /127.10.30.171:7000->/127.10.20.88:7000-URGENT_MESSAGES-8fd0dbf2 channel closed by provider

io.netty.channel.unix.Errors$NativeIoException: readAddress(..) failed: Connection timed out

2024-05-13 02:06:13,804 [INFO ] [Messaging-EventLoop-3-4] cluster_id=111 ip_address=127.10.30.171 OutboundConnection.java:1153 - /127.10.30.171:7000(/127.10.30.171:37404)->/127.10.20.88:7000-URGENT_MESSAGES-155d9869 successfully connected, version = 12, framing = CRC, encryption = encrypted(...)

2024-05-13 02:06:24,281 [INFO ] [Messaging-EventLoop-3-4] cluster_id=111 ip_address=127.10.30.171 OutboundConnection.java:1153 - /127.10.30.171:7000(/127.10.30.171:50046)->/169.73.137.223:7000-LARGE_MESSAGES-04b51284 successfully connected, version = 12, framing = LZ4, encryption = encrypted(...)
Bug: Test failure: replace_address_test.py::TestReplaceAddress::test_restart_failed_replace
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 23/May/24 00:35
Resolved: 07/Jun/24 13:23

This can be seen failing in butler: https://butler.cassandra.apache.org/#/ci/upstream/workflow/Cassandra-5.0/failure/replace_address_test/TestReplaceAddress/test_restart_failed_replace

{noformat}
ccmlib.node.TimeoutError: 14 May 2024 18:19:08 [node1] after 120.13/120 seconds Missing: ['FatClient /127.0.0.4:7000 has been silent for 30000ms, removing from gossip'] not found in system.log:
{noformat}
Bug: Reload new keystores/truststores in ReloadSSL
Status: Triage Needed
Priority: Normal
Created: 07/Jun/24 09:40

During the last month, we rotated our *client_encryption_options* and *server_encryption_options* certificates using the new feature reloadssl in all our cassandra 4.0.4. Everything seemed fine, until the certificate expired and we {*}started having serious issues in several of our clusters{*}.

We needed to restart all the nodes, and there was unavailability, because when we restarted the nodes, of course, the encryption was different.

When analysing the cause, I realised that from the *ReloadSslCertificates* method in *NoteTool.java* until the end of the process in {*}SSLFactory.java{*}, the cassandra.yaml configurations *are never reloaded* to the new *Keystore* and *Truststore* files.

In our scenario, exchanging the certificate generates new keystores and truststores and as there is no documentation indicating that it needs to be the same name/file as the KS/TS, the expected behavior was for the certificate to be exchanged according to what is in the yaml.

My suggestion would be to reload the cassandra.yaml settings and load the new KS/TS before rotating the certificate and improving the documentation.
Bug: keystore / truststore on system_views.settings
Status: Triage Needed
Priority: Normal
Created: 07/Jun/24 09:46

With the problems we had when exchanging Cassandra certificates, using reloadssl, described in the ticket: https://issues.apache.org/jira/browse/CASSANDRA-19690
We suggest a new feature or improvement so that we can somehow have information about which keystore / truststore is currently in use in Cassandra:
 * server_encryption_options.truststore
 * server_encryption_options.keystore
 * client_encryption_options.truststore
 * client_encryption_options.keystore

This information together with the Virtual tables information in system_views.settings would be perfect.
Bug: Correct testing instructions on the website
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 09/May/24 14:16
Resolved: 09/May/24 15:47

At https://cassandra.apache.org/_/development/testing.html it says to issue these statements for cqlsh tests:

{noformat}
ccm updateconf "enable_user_defined_functions: true"
ccm updateconf "enable_scripted_user_defined_functions: true"
ccm updateconf "cdc_enabled: true"
{noformat}

But these actually break the configuration so it won't start.
Bug: Stream processing for StorageProxy::updateCoordinatorWriteLatencyTableMetric
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 02/Jun/24 16:25
Resolved: 06/Jun/24 10:54

On profiling a write-heavy workload (90% writes) using easy-cass-stress, it became very clear StorageProxy::updateCoordinatorWriteLatencyTableMetric was a hot path that ~15% of the CPU cycles of ModificationStatement::executeWithoutCondition were taken up by (see attached async-profiler image).

We should convert this stream to a simple for loop, as has been discussed recently on the mail list.

easy-cass-stress command:

$ bin/easy-cass-stress run KeyValue -n 10m --maxwlat 10 -r 0.1 --rate 20000 --compaction twcs