[jira] [Updated] (CASSANDRASC-133) Allow optional reason to abort restore jobs
[ https://issues.apache.org/jira/browse/CASSANDRASC-133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yifan Cai updated CASSANDRASC-133: -- Status: Ready to Commit (was: Review In Progress) > Allow optional reason to abort restore jobs > --- > > Key: CASSANDRASC-133 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-133 > Project: Sidecar for Apache Cassandra > Issue Type: Improvement > Components: Rest API >Reporter: Yifan Cai >Assignee: Yifan Cai >Priority: Normal > Labels: pull-request-available > > Allowing posting the reason to abort a restore jobs can help on reasoning the > cause of a job cancellation. The patch adds the capability for sidecar client > to provide the optional reason. The text is then persisted and logged. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRASC-133) Allow optional reason to abort restore jobs
[ https://issues.apache.org/jira/browse/CASSANDRASC-133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17849410#comment-17849410 ] Francisco Guerrero commented on CASSANDRASC-133: +1 PR and CI look good. Thanks for the improvement > Allow optional reason to abort restore jobs > --- > > Key: CASSANDRASC-133 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-133 > Project: Sidecar for Apache Cassandra > Issue Type: Improvement > Components: Rest API >Reporter: Yifan Cai >Assignee: Yifan Cai >Priority: Normal > Labels: pull-request-available > > Allowing posting the reason to abort a restore jobs can help on reasoning the > cause of a job cancellation. The patch adds the capability for sidecar client > to provide the optional reason. The text is then persisted and logged. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19451) An Option of Latency Sensitive Load Balancing Policy
[ https://issues.apache.org/jira/browse/CASSANDRA-19451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bret McGuire updated CASSANDRA-19451: - Resolution: Won't Fix Status: Resolved (was: Triage Needed) > An Option of Latency Sensitive Load Balancing Policy > > > Key: CASSANDRA-19451 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19451 > Project: Cassandra > Issue Type: Improvement > Components: Client/java-driver >Reporter: Jane He >Assignee: Jane He >Priority: High > Time Spent: 40m > Remaining Estimate: 0h > > We have received concerns from the community about the 4.x java driver > default load balancing policy's performance in terms of busy node avoidance. > In some circumstances, when some nodes are busy, the 3.x java driver's > `LatencyAwarenessLoadBalancingPolicy` almost does not send requests to the > busy nodes, while the 4.x default one will still send a lot of requests to > them. This is because the 4.x default one uses in-flight count and responses > in the past 200ms to determine a node's health instead of latency. > Therefore, we want to create another class called > `LatencySensitiveLoadBalancingPolicy` in the 4.x java driver, which will > combine the in-flight count and the latency. A user can use it by specifying > it in `application.conf`. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19451) An Option of Latency Sensitive Load Balancing Policy
[ https://issues.apache.org/jira/browse/CASSANDRA-19451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17849404#comment-17849404 ] Bret McGuire commented on CASSANDRA-19451: -- To close the loop here: we wound up releasing this as a [separate artifact|https://github.com/datastax/java-driver-policies] managed by DataStax. We saw real problems with the plethora of options users had with the 3.x Java driver; the explosion of combinations of LBPs in that driver led to confusion about what should be used in what situations. 4.x very deliberately went the other way by maintaining a single LBP (DefaultLoadBalancingPolicy) which has very reasonable behaviour in a wide range of configurations. To avoid re-introducing the confusion we saw with 3.x the aim here is to keep extraneous LBPs out of the core driver and in discrete artifacts. We can consider addressing this in the future via something like the "extras" directory maintained in the 3.x driver. The 4.x driver has an "examples" directory which serves a similar function but it's not exactly equivalent. Furthermore any such optional policy should have _very_ clear guidance around it's behaviour and in what cases a user may want to consider deploying it. > An Option of Latency Sensitive Load Balancing Policy > > > Key: CASSANDRA-19451 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19451 > Project: Cassandra > Issue Type: Improvement > Components: Client/java-driver >Reporter: Jane He >Assignee: Jane He >Priority: High > Time Spent: 40m > Remaining Estimate: 0h > > We have received concerns from the community about the 4.x java driver > default load balancing policy's performance in terms of busy node avoidance. > In some circumstances, when some nodes are busy, the 3.x java driver's > `LatencyAwarenessLoadBalancingPolicy` almost does not send requests to the > busy nodes, while the 4.x default one will still send a lot of requests to > them. This is because the 4.x default one uses in-flight count and responses > in the past 200ms to determine a node's health instead of latency. > Therefore, we want to create another class called > `LatencySensitiveLoadBalancingPolicy` in the 4.x java driver, which will > combine the in-flight count and the latency. A user can use it by specifying > it in `application.conf`. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRASC-133) Allow optional reason to abort restore jobs
[ https://issues.apache.org/jira/browse/CASSANDRASC-133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francisco Guerrero updated CASSANDRASC-133: --- Reviewers: Francisco Guerrero Status: Review In Progress (was: Patch Available) > Allow optional reason to abort restore jobs > --- > > Key: CASSANDRASC-133 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-133 > Project: Sidecar for Apache Cassandra > Issue Type: Improvement > Components: Rest API >Reporter: Yifan Cai >Assignee: Yifan Cai >Priority: Normal > Labels: pull-request-available > > Allowing posting the reason to abort a restore jobs can help on reasoning the > cause of a job cancellation. The patch adds the capability for sidecar client > to provide the optional reason. The text is then persisted and logged. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRASC-133) Allow optional reason to abort restore jobs
[ https://issues.apache.org/jira/browse/CASSANDRASC-133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yifan Cai updated CASSANDRASC-133: -- Authors: Yifan Cai Test and Documentation Plan: ci Status: Patch Available (was: Open) PR: https://github.com/apache/cassandra-sidecar/pull/124 CI: https://app.circleci.com/pipelines/github/yifan-c/cassandra-sidecar?branch=CASSANDRASC-133%2Ftrunk > Allow optional reason to abort restore jobs > --- > > Key: CASSANDRASC-133 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-133 > Project: Sidecar for Apache Cassandra > Issue Type: Improvement > Components: Rest API >Reporter: Yifan Cai >Assignee: Yifan Cai >Priority: Normal > Labels: pull-request-available > > Allowing posting the reason to abort a restore jobs can help on reasoning the > cause of a job cancellation. The patch adds the capability for sidecar client > to provide the optional reason. The text is then persisted and logged. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRASC-133) Allow optional reason to abort restore jobs
[ https://issues.apache.org/jira/browse/CASSANDRASC-133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CASSANDRASC-133: --- Labels: pull-request-available (was: ) > Allow optional reason to abort restore jobs > --- > > Key: CASSANDRASC-133 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-133 > Project: Sidecar for Apache Cassandra > Issue Type: Improvement > Components: Rest API >Reporter: Yifan Cai >Assignee: Yifan Cai >Priority: Normal > Labels: pull-request-available > > Allowing posting the reason to abort a restore jobs can help on reasoning the > cause of a job cancellation. The patch adds the capability for sidecar client > to provide the optional reason. The text is then persisted and logged. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRASC-133) Allow optional reason to abort restore jobs
Yifan Cai created CASSANDRASC-133: - Summary: Allow optional reason to abort restore jobs Key: CASSANDRASC-133 URL: https://issues.apache.org/jira/browse/CASSANDRASC-133 Project: Sidecar for Apache Cassandra Issue Type: Improvement Reporter: Yifan Cai Assignee: Yifan Cai Allowing posting the reason to abort a restore jobs can help on reasoning the cause of a job cancellation. The patch adds the capability for sidecar client to provide the optional reason. The text is then persisted and logged. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRASC-133) Allow optional reason to abort restore jobs
[ https://issues.apache.org/jira/browse/CASSANDRASC-133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yifan Cai updated CASSANDRASC-133: -- Change Category: Semantic Complexity: Normal Component/s: Rest API Status: Open (was: Triage Needed) > Allow optional reason to abort restore jobs > --- > > Key: CASSANDRASC-133 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-133 > Project: Sidecar for Apache Cassandra > Issue Type: Improvement > Components: Rest API >Reporter: Yifan Cai >Assignee: Yifan Cai >Priority: Normal > > Allowing posting the reason to abort a restore jobs can help on reasoning the > cause of a job cancellation. The patch adds the capability for sidecar client > to provide the optional reason. The text is then persisted and logged. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19663) trunk fails to start
[
https://issues.apache.org/jira/browse/CASSANDRA-19663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17849392#comment-17849392
]
Brandon Williams commented on CASSANDRA-19663:
--
Try removing the ~/.m2 directory if it has one, since that is outside of what
is cloned.
> trunk fails to start
>
>
> Key: CASSANDRA-19663
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19663
> Project: Cassandra
> Issue Type: Bug
>Reporter: Jon Haddad
>Priority: Normal
>
> On commit {{6701259bce91672a7c3ca9fb77ea7b040e9c}}, I get errors on
> startup.
> Verified the build was successful:
> {noformat}
> easy-cass-lab.amazon-ebs.ubuntu: BUILD SUCCESSFUL
> easy-cass-lab.amazon-ebs.ubuntu: Total time: 1 minute 41 seconds
> {noformat}
> Running on a new Ubuntu instance:
> {noformat}
> INFO [main] 2024-05-24 18:31:16,397 YamlConfigurationLoader.java:103 -
> Configuration location: file:/usr/local/cassandra/trunk/conf/cassandra.yaml
> ERROR [main] 2024-05-24 18:31:16,470 CassandraDaemon.java:900 - Exception
> encountered during startup
> java.lang.NoSuchMethodError: 'void
> org.yaml.snakeyaml.LoaderOptions.setCodePointLimit(int)'
> at
> org.apache.cassandra.config.YamlConfigurationLoader.getDefaultLoaderOptions(YamlConfigurationLoader.java:433)
> at
> org.apache.cassandra.config.YamlConfigurationLoader$CustomConstructor.(YamlConfigurationLoader.java:278)
> at
> org.apache.cassandra.config.YamlConfigurationLoader.loadConfig(YamlConfigurationLoader.java:135)
> at
> org.apache.cassandra.config.YamlConfigurationLoader.loadConfig(YamlConfigurationLoader.java:116)
> at
> org.apache.cassandra.config.DatabaseDescriptor.loadConfig(DatabaseDescriptor.java:403)
> at
> org.apache.cassandra.config.DatabaseDescriptor.daemonInitialization(DatabaseDescriptor.java:265)
> at
> org.apache.cassandra.config.DatabaseDescriptor.daemonInitialization(DatabaseDescriptor.java:250)
> at
> org.apache.cassandra.service.CassandraDaemon.applyConfig(CassandraDaemon.java:781)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:724)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:878)
> {noformat}
> Running on Java 17:
> {noformat}
> ubuntu@cassandra0:~$ java -version
> openjdk version "17.0.10" 2024-01-16
> OpenJDK Runtime Environment (build 17.0.10+7-Ubuntu-122.04.1)
> OpenJDK 64-Bit Server VM (build 17.0.10+7-Ubuntu-122.04.1, mixed mode,
> sharing)
> {noformat}
> Built with 11.
> The only configs I changed:
> {noformat}
> cluster_name: "system_views"
> num_tokens: 4
> seed_provider:
> class_name: "org.apache.cassandra.locator.SimpleSeedProvider"
> parameters:
> seeds: "10.0.0.225"
> hints_directory: "/mnt/cassandra/hints"
> data_file_directories:
> - "/mnt/cassandra/data"
> commitlog_directory: "/mnt/cassandra/commitlog"
> concurrent_reads: 64
> concurrent_writes: 64
> trickle_fsync: true
> endpoint_snitch: "Ec2Snitch"
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19663) trunk fails to start
[
https://issues.apache.org/jira/browse/CASSANDRA-19663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17849389#comment-17849389
]
Jon Haddad commented on CASSANDRA-19663:
I thought it might be related to the build, but this happened with a fresh repo
clone. easy-cass-lab handles building off branches with a clean repo every
time. Here's the packer output from where the AMI is built:
{noformat}
==> easy-cass-lab.amazon-ebs.ubuntu: + git clone --depth=1 --single-branch
--branch trunk https://github.com/apache/cassandra.git trunk
==> easy-cass-lab.amazon-ebs.ubuntu: Cloning into 'trunk'...
==> easy-cass-lab.amazon-ebs.ubuntu: + cd trunk
==> easy-cass-lab.amazon-ebs.ubuntu: + ant -Dno-checkstyle=true
{noformat}
You can see the 3 steps are clone, cd into the dir, then ant. These are the
same steps done for 5.0-HEAD:
{noformat}
==> easy-cass-lab.amazon-ebs.ubuntu: + git clone --depth=1 --single-branch
--branch cassandra-5.0 https://github.com/apache/cassandra.git 5.0-HEAD
==> easy-cass-lab.amazon-ebs.ubuntu: Cloning into '5.0-HEAD'...
==> easy-cass-lab.amazon-ebs.ubuntu: + cd 5.0-HEAD
==> easy-cass-lab.amazon-ebs.ubuntu: + ant -Dno-checkstyle=true
easy-cass-lab.amazon-ebs.ubuntu: Buildfile:
/home/ubuntu/cassandra/5.0-HEAD/build.xml
{noformat}
So, I'm not really sure what's different here. Is something else needed for
5.1?
FWIW, I'm able to build on my Mac.
> trunk fails to start
>
>
> Key: CASSANDRA-19663
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19663
> Project: Cassandra
> Issue Type: Bug
>Reporter: Jon Haddad
>Priority: Normal
>
> On commit {{6701259bce91672a7c3ca9fb77ea7b040e9c}}, I get errors on
> startup.
> Verified the build was successful:
> {noformat}
> easy-cass-lab.amazon-ebs.ubuntu: BUILD SUCCESSFUL
> easy-cass-lab.amazon-ebs.ubuntu: Total time: 1 minute 41 seconds
> {noformat}
> Running on a new Ubuntu instance:
> {noformat}
> INFO [main] 2024-05-24 18:31:16,397 YamlConfigurationLoader.java:103 -
> Configuration location: file:/usr/local/cassandra/trunk/conf/cassandra.yaml
> ERROR [main] 2024-05-24 18:31:16,470 CassandraDaemon.java:900 - Exception
> encountered during startup
> java.lang.NoSuchMethodError: 'void
> org.yaml.snakeyaml.LoaderOptions.setCodePointLimit(int)'
> at
> org.apache.cassandra.config.YamlConfigurationLoader.getDefaultLoaderOptions(YamlConfigurationLoader.java:433)
> at
> org.apache.cassandra.config.YamlConfigurationLoader$CustomConstructor.(YamlConfigurationLoader.java:278)
> at
> org.apache.cassandra.config.YamlConfigurationLoader.loadConfig(YamlConfigurationLoader.java:135)
> at
> org.apache.cassandra.config.YamlConfigurationLoader.loadConfig(YamlConfigurationLoader.java:116)
> at
> org.apache.cassandra.config.DatabaseDescriptor.loadConfig(DatabaseDescriptor.java:403)
> at
> org.apache.cassandra.config.DatabaseDescriptor.daemonInitialization(DatabaseDescriptor.java:265)
> at
> org.apache.cassandra.config.DatabaseDescriptor.daemonInitialization(DatabaseDescriptor.java:250)
> at
> org.apache.cassandra.service.CassandraDaemon.applyConfig(CassandraDaemon.java:781)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:724)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:878)
> {noformat}
> Running on Java 17:
> {noformat}
> ubuntu@cassandra0:~$ java -version
> openjdk version "17.0.10" 2024-01-16
> OpenJDK Runtime Environment (build 17.0.10+7-Ubuntu-122.04.1)
> OpenJDK 64-Bit Server VM (build 17.0.10+7-Ubuntu-122.04.1, mixed mode,
> sharing)
> {noformat}
> Built with 11.
> The only configs I changed:
> {noformat}
> cluster_name: "system_views"
> num_tokens: 4
> seed_provider:
> class_name: "org.apache.cassandra.locator.SimpleSeedProvider"
> parameters:
> seeds: "10.0.0.225"
> hints_directory: "/mnt/cassandra/hints"
> data_file_directories:
> - "/mnt/cassandra/data"
> commitlog_directory: "/mnt/cassandra/commitlog"
> concurrent_reads: 64
> concurrent_writes: 64
> trickle_fsync: true
> endpoint_snitch: "Ec2Snitch"
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19640) Enhance documentation on storage engine with leading summary
[ https://issues.apache.org/jira/browse/CASSANDRA-19640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brad Schoening updated CASSANDRA-19640: --- Test and Documentation Plan: n/a for documentation Status: Patch Available (was: In Progress) > Enhance documentation on storage engine with leading summary > > > Key: CASSANDRA-19640 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19640 > Project: Cassandra > Issue Type: Improvement > Components: Documentation >Reporter: Brad Schoening >Assignee: Brad Schoening >Priority: Low > > The storage engine > [documentation|https://github.com/apache/cassandra/blob/trunk/doc/modules/cassandra/pages/architecture/storage-engine.adoc] > would benefit from an abstract or summary which mentions key points that it > uses a Log-structured merge (LSM) tree design, is write-oriented, and relies > upon bloom filters (not B-trees) to optimize the read path. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19620) Refactor ColumnCondition post CASSANDRA-19341
[ https://issues.apache.org/jira/browse/CASSANDRA-19620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-19620: Reviewers: Benjamin Lerer, Ekaterina Dimitrova (was: Benjamin Lerer) > Refactor ColumnCondition post CASSANDRA-19341 > - > > Key: CASSANDRA-19620 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19620 > Project: Cassandra > Issue Type: Improvement > Components: CQL/Interpreter >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > CASSANDRA-19341 added ColumnsExpression in restrictions. > This ticket's target is to extend the kinds of ColumnsExpression and use them > in conditions, too. > Also, it should add a few other simplifications around ColumnCondition, which > were suggested by [~blerer] -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19620) Refactor ColumnCondition post CASSANDRA-19341
[ https://issues.apache.org/jira/browse/CASSANDRA-19620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-19620: Authors: Benjamin Lerer, Ekaterina Dimitrova (was: Ekaterina Dimitrova) > Refactor ColumnCondition post CASSANDRA-19341 > - > > Key: CASSANDRA-19620 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19620 > Project: Cassandra > Issue Type: Improvement > Components: CQL/Interpreter >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > CASSANDRA-19341 added ColumnsExpression in restrictions. > This ticket's target is to extend the kinds of ColumnsExpression and use them > in conditions, too. > Also, it should add a few other simplifications around ColumnCondition, which > were suggested by [~blerer] -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14572) Expose all table metrics in virtual table
[
https://issues.apache.org/jira/browse/CASSANDRA-14572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17849386#comment-17849386
]
David Capwell commented on CASSANDRA-14572:
---
For visibility there is a large conversation in slack about this feature
https://the-asf.slack.com/archives/CK23JSY2K/p1716324924466269
Here are a few of the points
*) the "group" tables expose a "name" that doesn't reflect the "name" in our
metrics, but instead an internal map used for unique metric detection
*) the term "group" maps to "type" for JMX, so causes confusion for users (the
"group" is "org.apache.cassandra.metrics", every instance of group is actually
"type")
*) implementation is O(N) where N is the number of metrics in the JVM
**) new benchmarks were created using tlp-stress and show that these tables are
2-3x slower than other vtables for a freshly started instance with no tables.
*) UX is hard for users and for automation due to it exposing a internal key
that must be parsed (mentally or by tools) rather than showing columns users
would expect
*) histogram metrics return a single double value, this may not be the best UX
for histograms
We have been talking about solutions to these problems and we should create a
ticket to track this, should make sure to link that once its ready
> Expose all table metrics in virtual table
> -
>
> Key: CASSANDRA-14572
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14572
> Project: Cassandra
> Issue Type: New Feature
> Components: Legacy/Observability, Observability/Metrics
>Reporter: Chris Lohfink
>Assignee: Maxim Muzafarov
>Priority: Low
> Labels: virtual-tables
> Fix For: 5.1
>
> Attachments: flight_recording_1270017199_13.jfr, keyspayces_group
> responses times.png, keyspayces_group summary.png, select keyspaces_group by
> string prefix.png, select keyspaces_group compare with wo.png, select
> keyspaces_group without value.png, systemv_views.metrics_dropped_message.png,
> thread_pools benchmark.png
>
> Time Spent: 8h
> Remaining Estimate: 0h
>
> While we want a number of virtual tables to display data in a way thats great
> and intuitive like in nodetool. There is also much for being able to expose
> the metrics we have for tooling via CQL instead of JMX. This is more for the
> tooling and adhoc advanced users who know exactly what they are looking for.
> *Schema:*
> Initial idea is to expose data via {{((keyspace, table), metric)}} with a
> column for each metric value. Could also use a Map or UDT instead of the
> column based that can be a bit more specific to each metric type. To that end
> there can be a {{metric_type}} column and then a UDT for each metric type
> filled in, or a single value with more of a Map style. I am
> purposing the column type though as with {{ALLOW FILTERING}} it does allow
> more extensive query capabilities.
> *Implementations:*
> * Use reflection to grab all the metrics from TableMetrics (see:
> CASSANDRA-7622 impl). This is easiest and least abrasive towards new metric
> implementors... but its reflection and a kinda a bad idea.
> * Add a hook in TableMetrics to register with this virtual table when
> registering
> * Pull from the CassandraMetrics registery (either reporter or iterate
> through metrics query on read of virtual table)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19661) Cannot restart Cassandra 5 after creating a vector table and index
[
https://issues.apache.org/jira/browse/CASSANDRA-19661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17849380#comment-17849380
]
Jonathan Ellis commented on CASSANDRA-19661:
> It looks like perhaps {{computeRowIds()}} is being called multiple times when
> it shouldn't
Agreed that it's not intended to be called multiple times.
> Is it possible for multiple keys in {{postingsMap}} to point to the same
> {{VectorPostings}} instance?
I don't think that's possible – the only mutation against `postingsMap` is done
with a freshly instantiated `VectorPostings`.
> Cannot restart Cassandra 5 after creating a vector table and index
> --
>
> Key: CASSANDRA-19661
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19661
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/SAI
>Reporter: Sergio Rua
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
>
> I'm using llama-index and llama3 to train a model. I'm using a very simple
> code that reads some *.txt files from local and uploads them to Cassandra and
> then creates the index:
>
> {code:java}
> # Create the index from documents
> index = VectorStoreIndex.from_documents(
> documents,
> service_context=vector_store.service_context,
> storage_context=storage_context,
> show_progress=True,
> ) {code}
> This works well and I'm able to use a Chat app to get responses from the
> Cassandra data. however, right after, I cannot restart Cassandra. It'll break
> with the following error:
>
> {code:java}
> INFO [PerDiskMemtableFlushWriter_0:7] 2024-05-23 08:23:20,102
> Flushing.java:179 - Completed flushing
> /data/cassandra/data/gpt/docs_20240523-10c8eaa018d811ef8dadf75182f3e2b4/da-6-bti-Data.db
> (124.236MiB) for commitlog position
> CommitLogPosition(segmentId=1716452305636, position=15336)
> [...]
> WARN [MemtableFlushWriter:1] 2024-05-23 08:28:29,575
> MemtableIndexWriter.java:92 - [gpt.docs.idx_vector_docs] Aborting index
> memtable flush for
> /data/cassandra/data/gpt/docs-aea77a80184b11ef8dadf75182f3e2b4/da-3-bti...{code}
> {code:java}
> java.lang.IllegalStateException: null
> at
> com.google.common.base.Preconditions.checkState(Preconditions.java:496)
> at
> org.apache.cassandra.index.sai.disk.v1.vector.VectorPostings.computeRowIds(VectorPostings.java:76)
> at
> org.apache.cassandra.index.sai.disk.v1.vector.OnHeapGraph.writeData(OnHeapGraph.java:313)
> at
> org.apache.cassandra.index.sai.memory.VectorMemoryIndex.writeDirect(VectorMemoryIndex.java:272)
> at
> org.apache.cassandra.index.sai.memory.MemtableIndex.writeDirect(MemtableIndex.java:110)
> at
> org.apache.cassandra.index.sai.disk.v1.MemtableIndexWriter.flushVectorIndex(MemtableIndexWriter.java:192)
> at
> org.apache.cassandra.index.sai.disk.v1.MemtableIndexWriter.complete(MemtableIndexWriter.java:117)
> at
> org.apache.cassandra.index.sai.disk.StorageAttachedIndexWriter.complete(StorageAttachedIndexWriter.java:185)
> at java.base/java.util.ArrayList.forEach(ArrayList.java:1541)
> at
> java.base/java.util.Collections$UnmodifiableCollection.forEach(Collections.java:1085)
> at
> org.apache.cassandra.io.sstable.format.SSTableWriter.commit(SSTableWriter.java:289)
> at
> org.apache.cassandra.db.compaction.unified.ShardedMultiWriter.commit(ShardedMultiWriter.java:219)
> at
> org.apache.cassandra.db.ColumnFamilyStore$Flush.flushMemtable(ColumnFamilyStore.java:1323)
> at
> org.apache.cassandra.db.ColumnFamilyStore$Flush.run(ColumnFamilyStore.java:1222)
> at
> org.apache.cassandra.concurrent.ExecutionFailure$1.run(ExecutionFailure.java:133)
> 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}
> The table created by the script is as follows:
>
> {noformat}
> CREATE TABLE gpt.docs (
> partition_id text,
> row_id text,
> attributes_blob text,
> body_blob text,
> vector vector,
> metadata_s map,
> PRIMARY KEY (partition_id, row_id)
> ) WITH CLUSTERING ORDER BY (row_id ASC)
> AND additional_write_policy = '99p'
> AND allow_auto_snapshot = true
> AND bloom_fil
[jira] [Commented] (CASSANDRA-19663) trunk fails to start
[
https://issues.apache.org/jira/browse/CASSANDRA-19663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17849378#comment-17849378
]
Brandon Williams commented on CASSANDRA-19663:
--
This looks like some kind of build problem and doesn't repro for me, maybe try
a realclean?
> trunk fails to start
>
>
> Key: CASSANDRA-19663
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19663
> Project: Cassandra
> Issue Type: Bug
>Reporter: Jon Haddad
>Priority: Normal
>
> On commit {{6701259bce91672a7c3ca9fb77ea7b040e9c}}, I get errors on
> startup.
> Verified the build was successful:
> {noformat}
> easy-cass-lab.amazon-ebs.ubuntu: BUILD SUCCESSFUL
> easy-cass-lab.amazon-ebs.ubuntu: Total time: 1 minute 41 seconds
> {noformat}
> Running on a new Ubuntu instance:
> {noformat}
> INFO [main] 2024-05-24 18:31:16,397 YamlConfigurationLoader.java:103 -
> Configuration location: file:/usr/local/cassandra/trunk/conf/cassandra.yaml
> ERROR [main] 2024-05-24 18:31:16,470 CassandraDaemon.java:900 - Exception
> encountered during startup
> java.lang.NoSuchMethodError: 'void
> org.yaml.snakeyaml.LoaderOptions.setCodePointLimit(int)'
> at
> org.apache.cassandra.config.YamlConfigurationLoader.getDefaultLoaderOptions(YamlConfigurationLoader.java:433)
> at
> org.apache.cassandra.config.YamlConfigurationLoader$CustomConstructor.(YamlConfigurationLoader.java:278)
> at
> org.apache.cassandra.config.YamlConfigurationLoader.loadConfig(YamlConfigurationLoader.java:135)
> at
> org.apache.cassandra.config.YamlConfigurationLoader.loadConfig(YamlConfigurationLoader.java:116)
> at
> org.apache.cassandra.config.DatabaseDescriptor.loadConfig(DatabaseDescriptor.java:403)
> at
> org.apache.cassandra.config.DatabaseDescriptor.daemonInitialization(DatabaseDescriptor.java:265)
> at
> org.apache.cassandra.config.DatabaseDescriptor.daemonInitialization(DatabaseDescriptor.java:250)
> at
> org.apache.cassandra.service.CassandraDaemon.applyConfig(CassandraDaemon.java:781)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:724)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:878)
> {noformat}
> Running on Java 17:
> {noformat}
> ubuntu@cassandra0:~$ java -version
> openjdk version "17.0.10" 2024-01-16
> OpenJDK Runtime Environment (build 17.0.10+7-Ubuntu-122.04.1)
> OpenJDK 64-Bit Server VM (build 17.0.10+7-Ubuntu-122.04.1, mixed mode,
> sharing)
> {noformat}
> Built with 11.
> The only configs I changed:
> {noformat}
> cluster_name: "system_views"
> num_tokens: 4
> seed_provider:
> class_name: "org.apache.cassandra.locator.SimpleSeedProvider"
> parameters:
> seeds: "10.0.0.225"
> hints_directory: "/mnt/cassandra/hints"
> data_file_directories:
> - "/mnt/cassandra/data"
> commitlog_directory: "/mnt/cassandra/commitlog"
> concurrent_reads: 64
> concurrent_writes: 64
> trickle_fsync: true
> endpoint_snitch: "Ec2Snitch"
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19241) Upgrade ci-cassandra.a.o agents to Ubuntu 22.04.3
[ https://issues.apache.org/jira/browse/CASSANDRA-19241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17849375#comment-17849375 ] Brandon Williams commented on CASSANDRA-19241: -- 41 and 42 in INFRA-25820. It looks like 43 may need to be replaced like 39 was. > Upgrade ci-cassandra.a.o agents to Ubuntu 22.04.3 > - > > Key: CASSANDRA-19241 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19241 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Michael Semb Wever >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.0.x, 5.x > > > All agents are currently Ubuntu 18.04 LTS per the > [docs|https://github.com/apache/cassandra-builds/blob/trunk/ASF-jenkins-agents.md#server-requirements]. > All agents need to be upgraded to Ubuntu 22.04.3 LTS. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-19663) trunk fails to start
Jon Haddad created CASSANDRA-19663:
--
Summary: trunk fails to start
Key: CASSANDRA-19663
URL: https://issues.apache.org/jira/browse/CASSANDRA-19663
Project: Cassandra
Issue Type: Bug
Reporter: Jon Haddad
On commit {{6701259bce91672a7c3ca9fb77ea7b040e9c}}, I get errors on startup.
Verified the build was successful:
{noformat}
easy-cass-lab.amazon-ebs.ubuntu: BUILD SUCCESSFUL
easy-cass-lab.amazon-ebs.ubuntu: Total time: 1 minute 41 seconds
{noformat}
Running on a new Ubuntu instance:
{noformat}
INFO [main] 2024-05-24 18:31:16,397 YamlConfigurationLoader.java:103 -
Configuration location: file:/usr/local/cassandra/trunk/conf/cassandra.yaml
ERROR [main] 2024-05-24 18:31:16,470 CassandraDaemon.java:900 - Exception
encountered during startup
java.lang.NoSuchMethodError: 'void
org.yaml.snakeyaml.LoaderOptions.setCodePointLimit(int)'
at
org.apache.cassandra.config.YamlConfigurationLoader.getDefaultLoaderOptions(YamlConfigurationLoader.java:433)
at
org.apache.cassandra.config.YamlConfigurationLoader$CustomConstructor.(YamlConfigurationLoader.java:278)
at
org.apache.cassandra.config.YamlConfigurationLoader.loadConfig(YamlConfigurationLoader.java:135)
at
org.apache.cassandra.config.YamlConfigurationLoader.loadConfig(YamlConfigurationLoader.java:116)
at
org.apache.cassandra.config.DatabaseDescriptor.loadConfig(DatabaseDescriptor.java:403)
at
org.apache.cassandra.config.DatabaseDescriptor.daemonInitialization(DatabaseDescriptor.java:265)
at
org.apache.cassandra.config.DatabaseDescriptor.daemonInitialization(DatabaseDescriptor.java:250)
at
org.apache.cassandra.service.CassandraDaemon.applyConfig(CassandraDaemon.java:781)
at
org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:724)
at
org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:878)
{noformat}
Running on Java 17:
{noformat}
ubuntu@cassandra0:~$ java -version
openjdk version "17.0.10" 2024-01-16
OpenJDK Runtime Environment (build 17.0.10+7-Ubuntu-122.04.1)
OpenJDK 64-Bit Server VM (build 17.0.10+7-Ubuntu-122.04.1, mixed mode, sharing)
{noformat}
Built with 11.
The only configs I changed:
{noformat}
cluster_name: "system_views"
num_tokens: 4
seed_provider:
class_name: "org.apache.cassandra.locator.SimpleSeedProvider"
parameters:
seeds: "10.0.0.225"
hints_directory: "/mnt/cassandra/hints"
data_file_directories:
- "/mnt/cassandra/data"
commitlog_directory: "/mnt/cassandra/commitlog"
concurrent_reads: 64
concurrent_writes: 64
trickle_fsync: true
endpoint_snitch: "Ec2Snitch"
{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17667) Text value containing "/*" interpreted as multiline comment in cqlsh
[
https://issues.apache.org/jira/browse/CASSANDRA-17667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17849368#comment-17849368
]
Brandon Williams commented on CASSANDRA-17667:
--
That looks good to me [~bschoeni] if you want to prepare the branches.
> Text value containing "/*" interpreted as multiline comment in cqlsh
>
>
> Key: CASSANDRA-17667
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17667
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: ANOOP THOMAS
>Assignee: Brad Schoening
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x
>
>
> I use CQLSH command line utility to load some DDLs. The version of utility I
> use is this:
> {noformat}
> [cqlsh 6.0.0 | Cassandra 4.0.0.47 | CQL spec 3.4.5 | Native protocol
> v5]{noformat}
> Command that loads DDL.cql:
> {noformat}
> cqlsh -u username -p password cassandra.example.com 65503 --ssl -f DDL.cql
> {noformat}
> I have a line in CQL script that breaks the syntax.
> {noformat}
> INSERT into tablename (key,columnname1,columnname2) VALUES
> ('keyName','value1','/value2/*/value3');{noformat}
> {{/*}} here is interpreted as start of multi-line comment. It used to work on
> older versions of cqlsh. The error I see looks like this:
> {noformat}
> SyntaxException: line 4:2 mismatched input 'Update' expecting ')'
> (...,'value1','/value2INSERT into tablename(INSERT into tablename
> (key,columnname1,columnname2)) VALUES ('[Update]-...) SyntaxException: line
> 1:0 no viable alternative at input '(' ([(]...)
> {noformat}
> Same behavior while running in interactive mode too. {{/*}} inside a CQL
> statement should not be interpreted as start of multi-line comment.
> With schema:
> {code:java}
> CREATE TABLE tablename ( key text primary key, columnname1 text, columnname2
> text);{code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17667) Text value containing "/*" interpreted as multiline comment in cqlsh
[
https://issues.apache.org/jira/browse/CASSANDRA-17667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846493#comment-17846493
]
Brad Schoening edited comment on CASSANDRA-17667 at 5/24/24 6:31 PM:
-
[~bereng] I have updated the PR with a test string for */. There already exists
{code:java}
'SELECT FROM "/*MyTable*/";'
'SELECT FROM /*
comment block starts here;
and continues here
*/ "MyTable';
' /* comment block */
/* another comment */ SELECT FROM /*
comment block starts here;
and continues here
*/ "MyTable';
' '
'SELECT FROM /* \n comment block starts here; \n and continues here \n */
"MyTable";'
{code}
I looked up pg-style quoted equivalents means, and see that was added in
CASSANDRA-7769
was (Author: bschoeni):
[~bereng] I have updated the PR with a test string for */. There already exists
{code:java}
'SELECT FROM "/*MyTable*/";'
'SELECT FROM /*
comment block starts here;
and continues here
*/ "MyTable';
' /* comment block */
/* another comment */ SELECT FROM /*
comment block starts here;
and continues here
*/ "MyTable';
' '
'SELECT FROM /* \n comment block starts here; \n and continues here \n */
"MyTable";'
{code}
I looked up pg-style quoted equivalents means, and see that was added in [link
CASSANDRA-7769|https://issues.apache.org/jira/browse/CASSANDRA-7769]
> Text value containing "/*" interpreted as multiline comment in cqlsh
>
>
> Key: CASSANDRA-17667
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17667
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: ANOOP THOMAS
>Assignee: Brad Schoening
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x
>
>
> I use CQLSH command line utility to load some DDLs. The version of utility I
> use is this:
> {noformat}
> [cqlsh 6.0.0 | Cassandra 4.0.0.47 | CQL spec 3.4.5 | Native protocol
> v5]{noformat}
> Command that loads DDL.cql:
> {noformat}
> cqlsh -u username -p password cassandra.example.com 65503 --ssl -f DDL.cql
> {noformat}
> I have a line in CQL script that breaks the syntax.
> {noformat}
> INSERT into tablename (key,columnname1,columnname2) VALUES
> ('keyName','value1','/value2/*/value3');{noformat}
> {{/*}} here is interpreted as start of multi-line comment. It used to work on
> older versions of cqlsh. The error I see looks like this:
> {noformat}
> SyntaxException: line 4:2 mismatched input 'Update' expecting ')'
> (...,'value1','/value2INSERT into tablename(INSERT into tablename
> (key,columnname1,columnname2)) VALUES ('[Update]-...) SyntaxException: line
> 1:0 no viable alternative at input '(' ([(]...)
> {noformat}
> Same behavior while running in interactive mode too. {{/*}} inside a CQL
> statement should not be interpreted as start of multi-line comment.
> With schema:
> {code:java}
> CREATE TABLE tablename ( key text primary key, columnname1 text, columnname2
> text);{code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17667) Text value containing "/*" interpreted as multiline comment in cqlsh
[
https://issues.apache.org/jira/browse/CASSANDRA-17667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846493#comment-17846493
]
Brad Schoening edited comment on CASSANDRA-17667 at 5/24/24 6:31 PM:
-
[~bereng] I have updated the PR with a test string for */. There already exists
{code:java}
'SELECT FROM "/*MyTable*/";'
'SELECT FROM /*
comment block starts here;
and continues here
*/ "MyTable';
' /* comment block */
/* another comment */ SELECT FROM /*
comment block starts here;
and continues here
*/ "MyTable';
' '
'SELECT FROM /* \n comment block starts here; \n and continues here \n */
"MyTable";'
{code}
I looked up pg-style quoted equivalents means, and see that was added in [link
CASSANDRA-7769|https://issues.apache.org/jira/browse/CASSANDRA-7769]
was (Author: bschoeni):
[~bereng] I have updated the PR with a test string for */. There already exists
{code:java}
'SELECT FROM "/*MyTable*/";'
'SELECT FROM /*
comment block starts here;
and continues here
*/ "MyTable';
' /* comment block */
/* another comment */ SELECT FROM /*
comment block starts here;
and continues here
*/ "MyTable';
' '
'SELECT FROM /* \n comment block starts here; \n and continues here \n */
"MyTable";'
{code}
I looked up pg-style quoted equivalents means, and see that was added in [link
CASSANDRA-7769|{*}https://issues.apache.org/jira/browse/CASSANDRA-7769{*}]
> Text value containing "/*" interpreted as multiline comment in cqlsh
>
>
> Key: CASSANDRA-17667
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17667
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: ANOOP THOMAS
>Assignee: Brad Schoening
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x
>
>
> I use CQLSH command line utility to load some DDLs. The version of utility I
> use is this:
> {noformat}
> [cqlsh 6.0.0 | Cassandra 4.0.0.47 | CQL spec 3.4.5 | Native protocol
> v5]{noformat}
> Command that loads DDL.cql:
> {noformat}
> cqlsh -u username -p password cassandra.example.com 65503 --ssl -f DDL.cql
> {noformat}
> I have a line in CQL script that breaks the syntax.
> {noformat}
> INSERT into tablename (key,columnname1,columnname2) VALUES
> ('keyName','value1','/value2/*/value3');{noformat}
> {{/*}} here is interpreted as start of multi-line comment. It used to work on
> older versions of cqlsh. The error I see looks like this:
> {noformat}
> SyntaxException: line 4:2 mismatched input 'Update' expecting ')'
> (...,'value1','/value2INSERT into tablename(INSERT into tablename
> (key,columnname1,columnname2)) VALUES ('[Update]-...) SyntaxException: line
> 1:0 no viable alternative at input '(' ([(]...)
> {noformat}
> Same behavior while running in interactive mode too. {{/*}} inside a CQL
> statement should not be interpreted as start of multi-line comment.
> With schema:
> {code:java}
> CREATE TABLE tablename ( key text primary key, columnname1 text, columnname2
> text);{code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17667) Text value containing "/*" interpreted as multiline comment in cqlsh
[
https://issues.apache.org/jira/browse/CASSANDRA-17667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846493#comment-17846493
]
Brad Schoening edited comment on CASSANDRA-17667 at 5/24/24 6:30 PM:
-
[~bereng] I have updated the PR with a test string for */. There already exists
{code:java}
'SELECT FROM "/*MyTable*/";'
'SELECT FROM /*
comment block starts here;
and continues here
*/ "MyTable';
' /* comment block */
/* another comment */ SELECT FROM /*
comment block starts here;
and continues here
*/ "MyTable';
' '
'SELECT FROM /* \n comment block starts here; \n and continues here \n */
"MyTable";'
{code}
I looked up pg-style quoted equivalents means, and see that was added in [link
CASSANDRA-7769|{*}https://issues.apache.org/jira/browse/CASSANDRA-7769{*}]
was (Author: bschoeni):
[~bereng] I have updated the PR with a test string for */. There already exists
{code:java}
'SELECT FROM "/*MyTable*/";'
'SELECT FROM /*
comment block starts here;
and continues here
*/ "MyTable';
' /* comment block */
/* another comment */ SELECT FROM /*
comment block starts here;
and continues here
*/ "MyTable';
' '
'SELECT FROM /* \n comment block starts here; \n and continues here \n */
"MyTable";'
{code}
Not sure what pg-style quoted equivalents means.
> Text value containing "/*" interpreted as multiline comment in cqlsh
>
>
> Key: CASSANDRA-17667
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17667
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: ANOOP THOMAS
>Assignee: Brad Schoening
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x
>
>
> I use CQLSH command line utility to load some DDLs. The version of utility I
> use is this:
> {noformat}
> [cqlsh 6.0.0 | Cassandra 4.0.0.47 | CQL spec 3.4.5 | Native protocol
> v5]{noformat}
> Command that loads DDL.cql:
> {noformat}
> cqlsh -u username -p password cassandra.example.com 65503 --ssl -f DDL.cql
> {noformat}
> I have a line in CQL script that breaks the syntax.
> {noformat}
> INSERT into tablename (key,columnname1,columnname2) VALUES
> ('keyName','value1','/value2/*/value3');{noformat}
> {{/*}} here is interpreted as start of multi-line comment. It used to work on
> older versions of cqlsh. The error I see looks like this:
> {noformat}
> SyntaxException: line 4:2 mismatched input 'Update' expecting ')'
> (...,'value1','/value2INSERT into tablename(INSERT into tablename
> (key,columnname1,columnname2)) VALUES ('[Update]-...) SyntaxException: line
> 1:0 no viable alternative at input '(' ([(]...)
> {noformat}
> Same behavior while running in interactive mode too. {{/*}} inside a CQL
> statement should not be interpreted as start of multi-line comment.
> With schema:
> {code:java}
> CREATE TABLE tablename ( key text primary key, columnname1 text, columnname2
> text);{code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19150) Align values in rows in CQLSH right for numbers, left for text
[
https://issues.apache.org/jira/browse/CASSANDRA-19150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17849363#comment-17849363
]
Brad Schoening commented on CASSANDRA-19150:
[~arkn98] any thoughts on the above?
> Align values in rows in CQLSH right for numbers, left for text
> --
>
> Key: CASSANDRA-19150
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19150
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Stefan Miklosovic
>Assignee: Arun Ganesh
>Priority: Low
> Fix For: 5.x
>
> Attachments: Screenshot 2023-12-04 at 00.38.16.png, Screenshot
> 2023-12-09 at 16.58.25.png, signature.asc, test_output.txt,
> test_output_old.txt
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> *Updated* Jan 17 2024 after dev discussion
> Change CQLSH to left-align text while continue to right-align numbers. This
> will match how Postgres shell and Excel treat alignment of text and number.
> -
> *Original*
> We need to make this
> [https://github.com/apache/cassandra/blob/trunk/pylib/cqlshlib/cqlshmain.py#L1101]
> configurable so values in columns are either all on left or on right side of
> the column (basically change col.rjust to col.ljust).
> By default, it would be like it is now but there would be configuration
> property in cqlsh for that as well as a corresponding CQLSH command
> (optional), something like
> {code:java}
> ALIGNMENT LEFT|RIGHT
> {code}
> cc [~bschoeni]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19662) Data Corruption and OOM Issues During Schema Alterations
[
https://issues.apache.org/jira/browse/CASSANDRA-19662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
BHARATH KUMAR updated CASSANDRA-19662:
--
Severity: Critical
> Data Corruption and OOM Issues During Schema Alterations
> -
>
> Key: CASSANDRA-19662
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19662
> Project: Cassandra
> Issue Type: Bug
> Components: Client/java-driver
>Reporter: BHARATH KUMAR
>Priority: Urgent
> Attachments: BufferUnderflow_plus_error
>
>
> h2. Description
>
> *Overview:* The primary issue is data corruption occurring during schema
> alterations (ADD/DROP column) on large tables(300+ columns and 6TB size ) in
> the production cluster. This is accompanied by out-of-memory (OOM) errors and
> other exceptions, specifically during batch reads. This problem has been
> replicated on multiple clusters, running Apache Cassandra version 4.0.12 and
> Datastax Java Driver Version: 4.17
> *Details:*
> *Main Issue:*
> * *Data Corruption:* When dynamically adding a column to a table, the data
> intended for the new column is shifted, causing misalignment in the data.
> * *Symptoms:* The object implementing
> {{com.datastax.oss.driver.api.core.cql.Row}} returns values shifted against
> the column names returned by {{{}row.getColumnDefinitions(){}}}. The driver
> returns a corrupted row, leading to incorrect data insertion.
> *Additional Issues:*
> *Exceptions:*
> * {{java.nio.BufferUnderflowException}} during batch reads when ALTER TABLE
> ADD/DROP column statements are issued.
> * {{java.lang.ArrayIndexOutOfBoundsException}} in some cases.
> * Buffer underflow exceptions with messages like "Invalid 32-bits integer
> value, expecting 4 bytes but got 292".
> * OOM errors mostly occur during ADD column operations, while other
> exceptions occur during DELETE column operations.
> * *Method Specific:* Errors occur specifically with
> {{{}row.getList(columnName, Float.class){}}}, returning incorrect values.
> *Reproducibility:*
> * The issue is reproducible on larger tables (300 columns, 6 TB size) but
> not on smaller tables.
> * SELECT * statements are used during reads
> * *Method Specific:* Errors occur specifically with
> {{{}row.getList(columnName, Float.class){}}}, returning incorrect values.
> However, the code registers a driver exception when calling the method
> {{{}row.getList(columnName, Float.class){}}}. We pass the exact column name
> obtained from {{{}row.getColumnDefinition{}}}, but it returns the wrong value
> for a column with this name. This suggests that the issue lies with the
> driver returning an object with incorrect properties, rather than with the
> SQL query itself.
> *Debugging Efforts:*
> * *Metadata Refresh:* Enabling metadata refresh did not resolve the issue.
> * *Schema Agreement:* {{session.getCqlSession().checkSchemaAgreement()}} did
> not detect inconsistencies during test execution.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19662) Data Corruption and OOM Issues During Schema Alterations
[
https://issues.apache.org/jira/browse/CASSANDRA-19662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
BHARATH KUMAR updated CASSANDRA-19662:
--
Attachment: BufferUnderflow_plus_error
> Data Corruption and OOM Issues During Schema Alterations
> -
>
> Key: CASSANDRA-19662
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19662
> Project: Cassandra
> Issue Type: Bug
> Components: Client/java-driver
>Reporter: BHARATH KUMAR
>Priority: Normal
> Attachments: BufferUnderflow_plus_error
>
>
> h2. Description
>
> *Overview:* The primary issue is data corruption occurring during schema
> alterations (ADD/DROP column) on large tables(300+ columns and 6TB size ) in
> the production cluster. This is accompanied by out-of-memory (OOM) errors and
> other exceptions, specifically during batch reads. This problem has been
> replicated on multiple clusters, running Apache Cassandra version 4.0.12 and
> Datastax Java Driver Version: 4.17
> *Details:*
> *Main Issue:*
> * *Data Corruption:* When dynamically adding a column to a table, the data
> intended for the new column is shifted, causing misalignment in the data.
> * *Symptoms:* The object implementing
> {{com.datastax.oss.driver.api.core.cql.Row}} returns values shifted against
> the column names returned by {{{}row.getColumnDefinitions(){}}}. The driver
> returns a corrupted row, leading to incorrect data insertion.
> *Additional Issues:*
> *Exceptions:*
> * {{java.nio.BufferUnderflowException}} during batch reads when ALTER TABLE
> ADD/DROP column statements are issued.
> * {{java.lang.ArrayIndexOutOfBoundsException}} in some cases.
> * Buffer underflow exceptions with messages like "Invalid 32-bits integer
> value, expecting 4 bytes but got 292".
> * OOM errors mostly occur during ADD column operations, while other
> exceptions occur during DELETE column operations.
> * *Method Specific:* Errors occur specifically with
> {{{}row.getList(columnName, Float.class){}}}, returning incorrect values.
> *Reproducibility:*
> * The issue is reproducible on larger tables (300 columns, 6 TB size) but
> not on smaller tables.
> * SELECT * statements are used during reads
> * *Method Specific:* Errors occur specifically with
> {{{}row.getList(columnName, Float.class){}}}, returning incorrect values.
> However, the code registers a driver exception when calling the method
> {{{}row.getList(columnName, Float.class){}}}. We pass the exact column name
> obtained from {{{}row.getColumnDefinition{}}}, but it returns the wrong value
> for a column with this name. This suggests that the issue lies with the
> driver returning an object with incorrect properties, rather than with the
> SQL query itself.
> *Debugging Efforts:*
> * *Metadata Refresh:* Enabling metadata refresh did not resolve the issue.
> * *Schema Agreement:* {{session.getCqlSession().checkSchemaAgreement()}} did
> not detect inconsistencies during test execution.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19661) Cannot restart Cassandra 5 after creating a vector table and index
[
https://issues.apache.org/jira/browse/CASSANDRA-19661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17849359#comment-17849359
]
Caleb Rackliffe commented on CASSANDRA-19661:
-
[~adelapena] [~jbellis] [~mike_tr_adamson] It looks like perhaps
{{computeRowIds()}} is being called multiple times when it shouldn't via
{{OnHeapGraph#writeData()}}? Is it possible for multiple keys in
{{postingsMap}} to point to the same {{VectorPostings}} instance?
> Cannot restart Cassandra 5 after creating a vector table and index
> --
>
> Key: CASSANDRA-19661
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19661
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/SAI
>Reporter: Sergio Rua
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
>
> I'm using llama-index and llama3 to train a model. I'm using a very simple
> code that reads some *.txt files from local and uploads them to Cassandra and
> then creates the index:
>
> {code:java}
> # Create the index from documents
> index = VectorStoreIndex.from_documents(
> documents,
> service_context=vector_store.service_context,
> storage_context=storage_context,
> show_progress=True,
> ) {code}
> This works well and I'm able to use a Chat app to get responses from the
> Cassandra data. however, right after, I cannot restart Cassandra. It'll break
> with the following error:
>
> {code:java}
> INFO [PerDiskMemtableFlushWriter_0:7] 2024-05-23 08:23:20,102
> Flushing.java:179 - Completed flushing
> /data/cassandra/data/gpt/docs_20240523-10c8eaa018d811ef8dadf75182f3e2b4/da-6-bti-Data.db
> (124.236MiB) for commitlog position
> CommitLogPosition(segmentId=1716452305636, position=15336)
> [...]
> WARN [MemtableFlushWriter:1] 2024-05-23 08:28:29,575
> MemtableIndexWriter.java:92 - [gpt.docs.idx_vector_docs] Aborting index
> memtable flush for
> /data/cassandra/data/gpt/docs-aea77a80184b11ef8dadf75182f3e2b4/da-3-bti...{code}
> {code:java}
> java.lang.IllegalStateException: null
> at
> com.google.common.base.Preconditions.checkState(Preconditions.java:496)
> at
> org.apache.cassandra.index.sai.disk.v1.vector.VectorPostings.computeRowIds(VectorPostings.java:76)
> at
> org.apache.cassandra.index.sai.disk.v1.vector.OnHeapGraph.writeData(OnHeapGraph.java:313)
> at
> org.apache.cassandra.index.sai.memory.VectorMemoryIndex.writeDirect(VectorMemoryIndex.java:272)
> at
> org.apache.cassandra.index.sai.memory.MemtableIndex.writeDirect(MemtableIndex.java:110)
> at
> org.apache.cassandra.index.sai.disk.v1.MemtableIndexWriter.flushVectorIndex(MemtableIndexWriter.java:192)
> at
> org.apache.cassandra.index.sai.disk.v1.MemtableIndexWriter.complete(MemtableIndexWriter.java:117)
> at
> org.apache.cassandra.index.sai.disk.StorageAttachedIndexWriter.complete(StorageAttachedIndexWriter.java:185)
> at java.base/java.util.ArrayList.forEach(ArrayList.java:1541)
> at
> java.base/java.util.Collections$UnmodifiableCollection.forEach(Collections.java:1085)
> at
> org.apache.cassandra.io.sstable.format.SSTableWriter.commit(SSTableWriter.java:289)
> at
> org.apache.cassandra.db.compaction.unified.ShardedMultiWriter.commit(ShardedMultiWriter.java:219)
> at
> org.apache.cassandra.db.ColumnFamilyStore$Flush.flushMemtable(ColumnFamilyStore.java:1323)
> at
> org.apache.cassandra.db.ColumnFamilyStore$Flush.run(ColumnFamilyStore.java:1222)
> at
> org.apache.cassandra.concurrent.ExecutionFailure$1.run(ExecutionFailure.java:133)
> 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}
> The table created by the script is as follows:
>
> {noformat}
> CREATE TABLE gpt.docs (
> partition_id text,
> row_id text,
> attributes_blob text,
> body_blob text,
> vector vector,
> metadata_s map,
> PRIMARY KEY (partition_id, row_id)
> ) WITH CLUSTERING ORDER BY (row_id ASC)
> AND additional_write_policy = '99p'
> AND allow_auto_snapshot = true
> AND bloom_filter_fp_chance = 0.01
> AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
> AND cdc = false
> AND
[jira] [Updated] (CASSANDRA-19662) Data Corruption and OOM Issues During Schema Alterations
[
https://issues.apache.org/jira/browse/CASSANDRA-19662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
BHARATH KUMAR updated CASSANDRA-19662:
--
Attachment: (was: BufferUnderflow_plus_error)
> Data Corruption and OOM Issues During Schema Alterations
> -
>
> Key: CASSANDRA-19662
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19662
> Project: Cassandra
> Issue Type: Bug
> Components: Client/java-driver
>Reporter: BHARATH KUMAR
>Priority: Normal
>
> h2. Description
>
> *Overview:* The primary issue is data corruption occurring during schema
> alterations (ADD/DROP column) on large tables(300+ columns and 6TB size ) in
> the production cluster. This is accompanied by out-of-memory (OOM) errors and
> other exceptions, specifically during batch reads. This problem has been
> replicated on multiple clusters, running Apache Cassandra version 4.0.12 and
> Datastax Java Driver Version: 4.17
> *Details:*
> *Main Issue:*
> * *Data Corruption:* When dynamically adding a column to a table, the data
> intended for the new column is shifted, causing misalignment in the data.
> * *Symptoms:* The object implementing
> {{com.datastax.oss.driver.api.core.cql.Row}} returns values shifted against
> the column names returned by {{{}row.getColumnDefinitions(){}}}. The driver
> returns a corrupted row, leading to incorrect data insertion.
> *Additional Issues:*
> *Exceptions:*
> * {{java.nio.BufferUnderflowException}} during batch reads when ALTER TABLE
> ADD/DROP column statements are issued.
> * {{java.lang.ArrayIndexOutOfBoundsException}} in some cases.
> * Buffer underflow exceptions with messages like "Invalid 32-bits integer
> value, expecting 4 bytes but got 292".
> * OOM errors mostly occur during ADD column operations, while other
> exceptions occur during DELETE column operations.
> * *Method Specific:* Errors occur specifically with
> {{{}row.getList(columnName, Float.class){}}}, returning incorrect values.
> *Reproducibility:*
> * The issue is reproducible on larger tables (300 columns, 6 TB size) but
> not on smaller tables.
> * SELECT * statements are used during reads
> * *Method Specific:* Errors occur specifically with
> {{{}row.getList(columnName, Float.class){}}}, returning incorrect values.
> However, the code registers a driver exception when calling the method
> {{{}row.getList(columnName, Float.class){}}}. We pass the exact column name
> obtained from {{{}row.getColumnDefinition{}}}, but it returns the wrong value
> for a column with this name. This suggests that the issue lies with the
> driver returning an object with incorrect properties, rather than with the
> SQL query itself.
> *Debugging Efforts:*
> * *Metadata Refresh:* Enabling metadata refresh did not resolve the issue.
> * *Schema Agreement:* {{session.getCqlSession().checkSchemaAgreement()}} did
> not detect inconsistencies during test execution.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19662) Data Corruption and OOM Issues During Schema Alterations
[
https://issues.apache.org/jira/browse/CASSANDRA-19662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
BHARATH KUMAR updated CASSANDRA-19662:
--
Description:
h2. Description
*Overview:* The primary issue is data corruption occurring during schema
alterations (ADD/DROP column) on large tables(300+ columns and 6TB size ) in
the production cluster. This is accompanied by out-of-memory (OOM) errors and
other exceptions, specifically during batch reads. This problem has been
replicated on multiple clusters, running Apache Cassandra version 4.0.12 and
Datastax Java Driver Version: 4.17
*Details:*
*Main Issue:*
* *Data Corruption:* When dynamically adding a column to a table, the data
intended for the new column is shifted, causing misalignment in the data.
* *Symptoms:* The object implementing
{{com.datastax.oss.driver.api.core.cql.Row}} returns values shifted against the
column names returned by {{{}row.getColumnDefinitions(){}}}. The driver returns
a corrupted row, leading to incorrect data insertion.
*Additional Issues:*
*Exceptions:*
* {{java.nio.BufferUnderflowException}} during batch reads when ALTER TABLE
ADD/DROP column statements are issued.
* {{java.lang.ArrayIndexOutOfBoundsException}} in some cases.
* Buffer underflow exceptions with messages like "Invalid 32-bits integer
value, expecting 4 bytes but got 292".
* OOM errors mostly occur during ADD column operations, while other exceptions
occur during DELETE column operations.
* *Method Specific:* Errors occur specifically with
{{{}row.getList(columnName, Float.class){}}}, returning incorrect values.
*Reproducibility:*
* The issue is reproducible on larger tables (300 columns, 6 TB size) but not
on smaller tables.
* SELECT * statements are used during reads
* *Method Specific:* Errors occur specifically with
{{{}row.getList(columnName, Float.class){}}}, returning incorrect values.
However, the code registers a driver exception when calling the method
{{{}row.getList(columnName, Float.class){}}}. We pass the exact column name
obtained from {{{}row.getColumnDefinition{}}}, but it returns the wrong value
for a column with this name. This suggests that the issue lies with the driver
returning an object with incorrect properties, rather than with the SQL query
itself.
*Debugging Efforts:*
* *Metadata Refresh:* Enabling metadata refresh did not resolve the issue.
* *Schema Agreement:* {{session.getCqlSession().checkSchemaAgreement()}} did
not detect inconsistencies during test execution.
was:
h2. Description
*Overview:* The primary issue is data corruption occurring during schema
alterations (ADD/DROP column) on large tables(300+ columns and 6TB size ) in
the production cluster. This is accompanied by out-of-memory (OOM) errors and
other exceptions, specifically during batch reads. This problem has been
replicated on multiple clusters, running Apache Cassandra version 4.0.12.
*Details:*
*Main Issue:*
*
** *Data Corruption:* When dynamically adding a column to a table, the data
intended for the new column is shifted, causing misalignment in the data.
*
** *Symptoms:* The object implementing
{{com.datastax.oss.driver.api.core.cql.Row}} returns values shifted against the
column names returned by {{{}row.getColumnDefinitions(){}}}. The driver returns
a corrupted row, leading to incorrect data insertion.
*Additional Issues:*
*
** *Exceptions:*
*
**
*** {{java.nio.BufferUnderflowException}} during batch reads when ALTER TABLE
ADD/DROP column statements are issued.
*
**
*** {{java.lang.ArrayIndexOutOfBoundsException}} in some cases.
*
**
*** Buffer underflow exceptions with messages like "Invalid 32-bits integer
value, expecting 4 bytes but got 292".
*
**
*** OOM errors mostly occur during ADD column operations, while other
exceptions occur during DELETE column operations.
*
** *Method Specific:* Errors occur specifically with
{{{}row.getList(columnName, Float.class){}}}, returning incorrect values.
*Reproducibility:*
*
** The issue is reproducible on larger tables (300 columns, 6 TB size) but not
on smaller tables.
*
** SELECT * statements are used during reads
*
** *Method Specific:* Errors occur specifically with
{{{}row.getList(columnName, Float.class){}}}, returning incorrect values.
However, the code registers a driver exception when calling the method
{{{}row.getList(columnName, Float.class){}}}. We pass the exact column name
obtained from {{{}row.getColumnDefinition{}}}, but it returns the wrong value
for a column with this name. This suggests that the issue lies with the driver
returning an object with incorrect properties, rather than with the SQL query
itself.
*Debugging Efforts:*
*
** *Metadata Refresh:* Enabling metadata refresh did not resolve the issue.
** *Schema Agreement:* {{session.getCqlSession().checkSchemaAgreement
[jira] [Updated] (CASSANDRA-19662) Data Corruption and OOM Issues During Schema Alterations
[
https://issues.apache.org/jira/browse/CASSANDRA-19662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
BHARATH KUMAR updated CASSANDRA-19662:
--
Attachment: BufferUnderflow_plus_error
> Data Corruption and OOM Issues During Schema Alterations
> -
>
> Key: CASSANDRA-19662
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19662
> Project: Cassandra
> Issue Type: Bug
> Components: Client/java-driver
>Reporter: BHARATH KUMAR
>Priority: Normal
> Attachments: BufferUnderflow_plus_error
>
>
> h2. Description
>
> *Overview:* The primary issue is data corruption occurring during schema
> alterations (ADD/DROP column) on large tables(300+ columns and 6TB size ) in
> the production cluster. This is accompanied by out-of-memory (OOM) errors and
> other exceptions, specifically during batch reads. This problem has been
> replicated on multiple clusters, running Apache Cassandra version 4.0.12 and
> Datastax Java Driver Version: 4.17
> *Details:*
> *Main Issue:*
> * *Data Corruption:* When dynamically adding a column to a table, the data
> intended for the new column is shifted, causing misalignment in the data.
> * *Symptoms:* The object implementing
> {{com.datastax.oss.driver.api.core.cql.Row}} returns values shifted against
> the column names returned by {{{}row.getColumnDefinitions(){}}}. The driver
> returns a corrupted row, leading to incorrect data insertion.
> *Additional Issues:*
> *Exceptions:*
> * {{java.nio.BufferUnderflowException}} during batch reads when ALTER TABLE
> ADD/DROP column statements are issued.
> * {{java.lang.ArrayIndexOutOfBoundsException}} in some cases.
> * Buffer underflow exceptions with messages like "Invalid 32-bits integer
> value, expecting 4 bytes but got 292".
> * OOM errors mostly occur during ADD column operations, while other
> exceptions occur during DELETE column operations.
> * *Method Specific:* Errors occur specifically with
> {{{}row.getList(columnName, Float.class){}}}, returning incorrect values.
> *Reproducibility:*
> * The issue is reproducible on larger tables (300 columns, 6 TB size) but
> not on smaller tables.
> * SELECT * statements are used during reads
> * *Method Specific:* Errors occur specifically with
> {{{}row.getList(columnName, Float.class){}}}, returning incorrect values.
> However, the code registers a driver exception when calling the method
> {{{}row.getList(columnName, Float.class){}}}. We pass the exact column name
> obtained from {{{}row.getColumnDefinition{}}}, but it returns the wrong value
> for a column with this name. This suggests that the issue lies with the
> driver returning an object with incorrect properties, rather than with the
> SQL query itself.
> *Debugging Efforts:*
> * *Metadata Refresh:* Enabling metadata refresh did not resolve the issue.
> * *Schema Agreement:* {{session.getCqlSession().checkSchemaAgreement()}} did
> not detect inconsistencies during test execution.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19662) Data Corruption and OOM Issues During Schema Alterations
[
https://issues.apache.org/jira/browse/CASSANDRA-19662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
BHARATH KUMAR updated CASSANDRA-19662:
--
Platform: (was: All)
> Data Corruption and OOM Issues During Schema Alterations
> -
>
> Key: CASSANDRA-19662
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19662
> Project: Cassandra
> Issue Type: Bug
> Components: Client/java-driver
>Reporter: BHARATH KUMAR
>Priority: Normal
>
> h2. Description
>
> *Overview:* The primary issue is data corruption occurring during schema
> alterations (ADD/DROP column) on large tables(300+ columns and 6TB size ) in
> the production cluster. This is accompanied by out-of-memory (OOM) errors and
> other exceptions, specifically during batch reads. This problem has been
> replicated on multiple clusters, running Apache Cassandra version 4.0.12.
> *Details:*
> *Main Issue:*
> *
> ** *Data Corruption:* When dynamically adding a column to a table, the data
> intended for the new column is shifted, causing misalignment in the data.
> *
> ** *Symptoms:* The object implementing
> {{com.datastax.oss.driver.api.core.cql.Row}} returns values shifted against
> the column names returned by {{{}row.getColumnDefinitions(){}}}. The driver
> returns a corrupted row, leading to incorrect data insertion.
> *Additional Issues:*
> *
> ** *Exceptions:*
> *
> **
> *** {{java.nio.BufferUnderflowException}} during batch reads when ALTER
> TABLE ADD/DROP column statements are issued.
> *
> **
> *** {{java.lang.ArrayIndexOutOfBoundsException}} in some cases.
> *
> **
> *** Buffer underflow exceptions with messages like "Invalid 32-bits integer
> value, expecting 4 bytes but got 292".
> *
> **
> *** OOM errors mostly occur during ADD column operations, while other
> exceptions occur during DELETE column operations.
> *
> ** *Method Specific:* Errors occur specifically with
> {{{}row.getList(columnName, Float.class){}}}, returning incorrect values.
> *Reproducibility:*
> *
> ** The issue is reproducible on larger tables (300 columns, 6 TB size) but
> not on smaller tables.
> *
> ** SELECT * statements are used during reads
> *
> ** *Method Specific:* Errors occur specifically with
> {{{}row.getList(columnName, Float.class){}}}, returning incorrect values.
> However, the code registers a driver exception when calling the method
> {{{}row.getList(columnName, Float.class){}}}. We pass the exact column name
> obtained from {{{}row.getColumnDefinition{}}}, but it returns the wrong value
> for a column with this name. This suggests that the issue lies with the
> driver returning an object with incorrect properties, rather than with the
> SQL query itself.
> *Debugging Efforts:*
> *
> ** *Metadata Refresh:* Enabling metadata refresh did not resolve the issue.
> ** *Schema Agreement:* {{session.getCqlSession().checkSchemaAgreement()}}
> did not detect inconsistencies during test execution.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-19662) Data Corruption and OOM Issues During Schema Alterations
BHARATH KUMAR created CASSANDRA-19662:
-
Summary: Data Corruption and OOM Issues During Schema Alterations
Key: CASSANDRA-19662
URL: https://issues.apache.org/jira/browse/CASSANDRA-19662
Project: Cassandra
Issue Type: Bug
Reporter: BHARATH KUMAR
h2. Description
*Overview:* The primary issue is data corruption occurring during schema
alterations (ADD/DROP column) on large tables(300+ columns and 6TB size ) in
the production cluster. This is accompanied by out-of-memory (OOM) errors and
other exceptions, specifically during batch reads. This problem has been
replicated on multiple clusters, running Apache Cassandra version 4.0.12.
*Details:*
*Main Issue:*
*
** *Data Corruption:* When dynamically adding a column to a table, the data
intended for the new column is shifted, causing misalignment in the data.
*
** *Symptoms:* The object implementing
{{com.datastax.oss.driver.api.core.cql.Row}} returns values shifted against the
column names returned by {{{}row.getColumnDefinitions(){}}}. The driver returns
a corrupted row, leading to incorrect data insertion.
*Additional Issues:*
*
** *Exceptions:*
*
**
*** {{java.nio.BufferUnderflowException}} during batch reads when ALTER TABLE
ADD/DROP column statements are issued.
*
**
*** {{java.lang.ArrayIndexOutOfBoundsException}} in some cases.
*
**
*** Buffer underflow exceptions with messages like "Invalid 32-bits integer
value, expecting 4 bytes but got 292".
*
**
*** OOM errors mostly occur during ADD column operations, while other
exceptions occur during DELETE column operations.
*
** *Method Specific:* Errors occur specifically with
{{{}row.getList(columnName, Float.class){}}}, returning incorrect values.
*Reproducibility:*
*
** The issue is reproducible on larger tables (300 columns, 6 TB size) but not
on smaller tables.
*
** SELECT * statements are used during reads
*
** *Method Specific:* Errors occur specifically with
{{{}row.getList(columnName, Float.class){}}}, returning incorrect values.
However, the code registers a driver exception when calling the method
{{{}row.getList(columnName, Float.class){}}}. We pass the exact column name
obtained from {{{}row.getColumnDefinition{}}}, but it returns the wrong value
for a column with this name. This suggests that the issue lies with the driver
returning an object with incorrect properties, rather than with the SQL query
itself.
*Debugging Efforts:*
*
** *Metadata Refresh:* Enabling metadata refresh did not resolve the issue.
** *Schema Agreement:* {{session.getCqlSession().checkSchemaAgreement()}} did
not detect inconsistencies during test execution.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19662) Data Corruption and OOM Issues During Schema Alterations
[
https://issues.apache.org/jira/browse/CASSANDRA-19662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
BHARATH KUMAR updated CASSANDRA-19662:
--
Component/s: Client/java-driver
> Data Corruption and OOM Issues During Schema Alterations
> -
>
> Key: CASSANDRA-19662
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19662
> Project: Cassandra
> Issue Type: Bug
> Components: Client/java-driver
>Reporter: BHARATH KUMAR
>Priority: Normal
>
> h2. Description
>
> *Overview:* The primary issue is data corruption occurring during schema
> alterations (ADD/DROP column) on large tables(300+ columns and 6TB size ) in
> the production cluster. This is accompanied by out-of-memory (OOM) errors and
> other exceptions, specifically during batch reads. This problem has been
> replicated on multiple clusters, running Apache Cassandra version 4.0.12.
> *Details:*
> *Main Issue:*
> *
> ** *Data Corruption:* When dynamically adding a column to a table, the data
> intended for the new column is shifted, causing misalignment in the data.
> *
> ** *Symptoms:* The object implementing
> {{com.datastax.oss.driver.api.core.cql.Row}} returns values shifted against
> the column names returned by {{{}row.getColumnDefinitions(){}}}. The driver
> returns a corrupted row, leading to incorrect data insertion.
> *Additional Issues:*
> *
> ** *Exceptions:*
> *
> **
> *** {{java.nio.BufferUnderflowException}} during batch reads when ALTER
> TABLE ADD/DROP column statements are issued.
> *
> **
> *** {{java.lang.ArrayIndexOutOfBoundsException}} in some cases.
> *
> **
> *** Buffer underflow exceptions with messages like "Invalid 32-bits integer
> value, expecting 4 bytes but got 292".
> *
> **
> *** OOM errors mostly occur during ADD column operations, while other
> exceptions occur during DELETE column operations.
> *
> ** *Method Specific:* Errors occur specifically with
> {{{}row.getList(columnName, Float.class){}}}, returning incorrect values.
> *Reproducibility:*
> *
> ** The issue is reproducible on larger tables (300 columns, 6 TB size) but
> not on smaller tables.
> *
> ** SELECT * statements are used during reads
> *
> ** *Method Specific:* Errors occur specifically with
> {{{}row.getList(columnName, Float.class){}}}, returning incorrect values.
> However, the code registers a driver exception when calling the method
> {{{}row.getList(columnName, Float.class){}}}. We pass the exact column name
> obtained from {{{}row.getColumnDefinition{}}}, but it returns the wrong value
> for a column with this name. This suggests that the issue lies with the
> driver returning an object with incorrect properties, rather than with the
> SQL query itself.
> *Debugging Efforts:*
> *
> ** *Metadata Refresh:* Enabling metadata refresh did not resolve the issue.
> ** *Schema Agreement:* {{session.getCqlSession().checkSchemaAgreement()}}
> did not detect inconsistencies during test execution.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19661) Cannot restart Cassandra 5 after creating a vector table and index
[
https://issues.apache.org/jira/browse/CASSANDRA-19661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-19661:
-
Bug Category: Parent values: Availability(12983)Level 1 values:
Unavailable(12994)
Complexity: Normal
Component/s: Feature/SAI
Discovered By: User Report
Fix Version/s: 5.0-rc
5.x
Severity: Normal
Status: Open (was: Triage Needed)
The schema alone is not enough to reproduce, but it looks like this should
block 5.0-rc.
> Cannot restart Cassandra 5 after creating a vector table and index
> --
>
> Key: CASSANDRA-19661
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19661
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/SAI
>Reporter: Sergio Rua
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
>
> I'm using llama-index and llama3 to train a model. I'm using a very simple
> code that reads some *.txt files from local and uploads them to Cassandra and
> then creates the index:
>
> {code:java}
> # Create the index from documents
> index = VectorStoreIndex.from_documents(
> documents,
> service_context=vector_store.service_context,
> storage_context=storage_context,
> show_progress=True,
> ) {code}
> This works well and I'm able to use a Chat app to get responses from the
> Cassandra data. however, right after, I cannot restart Cassandra. It'll break
> with the following error:
>
> {code:java}
> INFO [PerDiskMemtableFlushWriter_0:7] 2024-05-23 08:23:20,102
> Flushing.java:179 - Completed flushing
> /data/cassandra/data/gpt/docs_20240523-10c8eaa018d811ef8dadf75182f3e2b4/da-6-bti-Data.db
> (124.236MiB) for commitlog position
> CommitLogPosition(segmentId=1716452305636, position=15336)
> [...]
> WARN [MemtableFlushWriter:1] 2024-05-23 08:28:29,575
> MemtableIndexWriter.java:92 - [gpt.docs.idx_vector_docs] Aborting index
> memtable flush for
> /data/cassandra/data/gpt/docs-aea77a80184b11ef8dadf75182f3e2b4/da-3-bti...{code}
> {code:java}
> java.lang.IllegalStateException: null
> at
> com.google.common.base.Preconditions.checkState(Preconditions.java:496)
> at
> org.apache.cassandra.index.sai.disk.v1.vector.VectorPostings.computeRowIds(VectorPostings.java:76)
> at
> org.apache.cassandra.index.sai.disk.v1.vector.OnHeapGraph.writeData(OnHeapGraph.java:313)
> at
> org.apache.cassandra.index.sai.memory.VectorMemoryIndex.writeDirect(VectorMemoryIndex.java:272)
> at
> org.apache.cassandra.index.sai.memory.MemtableIndex.writeDirect(MemtableIndex.java:110)
> at
> org.apache.cassandra.index.sai.disk.v1.MemtableIndexWriter.flushVectorIndex(MemtableIndexWriter.java:192)
> at
> org.apache.cassandra.index.sai.disk.v1.MemtableIndexWriter.complete(MemtableIndexWriter.java:117)
> at
> org.apache.cassandra.index.sai.disk.StorageAttachedIndexWriter.complete(StorageAttachedIndexWriter.java:185)
> at java.base/java.util.ArrayList.forEach(ArrayList.java:1541)
> at
> java.base/java.util.Collections$UnmodifiableCollection.forEach(Collections.java:1085)
> at
> org.apache.cassandra.io.sstable.format.SSTableWriter.commit(SSTableWriter.java:289)
> at
> org.apache.cassandra.db.compaction.unified.ShardedMultiWriter.commit(ShardedMultiWriter.java:219)
> at
> org.apache.cassandra.db.ColumnFamilyStore$Flush.flushMemtable(ColumnFamilyStore.java:1323)
> at
> org.apache.cassandra.db.ColumnFamilyStore$Flush.run(ColumnFamilyStore.java:1222)
> at
> org.apache.cassandra.concurrent.ExecutionFailure$1.run(ExecutionFailure.java:133)
> 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}
> The table created by the script is as follows:
>
> {noformat}
> CREATE TABLE gpt.docs (
> partition_id text,
> row_id text,
> attributes_blob text,
> body_blob text,
> vector vector,
> metadata_s map,
> PRIMARY KEY (partition_id, row_id)
> ) WITH CLUSTERING ORDER BY (row_id ASC)
> AND additional_write_policy = '99p'
> AND allow_auto_snapshot = true
> AND bloom_filter_fp_chance = 0.01
> AND ca
[jira] [Created] (CASSANDRA-19661) Cannot restart Cassandra 5 after creating a vector table and index
Sergio Rua created CASSANDRA-19661:
--
Summary: Cannot restart Cassandra 5 after creating a vector table
and index
Key: CASSANDRA-19661
URL: https://issues.apache.org/jira/browse/CASSANDRA-19661
Project: Cassandra
Issue Type: Bug
Reporter: Sergio Rua
I'm using llama-index and llama3 to train a model. I'm using a very simple code
that reads some *.txt files from local and uploads them to Cassandra and then
creates the index:
{code:java}
# Create the index from documents
index = VectorStoreIndex.from_documents(
documents,
service_context=vector_store.service_context,
storage_context=storage_context,
show_progress=True,
) {code}
This works well and I'm able to use a Chat app to get responses from the
Cassandra data. however, right after, I cannot restart Cassandra. It'll break
with the following error:
{code:java}
INFO [PerDiskMemtableFlushWriter_0:7] 2024-05-23 08:23:20,102
Flushing.java:179 - Completed flushing
/data/cassandra/data/gpt/docs_20240523-10c8eaa018d811ef8dadf75182f3e2b4/da-6-bti-Data.db
(124.236MiB) for commitlog position CommitLogPosition(segmentId=1716452305636,
position=15336)
[...]
WARN [MemtableFlushWriter:1] 2024-05-23 08:28:29,575
MemtableIndexWriter.java:92 - [gpt.docs.idx_vector_docs] Aborting index
memtable flush for
/data/cassandra/data/gpt/docs-aea77a80184b11ef8dadf75182f3e2b4/da-3-bti...{code}
{code:java}
java.lang.IllegalStateException: null
at
com.google.common.base.Preconditions.checkState(Preconditions.java:496)
at
org.apache.cassandra.index.sai.disk.v1.vector.VectorPostings.computeRowIds(VectorPostings.java:76)
at
org.apache.cassandra.index.sai.disk.v1.vector.OnHeapGraph.writeData(OnHeapGraph.java:313)
at
org.apache.cassandra.index.sai.memory.VectorMemoryIndex.writeDirect(VectorMemoryIndex.java:272)
at
org.apache.cassandra.index.sai.memory.MemtableIndex.writeDirect(MemtableIndex.java:110)
at
org.apache.cassandra.index.sai.disk.v1.MemtableIndexWriter.flushVectorIndex(MemtableIndexWriter.java:192)
at
org.apache.cassandra.index.sai.disk.v1.MemtableIndexWriter.complete(MemtableIndexWriter.java:117)
at
org.apache.cassandra.index.sai.disk.StorageAttachedIndexWriter.complete(StorageAttachedIndexWriter.java:185)
at java.base/java.util.ArrayList.forEach(ArrayList.java:1541)
at
java.base/java.util.Collections$UnmodifiableCollection.forEach(Collections.java:1085)
at
org.apache.cassandra.io.sstable.format.SSTableWriter.commit(SSTableWriter.java:289)
at
org.apache.cassandra.db.compaction.unified.ShardedMultiWriter.commit(ShardedMultiWriter.java:219)
at
org.apache.cassandra.db.ColumnFamilyStore$Flush.flushMemtable(ColumnFamilyStore.java:1323)
at
org.apache.cassandra.db.ColumnFamilyStore$Flush.run(ColumnFamilyStore.java:1222)
at
org.apache.cassandra.concurrent.ExecutionFailure$1.run(ExecutionFailure.java:133)
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}
The table created by the script is as follows:
{noformat}
CREATE TABLE gpt.docs (
partition_id text,
row_id text,
attributes_blob text,
body_blob text,
vector vector,
metadata_s map,
PRIMARY KEY (partition_id, row_id)
) WITH CLUSTERING ORDER BY (row_id ASC)
AND additional_write_policy = '99p'
AND allow_auto_snapshot = true
AND bloom_filter_fp_chance = 0.01
AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
AND cdc = false
AND comment = ''
AND compaction = {'class':
'org.apache.cassandra.db.compaction.UnifiedCompactionStrategy',
'scaling_parameters': 'T4', 'target_sstable_size': '1GiB'}
AND compression = {'chunk_length_in_kb': '16', 'class':
'org.apache.cassandra.io.compress.LZ4Compressor'}
AND memtable = 'default'
AND crc_check_chance = 1.0
AND default_time_to_live = 0
AND extensions = {}
AND gc_grace_seconds = 864000
AND incremental_backups = true
AND max_index_interval = 2048
AND memtable_flush_period_in_ms = 0
AND min_index_interval = 128
AND read_repair = 'BLOCKING'
AND speculative_retry = '99p';
CREATE CUSTOM INDEX eidx_metadata_s_docs ON gpt.docs (entries(metadata_s))
USING 'org.apache.cassandra.index.sai.StorageAttachedIndex';
CREATE CUSTOM INDEX idx_vector_docs ON gpt.docs (vector) USING
'org.apache.cassandra.index.sai.StorageAttachedIndex';{noformat}
Thank you
--
This message was sent by Atlassian Jira
(v8.20.10#820010
[jira] [Updated] (CASSANDRA-19620) Refactor ColumnCondition post CASSANDRA-19341
[ https://issues.apache.org/jira/browse/CASSANDRA-19620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-19620: --- Reviewers: Benjamin Lerer > Refactor ColumnCondition post CASSANDRA-19341 > - > > Key: CASSANDRA-19620 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19620 > Project: Cassandra > Issue Type: Improvement > Components: CQL/Interpreter >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > CASSANDRA-19341 added ColumnsExpression in restrictions. > This ticket's target is to extend the kinds of ColumnsExpression and use them > in conditions, too. > Also, it should add a few other simplifications around ColumnCondition, which > were suggested by [~blerer] -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19620) Refactor ColumnCondition post CASSANDRA-19341
[ https://issues.apache.org/jira/browse/CASSANDRA-19620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-19620: --- Test and Documentation Plan: The patch add new tests and rely on the original ones. Status: Patch Available (was: In Progress) > Refactor ColumnCondition post CASSANDRA-19341 > - > > Key: CASSANDRA-19620 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19620 > Project: Cassandra > Issue Type: Improvement > Components: CQL/Interpreter >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > CASSANDRA-19341 added ColumnsExpression in restrictions. > This ticket's target is to extend the kinds of ColumnsExpression and use them > in conditions, too. > Also, it should add a few other simplifications around ColumnCondition, which > were suggested by [~blerer] -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19632) wrap tracing logs in isTraceEnabled across the codebase
[ https://issues.apache.org/jira/browse/CASSANDRA-19632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17849305#comment-17849305 ] Brandon Williams commented on CASSANDRA-19632: -- The auth failure looks like CASSANDRA-19217 and durable writes is CASSANDRA-19601. +1 > wrap tracing logs in isTraceEnabled across the codebase > --- > > Key: CASSANDRA-19632 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19632 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Core >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 5.x > > Time Spent: 40m > Remaining Estimate: 0h > > Our usage of logger.isTraceEnabled across the codebase is inconsistent. This > would also fix issues similar in e.g. CASSANDRA-19429 as [~rustyrazorblade] > suggested. > We should fix this at least in trunk and 5.0 (not critical though) and > probably come up with a checkstyle rule to prevent not calling isTraceEnabled > while logging with TRACE level. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19217) Test failure: auth_test.TestAuthUnavailable
[ https://issues.apache.org/jira/browse/CASSANDRA-19217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-19217: - Bug Category: Parent values: Correctness(12982)Level 1 values: Test Failure(12990) Complexity: Normal Discovered By: User Report Severity: Normal Status: Open (was: Triage Needed) > Test failure: auth_test.TestAuthUnavailable > --- > > Key: CASSANDRA-19217 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19217 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest/java >Reporter: Jacek Lewandowski >Priority: Normal > Fix For: 5.x > > > https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/1233/workflows/bb617340-f1da-4550-9c87-5541469972c4/jobs/62551/tests -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19217) Test failure: auth_test.TestAuthUnavailable
[ https://issues.apache.org/jira/browse/CASSANDRA-19217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17849304#comment-17849304 ] Brandon Williams commented on CASSANDRA-19217: -- Also here: https://app.circleci.com/pipelines/github/instaclustr/cassandra/4344/workflows/f9410f3a-9af4-4924-a2c8-44fc3d7384c0/jobs/237001/tests > Test failure: auth_test.TestAuthUnavailable > --- > > Key: CASSANDRA-19217 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19217 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest/java >Reporter: Jacek Lewandowski >Priority: Normal > Fix For: 5.x > > > https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/1233/workflows/bb617340-f1da-4550-9c87-5541469972c4/jobs/62551/tests -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16383) Python dtests to use ccm tag instead of the `cassandra-test` branch
[
https://issues.apache.org/jira/browse/CASSANDRA-16383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-16383:
---
Description:
The python dtests (cassandra-dtest repo) creates its clusters using ccm.
The version of ccm it uses is the HEAD of the {{cassandra-test}} branch. This
is referenced in the
[requirements.txt|https://github.com/apache/cassandra-dtest/blob/trunk/requirements.txt#L3].
The history for why a separate branch of ccm is used by dtests is explained in
https://github.com/apache/cassandra-dtest/pull/13
Long story short: the separate branch avoids two headaches
- the 'latest commit to master' broke all the c* builds surprises', and
- the 'i have to cut a release of ccm just to get a ccm change into use by
dtests'
But the two branches: {{master}} and {{cassandra-test}}; have effectively been
treated as two separate repositories, with (non-fast-forward) merges happening
in both directions. This makes the git history of both branches messy and
difficult to use, and it makes the merge strategy confusing. Bi-directional
merging between branches is considered a poor practice by many (Laura Wingerd's
'The Flow of Change'
[presentation|https://www.perforce.com/sites/default/files/flow-change-wingerd.pdf]
and
[book|https://books.google.no/books?id=mlm61wb2v3MC=PT191=PT191=%22don%27t+drive+through+hedges%22=bl=I_rYBRJwTD=ACfU3U1iKLORDQii5uiTveaKPOpa3cFqng=en=X=2ahUKEwju96-DpZnuAhWytYsKHeW6D5EQ6AEwAHoECAEQAg#v=onepage=%22don't%20drive%20through%20hedges%22=false]
refers to this as "don't drive through hedges" and encourages the "merge down,
copy up" approach against the "tofu scale: firm above, soft below").
To date, AFAIK no merges between the branches have occurred since January 2018.
A possible improvement to this process is to replace the {{cassandra-test}}
branch with a floating tag (of the same name).
That way new commits to {{master}} are not automatically used by the python
dtests. And changes made to ccm and intended/needed to be used by the dtests
can be put in use by re-tagging {{cassandra-test}} to master's HEAD.
The re-tagging approach is
{code}
git tag -a -f cassandra-test
git push origin :refs/tags/cassandra-test
git push origin --tags
{code}
was:
The python dtests (cassandra-dtest repo) creates its clusters using ccm.
The version of ccm it uses is the HEAD of the {{cassandra-test}} branch. This
is referenced in the
[requirements.txt|https://github.com/apache/cassandra-dtest/blob/trunk/requirements.txt#L3].
The history for why a separate branch of ccm is used by dtests is explained in
https://github.com/apache/cassandra-dtest/pull/13
Long story short: the separate branch avoids two headaches
- the 'latest commit to master' broke all the c* builds surprises', and
- the 'i have to cut a release of ccm just to get a ccm change into use by
dtests'
But the two branches: {{master}} and {{cassandra-test}}; have effectively been
treated as two separate repositories, with (non-fast-forward) merges happening
in both directions. This makes the git history of both branches messy and
difficult to use, and it makes the merge strategy confusing. Bi-directional
merging between branches is considered a poor practice by many (Laura Wingerd's
'The Flow of Change'
[presentation|https://www.perforce.com/sites/default/files/flow-change-wingerd.pdf]
and
[book|https://books.google.no/books?id=mlm61wb2v3MC=PT191=PT191=%22don%27t+drive+through+hedges%22=bl=I_rYBRJwTD=ACfU3U1iKLORDQii5uiTveaKPOpa3cFqng=en=X=2ahUKEwju96-DpZnuAhWytYsKHeW6D5EQ6AEwAHoECAEQAg#v=onepage=%22don't%20drive%20through%20hedges%22=false]
refers to this as "don't drive through hedges" and encourages the "merge down,
copy up" approach against the "tofu scale: firm above, soft below").
To date, AFAIK no merges between the branches have occurred since January 2018.
A possible improvement to this process is to replace the {{cassandra-test}}
branch with a floating tag (of the same name).
That way new commits to {{master}} are not automatically used by the python
dtests. And changes made to ccm and intended/needed to be used by the dtests
can be put in use by re-tagging {{cassandra-test}} to master's HEAD.
The re-tagging approach is
{code}
git tag -a -f cassandra-test
git push origin :refs/tags/cassandra-test
git push -f origin --tags
{code}
> Python dtests to use ccm tag instead of the `cassandra-test` branch
> ---
>
> Key: CASSANDRA-16383
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16383
> Project: Cassandra
> Issue Type: Task
> Components: Test/dtest/python
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
[jira] [Comment Edited] (CASSANDRA-19650) CCM wrongly interprets CASSANDRA_USE_JDK11 for Cassandra 4.x
[
https://issues.apache.org/jira/browse/CASSANDRA-19650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17849257#comment-17849257
]
Michael Semb Wever edited comment on CASSANDRA-19650 at 5/24/24 12:46 PM:
--
CI using both patches (which fixes all^ problems)
- https://github.com/riptano/ccm/pull/769
- https://github.com/riptano/ccm/pull/770
5.0 all dtests (doesn't cover any of the breakages)
- [^CASSANDRA-19650_50_84_ci_summary.html] and
[^CASSANDRA-19650_50_84_ci_summary.htmlresults_details.tar.xz]
Trunk all dtests (doesn't cover any of the breakages)
- [^CASSANDRA-19650_trunk_85_ci_summary.html] and
[^CASSANDRA-19650_trunk_85_results_details.tar.xz]
4.1 dtest (doesn't cover any of the breakages)
- https://ci-cassandra.apache.org/job/Cassandra-devbranch-before-5-dtest/5/
-
https://nightlies.apache.org/cassandra/devbranch/Cassandra-devbranch-before-5-dtest/5/
4.1 dtest-upgrade (doesn't cover any of the breakages)
-
https://ci-cassandra.apache.org/job/Cassandra-devbranch-before-5-dtest-upgrade/5/
-
https://nightlies.apache.org/cassandra/devbranch/Cassandra-devbranch-before-5-dtest-upgrade/5/
[~aweisberg] confirmed on the PR
[here|https://github.com/riptano/ccm/pull/770#pullrequestreview-2074344248] his
breakages are fixed.
4.1 cqlsh-test (does cover a breakage)
-
https://ci-cassandra.apache.org/job/Cassandra-devbranch-before-5-cqlsh-tests/4/
-
https://nightlies.apache.org/cassandra/devbranch/Cassandra-devbranch-before-5-cqlsh-tests/4/
4.0 cqlsh-test
-
https://ci-cassandra.apache.org/job/Cassandra-devbranch-before-5-cqlsh-tests/5/
Everything looks good!
was (Author: michaelsembwever):
CI using both patches (which fixes all^ problems)
- https://github.com/riptano/ccm/pull/769
- https://github.com/riptano/ccm/pull/770
5.0 all dtests (doesn't cover any of the breakages)
- [^CASSANDRA-19650_50_84_ci_summary.html] and
[^CASSANDRA-19650_50_84_ci_summary.htmlresults_details.tar.xz]
Trunk all dtests (doesn't cover any of the breakages)
-
4.1 dtest (doesn't cover any of the breakages)
- https://ci-cassandra.apache.org/job/Cassandra-devbranch-before-5-dtest/5/
-
https://nightlies.apache.org/cassandra/devbranch/Cassandra-devbranch-before-5-dtest/5/
4.1 dtest-upgrade (doesn't cover any of the breakages)
-
https://ci-cassandra.apache.org/job/Cassandra-devbranch-before-5-dtest-upgrade/5/
-
https://nightlies.apache.org/cassandra/devbranch/Cassandra-devbranch-before-5-dtest-upgrade/5/
[~aweisberg] confirmed on the PR
[here|https://github.com/riptano/ccm/pull/770#pullrequestreview-2074344248] his
breakages are fixed.
4.1 cqlsh-test (does cover a breakage)
-
https://ci-cassandra.apache.org/job/Cassandra-devbranch-before-5-cqlsh-tests/4/
-
https://nightlies.apache.org/cassandra/devbranch/Cassandra-devbranch-before-5-cqlsh-tests/4/
4.0 cqlsh-test
-
https://ci-cassandra.apache.org/job/Cassandra-devbranch-before-5-cqlsh-tests/5/
Everything looks good!
> CCM wrongly interprets CASSANDRA_USE_JDK11 for Cassandra 4.x
>
>
> Key: CASSANDRA-19650
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19650
> Project: Cassandra
> Issue Type: Bug
> Components: Build, Test/dtest/python
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x
>
> Attachments: CASSANDRA-19650_50_84_ci_summary.html,
> CASSANDRA-19650_50_84_ci_summary.htmlresults_details.tar.xz,
> CASSANDRA-19650_trunk_85_ci_summary.html,
> CASSANDRA-19650_trunk_85_results_details.tar.xz
>
>
> CCM interprets {{CASSANDRA_USE_JDK11}} only by its existence in the
> environment rather than by its actual value (true/false).
> I can see two solutions:
> - make it interpret {{CASSANDRA_USE_JDK11}} properly
> - do not take into account {{CASSANDRA_USE_JDK11}} in the current env and set
> it or unset it automatically when starting a node basing on which Java
> version was selected
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19650) CCM wrongly interprets CASSANDRA_USE_JDK11 for Cassandra 4.x
[
https://issues.apache.org/jira/browse/CASSANDRA-19650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-19650:
---
Attachment: CASSANDRA-19650_trunk_85_results_details.tar.xz
CASSANDRA-19650_trunk_85_ci_summary.html
> CCM wrongly interprets CASSANDRA_USE_JDK11 for Cassandra 4.x
>
>
> Key: CASSANDRA-19650
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19650
> Project: Cassandra
> Issue Type: Bug
> Components: Build, Test/dtest/python
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x
>
> Attachments: CASSANDRA-19650_50_84_ci_summary.html,
> CASSANDRA-19650_50_84_ci_summary.htmlresults_details.tar.xz,
> CASSANDRA-19650_trunk_85_ci_summary.html,
> CASSANDRA-19650_trunk_85_results_details.tar.xz
>
>
> CCM interprets {{CASSANDRA_USE_JDK11}} only by its existence in the
> environment rather than by its actual value (true/false).
> I can see two solutions:
> - make it interpret {{CASSANDRA_USE_JDK11}} properly
> - do not take into account {{CASSANDRA_USE_JDK11}} in the current env and set
> it or unset it automatically when starting a node basing on which Java
> version was selected
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-19650) CCM wrongly interprets CASSANDRA_USE_JDK11 for Cassandra 4.x
[
https://issues.apache.org/jira/browse/CASSANDRA-19650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17849257#comment-17849257
]
Michael Semb Wever edited comment on CASSANDRA-19650 at 5/24/24 12:45 PM:
--
CI using both patches (which fixes all^ problems)
- https://github.com/riptano/ccm/pull/769
- https://github.com/riptano/ccm/pull/770
5.0 all dtests (doesn't cover any of the breakages)
- [^CASSANDRA-19650_50_84_ci_summary.html] and
[^CASSANDRA-19650_50_84_ci_summary.htmlresults_details.tar.xz]
Trunk all dtests (doesn't cover any of the breakages)
-
4.1 dtest (doesn't cover any of the breakages)
- https://ci-cassandra.apache.org/job/Cassandra-devbranch-before-5-dtest/5/
-
https://nightlies.apache.org/cassandra/devbranch/Cassandra-devbranch-before-5-dtest/5/
4.1 dtest-upgrade (doesn't cover any of the breakages)
-
https://ci-cassandra.apache.org/job/Cassandra-devbranch-before-5-dtest-upgrade/5/
-
https://nightlies.apache.org/cassandra/devbranch/Cassandra-devbranch-before-5-dtest-upgrade/5/
[~aweisberg] confirmed on the PR
[here|https://github.com/riptano/ccm/pull/770#pullrequestreview-2074344248] his
breakages are fixed.
4.1 cqlsh-test (does cover a breakage)
-
https://ci-cassandra.apache.org/job/Cassandra-devbranch-before-5-cqlsh-tests/4/
-
https://nightlies.apache.org/cassandra/devbranch/Cassandra-devbranch-before-5-cqlsh-tests/4/
4.0 cqlsh-test
-
https://ci-cassandra.apache.org/job/Cassandra-devbranch-before-5-cqlsh-tests/5/
Everything looks good!
was (Author: michaelsembwever):
CI using both patches (which fixes all^ problems)
- https://github.com/riptano/ccm/pull/769
- https://github.com/riptano/ccm/pull/770
5.0 all dtests (doesn't cover any of the breakages)
- [^CASSANDRA-19650_50_84_ci_summary.html] and
[^CASSANDRA-19650_50_84_ci_summary.htmlresults_details.tar.xz]
Trunk all dtests (doesn't cover any of the breakages)
-
https://ci-cassandra.apache.org/job/Cassandra-devbranch-before-5-cqlsh-tests/5/
4.1 dtest (doesn't cover any of the breakages)
- https://ci-cassandra.apache.org/job/Cassandra-devbranch-before-5-dtest/5/
-
https://nightlies.apache.org/cassandra/devbranch/Cassandra-devbranch-before-5-dtest/5/
4.1 dtest-upgrade (doesn't cover any of the breakages)
-
https://ci-cassandra.apache.org/job/Cassandra-devbranch-before-5-dtest-upgrade/5/
-
https://nightlies.apache.org/cassandra/devbranch/Cassandra-devbranch-before-5-dtest-upgrade/5/
[~aweisberg] confirmed on the PR
[here|https://github.com/riptano/ccm/pull/770#pullrequestreview-2074344248] his
breakages are fixed.
4.1 cqlsh-test (does cover a breakage)
-
https://ci-cassandra.apache.org/job/Cassandra-devbranch-before-5-cqlsh-tests/4/
-
https://nightlies.apache.org/cassandra/devbranch/Cassandra-devbranch-before-5-cqlsh-tests/4/
Everything looks good!
> CCM wrongly interprets CASSANDRA_USE_JDK11 for Cassandra 4.x
>
>
> Key: CASSANDRA-19650
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19650
> Project: Cassandra
> Issue Type: Bug
> Components: Build, Test/dtest/python
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x
>
> Attachments: CASSANDRA-19650_50_84_ci_summary.html,
> CASSANDRA-19650_50_84_ci_summary.htmlresults_details.tar.xz
>
>
> CCM interprets {{CASSANDRA_USE_JDK11}} only by its existence in the
> environment rather than by its actual value (true/false).
> I can see two solutions:
> - make it interpret {{CASSANDRA_USE_JDK11}} properly
> - do not take into account {{CASSANDRA_USE_JDK11}} in the current env and set
> it or unset it automatically when starting a node basing on which Java
> version was selected
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-19650) CCM wrongly interprets CASSANDRA_USE_JDK11 for Cassandra 4.x
[
https://issues.apache.org/jira/browse/CASSANDRA-19650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17849257#comment-17849257
]
Michael Semb Wever edited comment on CASSANDRA-19650 at 5/24/24 12:11 PM:
--
CI using both patches (which fixes all^ problems)
- https://github.com/riptano/ccm/pull/769
- https://github.com/riptano/ccm/pull/770
5.0 all dtests (doesn't cover any of the breakages)
- [^CASSANDRA-19650_50_84_ci_summary.html] and
[^CASSANDRA-19650_50_84_ci_summary.htmlresults_details.tar.xz]
Trunk all dtests (doesn't cover any of the breakages)
-
https://ci-cassandra.apache.org/job/Cassandra-devbranch-before-5-cqlsh-tests/5/
4.1 dtest (doesn't cover any of the breakages)
- https://ci-cassandra.apache.org/job/Cassandra-devbranch-before-5-dtest/5/
-
https://nightlies.apache.org/cassandra/devbranch/Cassandra-devbranch-before-5-dtest/5/
4.1 dtest-upgrade (doesn't cover any of the breakages)
-
https://ci-cassandra.apache.org/job/Cassandra-devbranch-before-5-dtest-upgrade/5/
-
https://nightlies.apache.org/cassandra/devbranch/Cassandra-devbranch-before-5-dtest-upgrade/5/
[~aweisberg] confirmed on the PR
[here|https://github.com/riptano/ccm/pull/770#pullrequestreview-2074344248] his
breakages are fixed.
4.1 cqlsh-test (does cover a breakage)
-
https://ci-cassandra.apache.org/job/Cassandra-devbranch-before-5-cqlsh-tests/4/
-
https://nightlies.apache.org/cassandra/devbranch/Cassandra-devbranch-before-5-cqlsh-tests/4/
Everything looks good!
was (Author: michaelsembwever):
CI using both patches (which fixes all^ problems)
- https://github.com/riptano/ccm/pull/769
- https://github.com/riptano/ccm/pull/770
5.0 all dtests (doesn't cover any of the breakages)
- [^CASSANDRA-19650_50_84_ci_summary.html] and
[^CASSANDRA-19650_50_84_ci_summary.htmlresults_details.tar.xz]
Trunk all dtests (doesn't cover any of the breakages)
- wip…
4.1 dtest (doesn't cover any of the breakages)
- https://ci-cassandra.apache.org/job/Cassandra-devbranch-before-5-dtest/5/
-
https://nightlies.apache.org/cassandra/devbranch/Cassandra-devbranch-before-5-dtest/5/
4.1 dtest-upgrade (doesn't cover any of the breakages)
-
https://ci-cassandra.apache.org/job/Cassandra-devbranch-before-5-dtest-upgrade/5/
-
https://nightlies.apache.org/cassandra/devbranch/Cassandra-devbranch-before-5-dtest-upgrade/5/
[~aweisberg] confirmed on the PR
[here|https://github.com/riptano/ccm/pull/770#pullrequestreview-2074344248] his
breakages are fixed.
4.1 cqlsh-test (does cover a breakage)
-
https://ci-cassandra.apache.org/job/Cassandra-devbranch-before-5-cqlsh-tests/4/
-
https://nightlies.apache.org/cassandra/devbranch/Cassandra-devbranch-before-5-cqlsh-tests/4/
Everything looks good!
> CCM wrongly interprets CASSANDRA_USE_JDK11 for Cassandra 4.x
>
>
> Key: CASSANDRA-19650
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19650
> Project: Cassandra
> Issue Type: Bug
> Components: Build, Test/dtest/python
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x
>
> Attachments: CASSANDRA-19650_50_84_ci_summary.html,
> CASSANDRA-19650_50_84_ci_summary.htmlresults_details.tar.xz
>
>
> CCM interprets {{CASSANDRA_USE_JDK11}} only by its existence in the
> environment rather than by its actual value (true/false).
> I can see two solutions:
> - make it interpret {{CASSANDRA_USE_JDK11}} properly
> - do not take into account {{CASSANDRA_USE_JDK11}} in the current env and set
> it or unset it automatically when starting a node basing on which Java
> version was selected
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19654) Update bundled Cassandra cassandra-driver-core dependency
[ https://issues.apache.org/jira/browse/CASSANDRA-19654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17849268#comment-17849268 ] Brandon Williams commented on CASSANDRA-19654: -- We're already [suppressing|https://github.com/apache/cassandra/blob/trunk/.build/owasp/dependency-check-suppressions.xml] some jackson-databind and netty CVEs, if this isn't tripping OWASP then I'm not sure it's a problem. > Update bundled Cassandra cassandra-driver-core dependency > - > > Key: CASSANDRA-19654 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19654 > Project: Cassandra > Issue Type: Task > Components: Dependencies >Reporter: Jackson Fleming >Priority: Normal > > There's a dependency in Cassandra project on an old version of the Java > driver cassandra-driver-core - 3.11.0 in the 4.0 and later releases of > Cassandra > > (For example on the 4.1 branch > [https://github.com/apache/cassandra/blob/cassandra-4.1/build.xml#L691)] > > It appears that this dependency may have some security vulnerabilities in > transitive dependencies. > But also this is a very old version of the driver, ideally it would be > aligned to a newer version, I would suggest either 3.11.5 which is the latest > in that line of driver versions > [https://mvnrepository.com/artifact/com.datastax.cassandra/cassandra-driver-core|https://mvnrepository.com/artifact/com.datastax.cassandra/cassandra-driver-core)] > or this gets updated to the latest 4.x driver (as of writing that's 4.18.1 in > [https://mvnrepository.com/artifact/org.apache.cassandra/java-driver-core] ) > but this seems like a larger undertaking. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19632) wrap tracing logs in isTraceEnabled across the codebase
[ https://issues.apache.org/jira/browse/CASSANDRA-19632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-19632: - Reviewers: Brandon Williams Status: Review In Progress (was: Needs Committer) > wrap tracing logs in isTraceEnabled across the codebase > --- > > Key: CASSANDRA-19632 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19632 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Core >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 5.x > > Time Spent: 40m > Remaining Estimate: 0h > > Our usage of logger.isTraceEnabled across the codebase is inconsistent. This > would also fix issues similar in e.g. CASSANDRA-19429 as [~rustyrazorblade] > suggested. > We should fix this at least in trunk and 5.0 (not critical though) and > probably come up with a checkstyle rule to prevent not calling isTraceEnabled > while logging with TRACE level. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19650) CCM wrongly interprets CASSANDRA_USE_JDK11 for Cassandra 4.x
[
https://issues.apache.org/jira/browse/CASSANDRA-19650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17849261#comment-17849261
]
Jacek Lewandowski commented on CASSANDRA-19650:
---
Thank you [~mck] for reviewing and running the tests!
> CCM wrongly interprets CASSANDRA_USE_JDK11 for Cassandra 4.x
>
>
> Key: CASSANDRA-19650
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19650
> Project: Cassandra
> Issue Type: Bug
> Components: Build, Test/dtest/python
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x
>
> Attachments: CASSANDRA-19650_50_84_ci_summary.html,
> CASSANDRA-19650_50_84_ci_summary.htmlresults_details.tar.xz
>
>
> CCM interprets {{CASSANDRA_USE_JDK11}} only by its existence in the
> environment rather than by its actual value (true/false).
> I can see two solutions:
> - make it interpret {{CASSANDRA_USE_JDK11}} properly
> - do not take into account {{CASSANDRA_USE_JDK11}} in the current env and set
> it or unset it automatically when starting a node basing on which Java
> version was selected
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19650) CCM wrongly interprets CASSANDRA_USE_JDK11 for Cassandra 4.x
[
https://issues.apache.org/jira/browse/CASSANDRA-19650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacek Lewandowski updated CASSANDRA-19650:
--
Since Version: NA
Source Control Link:
https://github.com/riptano/ccm/commit/4aae08061347075f25964db7aebc889719ffc83b
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
> CCM wrongly interprets CASSANDRA_USE_JDK11 for Cassandra 4.x
>
>
> Key: CASSANDRA-19650
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19650
> Project: Cassandra
> Issue Type: Bug
> Components: Build, Test/dtest/python
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x
>
> Attachments: CASSANDRA-19650_50_84_ci_summary.html,
> CASSANDRA-19650_50_84_ci_summary.htmlresults_details.tar.xz
>
>
> CCM interprets {{CASSANDRA_USE_JDK11}} only by its existence in the
> environment rather than by its actual value (true/false).
> I can see two solutions:
> - make it interpret {{CASSANDRA_USE_JDK11}} properly
> - do not take into account {{CASSANDRA_USE_JDK11}} in the current env and set
> it or unset it automatically when starting a node basing on which Java
> version was selected
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-19650) CCM wrongly interprets CASSANDRA_USE_JDK11 for Cassandra 4.x
[
https://issues.apache.org/jira/browse/CASSANDRA-19650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17849257#comment-17849257
]
Michael Semb Wever edited comment on CASSANDRA-19650 at 5/24/24 10:55 AM:
--
CI using both patches (which fixes all^ problems)
- https://github.com/riptano/ccm/pull/769
- https://github.com/riptano/ccm/pull/770
5.0 all dtests (doesn't cover any of the breakages)
- [^CASSANDRA-19650_50_84_ci_summary.html] and
[^CASSANDRA-19650_50_84_ci_summary.htmlresults_details.tar.xz]
Trunk all dtests (doesn't cover any of the breakages)
- wip…
4.1 dtest (doesn't cover any of the breakages)
- https://ci-cassandra.apache.org/job/Cassandra-devbranch-before-5-dtest/5/
-
https://nightlies.apache.org/cassandra/devbranch/Cassandra-devbranch-before-5-dtest/5/
4.1 dtest-upgrade (doesn't cover any of the breakages)
-
https://ci-cassandra.apache.org/job/Cassandra-devbranch-before-5-dtest-upgrade/5/
-
https://nightlies.apache.org/cassandra/devbranch/Cassandra-devbranch-before-5-dtest-upgrade/5/
[~aweisberg] confirmed on the PR
[here|https://github.com/riptano/ccm/pull/770#pullrequestreview-2074344248] his
breakages are fixed.
4.1 cqlsh-test (does cover a breakage)
-
https://ci-cassandra.apache.org/job/Cassandra-devbranch-before-5-cqlsh-tests/4/
-
https://nightlies.apache.org/cassandra/devbranch/Cassandra-devbranch-before-5-cqlsh-tests/4/
Everything looks good!
was (Author: michaelsembwever):
CI using both patches (which fixes all^ problems)
- https://github.com/riptano/ccm/pull/769
- https://github.com/riptano/ccm/pull/770
5.0 all dtests (doesn't cover any of the breakages)
- [^CASSANDRA-19650_50_84_ci_summary.html] and
[^CASSANDRA-19650_50_84_ci_summary.htmlresults_details.tar.xz]
Trunk all dtests (doesn't cover any of the breakages)
- wip…
4.1 dtest (doesn't cover any of the breakages)
- https://ci-cassandra.apache.org/job/Cassandra-devbranch-before-5-dtest/5/
-
https://nightlies.apache.org/cassandra/devbranch/Cassandra-devbranch-before-5-dtest/5/
4.1 dtest-upgrade (doesn't cover any of the breakages)
-
https://ci-cassandra.apache.org/job/Cassandra-devbranch-before-5-dtest-upgrade/5/
-
https://nightlies.apache.org/cassandra/devbranch/Cassandra-devbranch-before-5-dtest-upgrade/5/
[~aweisberg] confirmed on slack his breakages are fixed.
4.1 cqlsh-test (does cover a breakage)
-
https://ci-cassandra.apache.org/job/Cassandra-devbranch-before-5-cqlsh-tests/4/
-
https://nightlies.apache.org/cassandra/devbranch/Cassandra-devbranch-before-5-cqlsh-tests/4/
Everything looks good!
> CCM wrongly interprets CASSANDRA_USE_JDK11 for Cassandra 4.x
>
>
> Key: CASSANDRA-19650
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19650
> Project: Cassandra
> Issue Type: Bug
> Components: Build, Test/dtest/python
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x
>
> Attachments: CASSANDRA-19650_50_84_ci_summary.html,
> CASSANDRA-19650_50_84_ci_summary.htmlresults_details.tar.xz
>
>
> CCM interprets {{CASSANDRA_USE_JDK11}} only by its existence in the
> environment rather than by its actual value (true/false).
> I can see two solutions:
> - make it interpret {{CASSANDRA_USE_JDK11}} properly
> - do not take into account {{CASSANDRA_USE_JDK11}} in the current env and set
> it or unset it automatically when starting a node basing on which Java
> version was selected
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19650) CCM wrongly interprets CASSANDRA_USE_JDK11 for Cassandra 4.x
[
https://issues.apache.org/jira/browse/CASSANDRA-19650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17849257#comment-17849257
]
Michael Semb Wever commented on CASSANDRA-19650:
CI using both patches (which fixes all^ problems)
- https://github.com/riptano/ccm/pull/769
- https://github.com/riptano/ccm/pull/770
5.0 all dtests (doesn't cover any of the breakages)
- [^CASSANDRA-19650_50_84_ci_summary.html] and
[^CASSANDRA-19650_50_84_ci_summary.htmlresults_details.tar.xz]
Trunk all dtests (doesn't cover any of the breakages)
- wip…
4.1 dtest (doesn't cover any of the breakages)
- https://ci-cassandra.apache.org/job/Cassandra-devbranch-before-5-dtest/5/
-
https://nightlies.apache.org/cassandra/devbranch/Cassandra-devbranch-before-5-dtest/5/
4.1 dtest-upgrade (doesn't cover any of the breakages)
-
https://ci-cassandra.apache.org/job/Cassandra-devbranch-before-5-dtest-upgrade/5/
-
https://nightlies.apache.org/cassandra/devbranch/Cassandra-devbranch-before-5-dtest-upgrade/5/
[~aweisberg] confirmed on slack his breakages are fixed.
4.1 cqlsh-test (does cover a breakage)
-
https://ci-cassandra.apache.org/job/Cassandra-devbranch-before-5-cqlsh-tests/4/
-
https://nightlies.apache.org/cassandra/devbranch/Cassandra-devbranch-before-5-cqlsh-tests/4/
Everything looks good!
> CCM wrongly interprets CASSANDRA_USE_JDK11 for Cassandra 4.x
>
>
> Key: CASSANDRA-19650
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19650
> Project: Cassandra
> Issue Type: Bug
> Components: Build, Test/dtest/python
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x
>
> Attachments: CASSANDRA-19650_50_84_ci_summary.html,
> CASSANDRA-19650_50_84_ci_summary.htmlresults_details.tar.xz
>
>
> CCM interprets {{CASSANDRA_USE_JDK11}} only by its existence in the
> environment rather than by its actual value (true/false).
> I can see two solutions:
> - make it interpret {{CASSANDRA_USE_JDK11}} properly
> - do not take into account {{CASSANDRA_USE_JDK11}} in the current env and set
> it or unset it automatically when starting a node basing on which Java
> version was selected
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19650) CCM wrongly interprets CASSANDRA_USE_JDK11 for Cassandra 4.x
[
https://issues.apache.org/jira/browse/CASSANDRA-19650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-19650:
---
Status: Ready to Commit (was: Review In Progress)
> CCM wrongly interprets CASSANDRA_USE_JDK11 for Cassandra 4.x
>
>
> Key: CASSANDRA-19650
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19650
> Project: Cassandra
> Issue Type: Bug
> Components: Build, Test/dtest/python
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x
>
> Attachments: CASSANDRA-19650_50_84_ci_summary.html,
> CASSANDRA-19650_50_84_ci_summary.htmlresults_details.tar.xz
>
>
> CCM interprets {{CASSANDRA_USE_JDK11}} only by its existence in the
> environment rather than by its actual value (true/false).
> I can see two solutions:
> - make it interpret {{CASSANDRA_USE_JDK11}} properly
> - do not take into account {{CASSANDRA_USE_JDK11}} in the current env and set
> it or unset it automatically when starting a node basing on which Java
> version was selected
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19654) Update bundled Cassandra cassandra-driver-core dependency
[ https://issues.apache.org/jira/browse/CASSANDRA-19654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17849228#comment-17849228 ] Stefan Miklosovic commented on CASSANDRA-19654: --- I am not sure if we are going to bump the versions in a patch releases. We should carefully evaluate what impact it has because people bumping a patch release in their integrations do not expect that their dependency tree would be changed suddenly and substantially. cc [~brandon.williams] > Update bundled Cassandra cassandra-driver-core dependency > - > > Key: CASSANDRA-19654 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19654 > Project: Cassandra > Issue Type: Task > Components: Dependencies >Reporter: Jackson Fleming >Priority: Normal > > There's a dependency in Cassandra project on an old version of the Java > driver cassandra-driver-core - 3.11.0 in the 4.0 and later releases of > Cassandra > > (For example on the 4.1 branch > [https://github.com/apache/cassandra/blob/cassandra-4.1/build.xml#L691)] > > It appears that this dependency may have some security vulnerabilities in > transitive dependencies. > But also this is a very old version of the driver, ideally it would be > aligned to a newer version, I would suggest either 3.11.5 which is the latest > in that line of driver versions > [https://mvnrepository.com/artifact/com.datastax.cassandra/cassandra-driver-core|https://mvnrepository.com/artifact/com.datastax.cassandra/cassandra-driver-core)] > or this gets updated to the latest 4.x driver (as of writing that's 4.18.1 in > [https://mvnrepository.com/artifact/org.apache.cassandra/java-driver-core] ) > but this seems like a larger undertaking. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-19654) Update bundled Cassandra cassandra-driver-core dependency
[ https://issues.apache.org/jira/browse/CASSANDRA-19654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17849228#comment-17849228 ] Stefan Miklosovic edited comment on CASSANDRA-19654 at 5/24/24 9:25 AM: I am not sure if we are going to bump the versions in a patch release. We should carefully evaluate what impact it has because people bumping a patch release in their integrations do not expect that their dependency tree would be changed suddenly and substantially. cc [~brandon.williams] was (Author: smiklosovic): I am not sure if we are going to bump the versions in a patch releases. We should carefully evaluate what impact it has because people bumping a patch release in their integrations do not expect that their dependency tree would be changed suddenly and substantially. cc [~brandon.williams] > Update bundled Cassandra cassandra-driver-core dependency > - > > Key: CASSANDRA-19654 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19654 > Project: Cassandra > Issue Type: Task > Components: Dependencies >Reporter: Jackson Fleming >Priority: Normal > > There's a dependency in Cassandra project on an old version of the Java > driver cassandra-driver-core - 3.11.0 in the 4.0 and later releases of > Cassandra > > (For example on the 4.1 branch > [https://github.com/apache/cassandra/blob/cassandra-4.1/build.xml#L691)] > > It appears that this dependency may have some security vulnerabilities in > transitive dependencies. > But also this is a very old version of the driver, ideally it would be > aligned to a newer version, I would suggest either 3.11.5 which is the latest > in that line of driver versions > [https://mvnrepository.com/artifact/com.datastax.cassandra/cassandra-driver-core|https://mvnrepository.com/artifact/com.datastax.cassandra/cassandra-driver-core)] > or this gets updated to the latest 4.x driver (as of writing that's 4.18.1 in > [https://mvnrepository.com/artifact/org.apache.cassandra/java-driver-core] ) > but this seems like a larger undertaking. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19450) Hygiene updates for warnings and pytests
[ https://issues.apache.org/jira/browse/CASSANDRA-19450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-19450: -- Fix Version/s: 5.1 (was: 5.x) Source Control Link: https://github.com/apache/cassandra/commit/6701259bce91672a7c3ca9fb77ea7b040e9c Resolution: Fixed Status: Resolved (was: Ready to Commit) > Hygiene updates for warnings and pytests > > > Key: CASSANDRA-19450 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19450 > Project: Cassandra > Issue Type: Improvement > Components: CQL/Interpreter >Reporter: Brad Schoening >Assignee: Brad Schoening >Priority: Low > Fix For: 5.1 > > > > * -Update 'Warning' message to write to stderr- > * -Replace TimeoutError Exception with builtin (since Python 3.3)- > * -Remove re.pattern_type (removed since Python 3.7)- > * Fix mutable arg [] in test/run_cqlsh.py read_until() > * Remove redirect of stderr to stdout in pytest fixture with tty=false; > Deprecation warnings can otherwise fail unit tests when stdout & stderr > output is combined. > * Fix several pycodestyle issues -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-19450) Hygiene updates for warnings and pytests
[
https://issues.apache.org/jira/browse/CASSANDRA-19450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17849221#comment-17849221
]
Stefan Miklosovic edited comment on CASSANDRA-19450 at 5/24/24 8:51 AM:
I think this just looks fine. Going to ship it.
[CASSANDRA-19450|https://github.com/instaclustr/cassandra/tree/CASSANDRA-19450]
{noformat}
java17_pre-commit_tests
✓ j17_build4m 14s
✓ j17_cqlsh_dtests_py311 6m 57s
✓ j17_cqlsh_dtests_py311_vnode 7m 22s
✓ j17_cqlsh_dtests_py386m 55s
✓ j17_cqlsh_dtests_py38_vnode 7m 17s
✓ j17_cqlshlib_cython_tests7m 16s
✓ j17_cqlshlib_tests 6m 23s
✓ j17_dtests 36m 35s
✓ j17_dtests_vnode 35m 1s
✓ j17_unit_tests 14m 20s
✓ j17_utests_oa13m 2s
✕ j17_dtests_latest 35m 19s
streaming_test.TestStreaming test_zerocopy_streaming_no_replication
✕ j17_jvm_dtests 24m 34s
org.apache.cassandra.fuzz.harry.integration.model.InJVMTokenAwareExecutorTest
testRepair TIMEOUTED
✕ j17_jvm_dtests_latest_vnode 24m 15s
org.apache.cassandra.distributed.test.jmx.JMXFeatureTest
testOneNetworkInterfaceProvisioning
✕ j17_utests_latest 15m 50s
org.apache.cassandra.tcm.DiscoverySimulationTest discoveryTest
java17_separate_tests
java11_pre-commit_tests
java11_separate_tests
{noformat}
[java17_pre-commit_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4351/workflows/5f522c11-aae5-4915-8102-f79807d661d6]
[java17_separate_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4351/workflows/87429218-e1e2-4589-b879-09f9e80ef3b6]
[java11_pre-commit_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4351/workflows/222ad871-683e-4a14-919d-9e3e92def96c]
[java11_separate_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4351/workflows/3cd71329-9b0f-4f48-ae2b-33fd057520c9]
streaming_test.py::TestStreaming::test_zerocopy_streaming_no_replication was
verified to work locally
was (Author: smiklosovic):
I think this just looks fine. Going to ship it.
[CASSANDRA-19450|https://github.com/instaclustr/cassandra/tree/CASSANDRA-19450]
{noformat}
java17_pre-commit_tests
✓ j17_build4m 14s
✓ j17_cqlsh_dtests_py311 6m 57s
✓ j17_cqlsh_dtests_py311_vnode 7m 22s
✓ j17_cqlsh_dtests_py386m 55s
✓ j17_cqlsh_dtests_py38_vnode 7m 17s
✓ j17_cqlshlib_cython_tests7m 16s
✓ j17_cqlshlib_tests 6m 23s
✓ j17_dtests 36m 35s
✓ j17_dtests_vnode 35m 1s
✓ j17_unit_tests 14m 20s
✓ j17_utests_oa13m 2s
✕ j17_dtests_latest 35m 19s
streaming_test.TestStreaming test_zerocopy_streaming_no_replication
✕ j17_jvm_dtests 24m 34s
org.apache.cassandra.fuzz.harry.integration.model.InJVMTokenAwareExecutorTest
testRepair TIMEOUTED
✕ j17_jvm_dtests_latest_vnode 24m 15s
org.apache.cassandra.distributed.test.jmx.JMXFeatureTest
testOneNetworkInterfaceProvisioning
✕ j17_utests_latest 15m 50s
org.apache.cassandra.tcm.DiscoverySimulationTest discoveryTest
java17_separate_tests
java11_pre-commit_tests
java11_separate_tests
{noformat}
[java17_pre-commit_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4351/workflows/5f522c11-aae5-4915-8102-f79807d661d6]
[java17_separate_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4351/workflows/87429218-e1e2-4589-b879-09f9e80ef3b6]
[java11_pre-commit_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4351/workflows/222ad871-683e-4a14-919d-9e3e92def96c]
[java11_separate_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4351/workflows/3cd71329-9b0f-4f48-ae2b-33fd057520c9]
> Hygiene updates for warnings and pytests
>
>
> Key: CASSANDRA-19450
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19450
>
[jira] [Commented] (CASSANDRA-19632) wrap tracing logs in isTraceEnabled across the codebase
[ https://issues.apache.org/jira/browse/CASSANDRA-19632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17849222#comment-17849222 ] Stefan Miklosovic commented on CASSANDRA-19632: --- [~brandon.williams] any feedback on the second patch I just provided CI for above? > wrap tracing logs in isTraceEnabled across the codebase > --- > > Key: CASSANDRA-19632 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19632 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Core >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 5.x > > Time Spent: 40m > Remaining Estimate: 0h > > Our usage of logger.isTraceEnabled across the codebase is inconsistent. This > would also fix issues similar in e.g. CASSANDRA-19429 as [~rustyrazorblade] > suggested. > We should fix this at least in trunk and 5.0 (not critical though) and > probably come up with a checkstyle rule to prevent not calling isTraceEnabled > while logging with TRACE level. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19450) Hygiene updates for warnings and pytests
[
https://issues.apache.org/jira/browse/CASSANDRA-19450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17849221#comment-17849221
]
Stefan Miklosovic commented on CASSANDRA-19450:
---
I think this just looks fine. Going to ship it.
[CASSANDRA-19450|https://github.com/instaclustr/cassandra/tree/CASSANDRA-19450]
{noformat}
java17_pre-commit_tests
✓ j17_build4m 14s
✓ j17_cqlsh_dtests_py311 6m 57s
✓ j17_cqlsh_dtests_py311_vnode 7m 22s
✓ j17_cqlsh_dtests_py386m 55s
✓ j17_cqlsh_dtests_py38_vnode 7m 17s
✓ j17_cqlshlib_cython_tests7m 16s
✓ j17_cqlshlib_tests 6m 23s
✓ j17_dtests 36m 35s
✓ j17_dtests_vnode 35m 1s
✓ j17_unit_tests 14m 20s
✓ j17_utests_oa13m 2s
✕ j17_dtests_latest 35m 19s
streaming_test.TestStreaming test_zerocopy_streaming_no_replication
✕ j17_jvm_dtests 24m 34s
org.apache.cassandra.fuzz.harry.integration.model.InJVMTokenAwareExecutorTest
testRepair TIMEOUTED
✕ j17_jvm_dtests_latest_vnode 24m 15s
org.apache.cassandra.distributed.test.jmx.JMXFeatureTest
testOneNetworkInterfaceProvisioning
✕ j17_utests_latest 15m 50s
org.apache.cassandra.tcm.DiscoverySimulationTest discoveryTest
java17_separate_tests
java11_pre-commit_tests
java11_separate_tests
{noformat}
[java17_pre-commit_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4351/workflows/5f522c11-aae5-4915-8102-f79807d661d6]
[java17_separate_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4351/workflows/87429218-e1e2-4589-b879-09f9e80ef3b6]
[java11_pre-commit_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4351/workflows/222ad871-683e-4a14-919d-9e3e92def96c]
[java11_separate_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4351/workflows/3cd71329-9b0f-4f48-ae2b-33fd057520c9]
> Hygiene updates for warnings and pytests
>
>
> Key: CASSANDRA-19450
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19450
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Brad Schoening
>Assignee: Brad Schoening
>Priority: Low
> Fix For: 5.x
>
>
>
> * -Update 'Warning' message to write to stderr-
> * -Replace TimeoutError Exception with builtin (since Python 3.3)-
> * -Remove re.pattern_type (removed since Python 3.7)-
> * Fix mutable arg [] in test/run_cqlsh.py read_until()
> * Remove redirect of stderr to stdout in pytest fixture with tty=false;
> Deprecation warnings can otherwise fail unit tests when stdout & stderr
> output is combined.
> * Fix several pycodestyle issues
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19632) wrap tracing logs in isTraceEnabled across the codebase
[
https://issues.apache.org/jira/browse/CASSANDRA-19632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17849220#comment-17849220
]
Stefan Miklosovic commented on CASSANDRA-19632:
---
Looks fine, I think that cqlsh_tests.test_cqlsh.TestCqlsh test_describe is the
result of CASSANDRA-19592 and this build was not rebased againt the current
trunk
[CASSANDRA-19632-2|https://github.com/instaclustr/cassandra/tree/CASSANDRA-19632-2]
{noformat}
java17_pre-commit_tests
✓ j17_build5m 12s
✓ j17_cqlsh_dtests_py311_vnode 7m 45s
✓ j17_cqlsh_dtests_py386m 56s
✓ j17_cqlsh_dtests_py38_vnode 7m 20s
✓ j17_cqlshlib_cython_tests9m 35s
✓ j17_cqlshlib_tests 9m 30s
✓ j17_dtests 35m 34s
✓ j17_dtests_vnode36m 38s
✓ j17_jvm_dtests_latest_vnode 20m 44s
✓ j17_unit_tests 14m 15s
✓ j17_utests_latest 14m 27s
✓ j17_utests_oa 14m 21s
✕ j17_cqlsh_dtests_py311 6m 41s
cqlsh_tests.test_cqlsh.TestCqlsh test_describe
✕ j17_dtests_latest 36m 44s
auth_test.TestAuthUnavailable test_authorization_handle_unavailable
configuration_test.TestConfiguration test_change_durable_writes
✕ j17_jvm_dtests 22m 46s
java17_separate_tests
java11_pre-commit_tests
java11_separate_tests
{noformat}
[java17_pre-commit_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4344/workflows/f9410f3a-9af4-4924-a2c8-44fc3d7384c0]
[java17_separate_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4344/workflows/5a2470b3-7dee-4b50-98c7-1a5f9b50e650]
[java11_pre-commit_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4344/workflows/7263d3ca-ef7f-4499-9fff-fbb77617b613]
[java11_separate_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4344/workflows/91f98de5-c3e5-45bb-9737-a6d98922fedf]
> wrap tracing logs in isTraceEnabled across the codebase
> ---
>
> Key: CASSANDRA-19632
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19632
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Core
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Our usage of logger.isTraceEnabled across the codebase is inconsistent. This
> would also fix issues similar in e.g. CASSANDRA-19429 as [~rustyrazorblade]
> suggested.
> We should fix this at least in trunk and 5.0 (not critical though) and
> probably come up with a checkstyle rule to prevent not calling isTraceEnabled
> while logging with TRACE level.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-12937) Default setting (yaml) for SSTable compression
[
https://issues.apache.org/jira/browse/CASSANDRA-12937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17849218#comment-17849218
]
Stefan Miklosovic edited comment on CASSANDRA-12937 at 5/24/24 8:36 AM:
Seems reasonably clean ...
What I have not done is that the idea [~jlewandowski] had with "if some config
parameter is not in cql statement just merge the values from cassandra.yaml"
because it is quite tricky to get that right. We would need to know what values
were specfied and then diffing what is not there and then validating that such
combination makes sense (and if it does not, should we fail otherwise valid CQL
statement just because we happened to merge values from cassandra.yaml and that
combination was not right? I do not think so).
Let's just go with a simple case of "if compression is not specified just take
the defaults from cassandra.yaml" rather then trying to merge the configs ...
Too much of a hassle, might come as an improvement if somebody is really after
that.
I will try to come up with more tests and I think that sometimes next week this
should be all completed and ready for review again.
[CASSANDRA-12937-squashed|https://github.com/instaclustr/cassandra/tree/CASSANDRA-12937-squashed]
{noformat}
java17_pre-commit_tests
✓ j17_build 4m 7s
✓ j17_cqlsh_dtests_py311 7m 11s
✓ j17_cqlsh_dtests_py311_vnode 7m 18s
✓ j17_cqlsh_dtests_py386m 58s
✓ j17_cqlsh_dtests_py38_vnode 7m 1s
✓ j17_cqlshlib_cython_tests7m 26s
✓ j17_cqlshlib_tests 6m 50s
✓ j17_unit_tests 17m 36s
✓ j17_utests_oa 15m 39s
✕ j17_dtests 37m 48s
scrub_test.TestScrub test_standalone_scrub_essential_files_only
topology_test.TestTopology test_movement
✕ j17_dtests_latest 35m 36s
offline_tools_test.TestOfflineTools test_sstableverify
scrub_test.TestScrub test_standalone_scrub_essential_files_only
configuration_test.TestConfiguration test_change_durable_writes
✕ j17_dtests_vnode35m 11s
scrub_test.TestScrub test_standalone_scrub_essential_files_only
✕ j17_jvm_dtests 28m 15s
✕ j17_jvm_dtests_latest_vnode 27m 59s
org.apache.cassandra.fuzz.harry.integration.model.ConcurrentQuiescentCheckerIntegrationTest
testConcurrentReadWriteWorkload
✕ j17_utests_latest 14m 34s
org.apache.cassandra.tcm.DiscoverySimulationTest discoveryTest
java17_separate_tests
java11_pre-commit_tests
java11_separate_tests
{noformat}
[java17_pre-commit_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4350/workflows/a68e4fb0-bd7a-4758-841c-6b4b0fe22865]
[java17_separate_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4350/workflows/fa57a86d-d120-4304-bbdf-a6cf8fefc4d2]
[java11_pre-commit_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4350/workflows/91afc77c-54fe-4369-9cb9-ababa3568e16]
[java11_separate_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4350/workflows/71add260-9c68-4d87-9d5a-99863a01bb3f]
was (Author: smiklosovic):
Seems reasonably clean ...
What I have not done is that the idea Jacek had with "if some config parameter
is not in cql statement just merge the values from cassandra.yaml" because it
is quite tricky to get that right. We would need to know what values were
specfied and then diffing what is not there and then validating that such
combination makes sense (and if it does not, should we fail otherwise valid CQL
statement just because we happened to merge values from cassandra.yaml and that
combination was not right? I do not think so).
Let's just go with a simple case of "if compression is not specified just take
the defaults from cassandra.yaml" rather then trying to merge the configs ...
Too much of a hassle, might come as an improvement if somebody is really after
that.
I will try to come up with more tests and I think that sometimes next week this
should be all completed and ready for review again.
[CASSANDRA-12937-squashed|https://github.com/instaclustr/cassandra/tree/CASSANDRA-12937-squashed]
{noformat}
java17_pre-commit_tests
✓ j17_build 4m 7s
✓ j17_cqlsh_dtests_py311 7m 11s
✓ j17_cqlsh_dtests_py311_vnode 7m 18s
✓ j17_cqlsh_dtest
[jira] [Commented] (CASSANDRA-12937) Default setting (yaml) for SSTable compression
[
https://issues.apache.org/jira/browse/CASSANDRA-12937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17849218#comment-17849218
]
Stefan Miklosovic commented on CASSANDRA-12937:
---
Seems reasonably clean ...
What I have not done is that the idea Jacek had with "if some config parameter
is not in cql statement just merge the values from cassandra.yaml" because it
is quite tricky to get that right. We would need to know what values were
specfied and then diffing what is not there and then validating that such
combination makes sense (and if it does not, should we fail otherwise valid CQL
statement just because we happened to merge values from cassandra.yaml and that
combination was not right? I do not think so).
Let's just go with a simple case of "if compression is not specified just take
the defaults from cassandra.yaml" rather then trying to merge the configs ...
Too much of a hassle, might come as an improvement if somebody is really after
that.
I will try to come up with more tests and I think that sometimes next week this
should be all completed and ready for review again.
[CASSANDRA-12937-squashed|https://github.com/instaclustr/cassandra/tree/CASSANDRA-12937-squashed]
{noformat}
java17_pre-commit_tests
✓ j17_build 4m 7s
✓ j17_cqlsh_dtests_py311 7m 11s
✓ j17_cqlsh_dtests_py311_vnode 7m 18s
✓ j17_cqlsh_dtests_py386m 58s
✓ j17_cqlsh_dtests_py38_vnode 7m 1s
✓ j17_cqlshlib_cython_tests7m 26s
✓ j17_cqlshlib_tests 6m 50s
✓ j17_unit_tests 17m 36s
✓ j17_utests_oa 15m 39s
✕ j17_dtests 37m 48s
scrub_test.TestScrub test_standalone_scrub_essential_files_only
topology_test.TestTopology test_movement
✕ j17_dtests_latest 35m 36s
offline_tools_test.TestOfflineTools test_sstableverify
scrub_test.TestScrub test_standalone_scrub_essential_files_only
configuration_test.TestConfiguration test_change_durable_writes
✕ j17_dtests_vnode35m 11s
scrub_test.TestScrub test_standalone_scrub_essential_files_only
✕ j17_jvm_dtests 28m 15s
✕ j17_jvm_dtests_latest_vnode 27m 59s
org.apache.cassandra.fuzz.harry.integration.model.ConcurrentQuiescentCheckerIntegrationTest
testConcurrentReadWriteWorkload
✕ j17_utests_latest 14m 34s
org.apache.cassandra.tcm.DiscoverySimulationTest discoveryTest
java17_separate_tests
java11_pre-commit_tests
java11_separate_tests
{noformat}
[java17_pre-commit_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4350/workflows/a68e4fb0-bd7a-4758-841c-6b4b0fe22865]
[java17_separate_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4350/workflows/fa57a86d-d120-4304-bbdf-a6cf8fefc4d2]
[java11_pre-commit_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4350/workflows/91afc77c-54fe-4369-9cb9-ababa3568e16]
[java11_separate_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4350/workflows/71add260-9c68-4d87-9d5a-99863a01bb3f]
> Default setting (yaml) for SSTable compression
> --
>
> Key: CASSANDRA-12937
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12937
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Michael Semb Wever
>Assignee: Stefan Miklosovic
>Priority: Low
> Labels: AdventCalendar2021
> Fix For: 5.x
>
> Time Spent: 8h 20m
> Remaining Estimate: 0h
>
> In many situations the choice of compression for sstables is more relevant to
> the disks attached than to the schema and data.
> This issue is to add to cassandra.yaml a default value for sstable
> compression that new tables will inherit (instead of the defaults found in
> {{CompressionParams.DEFAULT}}.
> Examples where this can be relevant are filesystems that do on-the-fly
> compression (btrfs, zfs) or specific disk configurations or even specific C*
> versions (see CASSANDRA-10995 ).
> +Additional information for newcomers+
> Some new fields need to be added to {{cassandra.yaml}} to allow specifying
> the field required for defining the default compression parameters. In
> {{DatabaseDescriptor}} a new {
[jira] [Updated] (CASSANDRA-19650) CCM wrongly interprets CASSANDRA_USE_JDK11 for Cassandra 4.x
[
https://issues.apache.org/jira/browse/CASSANDRA-19650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-19650:
---
Attachment: CASSANDRA-19650_50_84_ci_summary.htmlresults_details.tar.xz
> CCM wrongly interprets CASSANDRA_USE_JDK11 for Cassandra 4.x
>
>
> Key: CASSANDRA-19650
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19650
> Project: Cassandra
> Issue Type: Bug
> Components: Build, Test/dtest/python
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x
>
> Attachments: CASSANDRA-19650_50_84_ci_summary.html,
> CASSANDRA-19650_50_84_ci_summary.htmlresults_details.tar.xz
>
>
> CCM interprets {{CASSANDRA_USE_JDK11}} only by its existence in the
> environment rather than by its actual value (true/false).
> I can see two solutions:
> - make it interpret {{CASSANDRA_USE_JDK11}} properly
> - do not take into account {{CASSANDRA_USE_JDK11}} in the current env and set
> it or unset it automatically when starting a node basing on which Java
> version was selected
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19650) CCM wrongly interprets CASSANDRA_USE_JDK11 for Cassandra 4.x
[
https://issues.apache.org/jira/browse/CASSANDRA-19650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-19650:
---
Attachment: CASSANDRA-19650_50_84_ci_summary.html
> CCM wrongly interprets CASSANDRA_USE_JDK11 for Cassandra 4.x
>
>
> Key: CASSANDRA-19650
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19650
> Project: Cassandra
> Issue Type: Bug
> Components: Build, Test/dtest/python
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x
>
> Attachments: CASSANDRA-19650_50_84_ci_summary.html
>
>
> CCM interprets {{CASSANDRA_USE_JDK11}} only by its existence in the
> environment rather than by its actual value (true/false).
> I can see two solutions:
> - make it interpret {{CASSANDRA_USE_JDK11}} properly
> - do not take into account {{CASSANDRA_USE_JDK11}} in the current env and set
> it or unset it automatically when starting a node basing on which Java
> version was selected
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18120) Single slow node dramatically reduces cluster logged batch write throughput regardless of CL
[ https://issues.apache.org/jira/browse/CASSANDRA-18120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17849156#comment-17849156 ] Maxim Chanturiay commented on CASSANDRA-18120: -- [~mck], [~shunsaker], No problem, of course. I won't be able to contribute anything better, anyways. I've been having extremely passionate professors for the past 2 semesters. The amount of papers to read and stuff to implement doesn't leave me any free time to work on Cassandra so far :D > Single slow node dramatically reduces cluster logged batch write throughput > regardless of CL > > > Key: CASSANDRA-18120 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18120 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Coordination >Reporter: Dan Sarisky >Assignee: Maxim Chanturiay >Priority: Normal > Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x > > > We issue writes to Cassandra as logged batches(RF=3, Consistency levels=TWO, > QUORUM, or LOCAL_QUORUM) > > On clusters of any size - a single extremely slow node causes a ~90% loss of > cluster-wide throughput using batched writes. We can replicate this in the > lab via CPU or disk throttling. I observe this in 3.11, 4.0, and 4.1. > > It appears the mechanism in play is: > Those logged batches are immediately written to two replica nodes and the > actual mutations aren't processed until those two nodes acknowledge the batch > statements. Those replica nodes are selected randomly from all nodes in the > local data center currently up in gossip. If a single node is slow, but > still thought to be up in gossip, this eventually causes every other node to > have all of its MutationStages to be waiting while the slow replica accepts > batch writes. > > The code in play appears to be: > See > [https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/locator/ReplicaPlans.java#L245]. > In the method filterBatchlogEndpoints() there is a > Collections.shuffle() to order the endpoints and a > FailureDetector.isEndpointAlive() to test if the endpoint is acceptable. > > This behavior causes Cassandra to move from a multi-node fault tolerant > system toa collection of single points of failure. > > We try to take administrator actions to kill off the extremely slow nodes, > but it would be great to have some notion of "what node is a bad choice" when > writing log batches to replica nodes. > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRASC-132) Add restore job progress endpoint and consistency check on restore ranges
[ https://issues.apache.org/jira/browse/CASSANDRASC-132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yifan Cai updated CASSANDRASC-132: -- Authors: Yifan Cai Test and Documentation Plan: ci Status: Patch Available (was: Open) > Add restore job progress endpoint and consistency check on restore ranges > - > > Key: CASSANDRASC-132 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-132 > Project: Sidecar for Apache Cassandra > Issue Type: New Feature > Components: Rest API >Reporter: Yifan Cai >Assignee: Yifan Cai >Priority: Normal > Labels: pull-request-available > > In order to support the sidecar-managed restore jobs (sidecar counterpart of > Cassandra analytics bulk write via S3), it is required to have the capability > to perform consistency check for the individual restore ranges and have a new > endpoint for the spark job to query the restore progress. > The consistency check should be responsive to cluster topology changes. For > example, if there is a new node joining the cluster, the write replica set of > the affected ranges are changed. The joining node should be able to discover > the restore ranges that it owns and restore the data. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRASC-132) Add restore job progress endpoint and consistency check on restore ranges
[ https://issues.apache.org/jira/browse/CASSANDRASC-132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CASSANDRASC-132: --- Labels: pull-request-available (was: ) > Add restore job progress endpoint and consistency check on restore ranges > - > > Key: CASSANDRASC-132 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-132 > Project: Sidecar for Apache Cassandra > Issue Type: New Feature > Components: Rest API >Reporter: Yifan Cai >Assignee: Yifan Cai >Priority: Normal > Labels: pull-request-available > > In order to support the sidecar-managed restore jobs (sidecar counterpart of > Cassandra analytics bulk write via S3), it is required to have the capability > to perform consistency check for the individual restore ranges and have a new > endpoint for the spark job to query the restore progress. > The consistency check should be responsive to cluster topology changes. For > example, if there is a new node joining the cluster, the write replica set of > the affected ranges are changed. The joining node should be able to discover > the restore ranges that it owns and restore the data. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRASC-132) Add restore job progress endpoint and consistency check on restore ranges
[ https://issues.apache.org/jira/browse/CASSANDRASC-132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yifan Cai updated CASSANDRASC-132: -- Change Category: Semantic Complexity: Normal Status: Open (was: Triage Needed) PR: https://github.com/apache/cassandra-sidecar/pull/123 CI: https://app.circleci.com/pipelines/github/yifan-c/cassandra-sidecar?branch=CASSANDRASC-132%2Ftrunk > Add restore job progress endpoint and consistency check on restore ranges > - > > Key: CASSANDRASC-132 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-132 > Project: Sidecar for Apache Cassandra > Issue Type: New Feature > Components: Rest API >Reporter: Yifan Cai >Assignee: Yifan Cai >Priority: Normal > Labels: pull-request-available > > In order to support the sidecar-managed restore jobs (sidecar counterpart of > Cassandra analytics bulk write via S3), it is required to have the capability > to perform consistency check for the individual restore ranges and have a new > endpoint for the spark job to query the restore progress. > The consistency check should be responsive to cluster topology changes. For > example, if there is a new node joining the cluster, the write replica set of > the affected ranges are changed. The joining node should be able to discover > the restore ranges that it owns and restore the data. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRASC-132) Add restore job progress endpoint and consistency check on restore ranges
Yifan Cai created CASSANDRASC-132: - Summary: Add restore job progress endpoint and consistency check on restore ranges Key: CASSANDRASC-132 URL: https://issues.apache.org/jira/browse/CASSANDRASC-132 Project: Sidecar for Apache Cassandra Issue Type: New Feature Components: Rest API Reporter: Yifan Cai Assignee: Yifan Cai In order to support the sidecar-managed restore jobs (sidecar counterpart of Cassandra analytics bulk write via S3), it is required to have the capability to perform consistency check for the individual restore ranges and have a new endpoint for the spark job to query the restore progress. The consistency check should be responsive to cluster topology changes. For example, if there is a new node joining the cluster, the write replica set of the affected ranges are changed. The joining node should be able to discover the restore ranges that it owns and restore the data. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19658) Test failure: replace_address_test.py::TestReplaceAddress::test_restart_failed_replace
[
https://issues.apache.org/jira/browse/CASSANDRA-19658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-19658:
-
Test and Documentation Plan: run CI
Status: Patch Available (was: Open)
> Test failure:
> replace_address_test.py::TestReplaceAddress::test_restart_failed_replace
> --
>
> Key: CASSANDRA-19658
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19658
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Membership
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0.x
>
>
> 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 3ms,
> removing from gossip'] not found in system.log:
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19658) Test failure: replace_address_test.py::TestReplaceAddress::test_restart_failed_replace
[
https://issues.apache.org/jira/browse/CASSANDRA-19658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17849089#comment-17849089
]
Brandon Williams commented on CASSANDRA-19658:
--
bq. Looks like fallout from CASSANDRA-15439
Indeed it was, patch
[here|https://github.com/driftx/cassandra-dtest/commit/b6a87433bfb37a00fe195fb838581864d66dee35]
to set the timeout to match the test.
||Branch||CI||
|[4.0|https://github.com/driftx/cassandra/tree/CASSANDRA-19658-4.0]|[repeats|https://app.circleci.com/pipelines/github/driftx/cassandra/1646/workflows/1d6dccad-7313-43f9-83a6-8fad2d592a38]|
|[4.1|https://github.com/driftx/cassandra/tree/CASSANDRA-19658-4.1]|[repeats|https://app.circleci.com/pipelines/github/driftx/cassandra/1647/workflows/944ecc10-0573-4c64-a180-db4006db30b1]|
|[5.0|https://github.com/driftx/cassandra/tree/CASSANDRA-19658-5.0]|[repeats|https://app.circleci.com/pipelines/github/driftx/cassandra/1648/workflows/2b5d5e3f-614a-4f02-b43c-b3efd345d2f1]|
|[trunk|https://github.com/driftx/cassandra/tree/CASSANDRA-19658-trunk]|[repeats|https://app.circleci.com/pipelines/github/driftx/cassandra/1649/workflows/01e57f68-f196-4986-b51c-2e90c4e1058a]|
> Test failure:
> replace_address_test.py::TestReplaceAddress::test_restart_failed_replace
> --
>
> Key: CASSANDRA-19658
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19658
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Membership
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0.x
>
>
> 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 3ms,
> removing from gossip'] not found in system.log:
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18120) Single slow node dramatically reduces cluster logged batch write throughput regardless of CL
[ https://issues.apache.org/jira/browse/CASSANDRA-18120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-18120: --- Change Category: Operability Complexity: Normal Component/s: Consistency/Coordination Fix Version/s: 4.0.x 4.1.x 5.0.x 5.x Reviewers: Michael Semb Wever Status: Open (was: Triage Needed) > Single slow node dramatically reduces cluster logged batch write throughput > regardless of CL > > > Key: CASSANDRA-18120 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18120 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Coordination >Reporter: Dan Sarisky >Assignee: Maxim Chanturiay >Priority: Normal > Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x > > > We issue writes to Cassandra as logged batches(RF=3, Consistency levels=TWO, > QUORUM, or LOCAL_QUORUM) > > On clusters of any size - a single extremely slow node causes a ~90% loss of > cluster-wide throughput using batched writes. We can replicate this in the > lab via CPU or disk throttling. I observe this in 3.11, 4.0, and 4.1. > > It appears the mechanism in play is: > Those logged batches are immediately written to two replica nodes and the > actual mutations aren't processed until those two nodes acknowledge the batch > statements. Those replica nodes are selected randomly from all nodes in the > local data center currently up in gossip. If a single node is slow, but > still thought to be up in gossip, this eventually causes every other node to > have all of its MutationStages to be waiting while the slow replica accepts > batch writes. > > The code in play appears to be: > See > [https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/locator/ReplicaPlans.java#L245]. > In the method filterBatchlogEndpoints() there is a > Collections.shuffle() to order the endpoints and a > FailureDetector.isEndpointAlive() to test if the endpoint is acceptable. > > This behavior causes Cassandra to move from a multi-node fault tolerant > system toa collection of single points of failure. > > We try to take administrator actions to kill off the extremely slow nodes, > but it would be great to have some notion of "what node is a bad choice" when > writing log batches to replica nodes. > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18120) Single slow node dramatically reduces cluster logged batch write throughput regardless of CL
[ https://issues.apache.org/jira/browse/CASSANDRA-18120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17849074#comment-17849074 ] Michael Semb Wever edited comment on CASSANDRA-18120 at 5/23/24 6:39 PM: - [~shunsaker], do you want to share the patch you're willing to upstream ? That patch would have had a lot of production exposure already, so it would be my preference. [~maximc], are you ok if we focus on Shayne's patch ? I know you've done a lot of work already, and it sucks when you've completed a patch and it was the first patch offered. Given your expertise now, and not letting it go to waste, it would be very valuable to have you as a reviewer (and tester). bq. Michael Semb Wever and Maxim Chanturiay provide strong arguments against Dynamic snitch. This is not related to logged batch writes, and today the dynamic snitch does nothing for it anyway. The advice to disable the dynamic snitch has been a long standing recommendation from The Last Pickle, aimed at competent Cassandra operators that have healthy and performant clusters, and solid enough monitoring and alerting in place to otherwise detect and deal with a slow node. The dynamic snitch comes with its own overhead, and on healthy performant clusters can't keep up, so offers very little value and hurts latencies. (Don't look past those caveats though!) If you have a problem with slow nodes, and don't have a way to deal with it, then the dynamic snitch is a good option, and adding the same ability to the batchlog makes sense. was (Author: michaelsembwever): [~shunsaker], do you want to share the patch you're willing to upstream ? That patch would have had a lot of production exposure already, so it would be my preference. [~maximc], are you ok if we focus on Shayne's patch ? I know you've done a lot of work already, and it sucks when you've completed a patch and it was the first patch offered. Given your expertise now, and not letting it go to waste, it would be very valuable to have you as a reviewer (and tester). bq. Michael Semb Wever and Maxim Chanturiay provide strong arguments against Dynamic snitch. This is not related to logged batch writes, and today the dynamic snitch does nothing for it anyway. The advice to disable the dynamic snitch has been a long standing recommendation from The Last Pickle, aimed at competent Cassandra operators that have healthy and performant clusters, and solid enough monitoring and alerting in place to otherwise detect and deal with a slow node. The dynamic snitch comes with its own overhead, and on healthy performant clusters can't keep up, so offers very little value. (Don't look past those caveats though!) If you have a problem with slow nodes, and don't have a way to deal with it, then the dynamic snitch is a good option, and adding the same ability to the batchlog makes sense. > Single slow node dramatically reduces cluster logged batch write throughput > regardless of CL > > > Key: CASSANDRA-18120 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18120 > Project: Cassandra > Issue Type: Improvement >Reporter: Dan Sarisky >Assignee: Maxim Chanturiay >Priority: Normal > > We issue writes to Cassandra as logged batches(RF=3, Consistency levels=TWO, > QUORUM, or LOCAL_QUORUM) > > On clusters of any size - a single extremely slow node causes a ~90% loss of > cluster-wide throughput using batched writes. We can replicate this in the > lab via CPU or disk throttling. I observe this in 3.11, 4.0, and 4.1. > > It appears the mechanism in play is: > Those logged batches are immediately written to two replica nodes and the > actual mutations aren't processed until those two nodes acknowledge the batch > statements. Those replica nodes are selected randomly from all nodes in the > local data center currently up in gossip. If a single node is slow, but > still thought to be up in gossip, this eventually causes every other node to > have all of its MutationStages to be waiting while the slow replica accepts > batch writes. > > The code in play appears to be: > See > [https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/locator/ReplicaPlans.java#L245]. > In the method filterBatchlogEndpoints() there is a > Collections.shuffle() to order the endpoints and a > FailureDetector.isEndpointAlive() to test if the endpoint is acceptable. > > This behavior causes Cassandra to move from a multi-node fault tolerant > system toa collection of single points of failure. > > We try to take administrator actions t
[jira] [Comment Edited] (CASSANDRA-18120) Single slow node dramatically reduces cluster logged batch write throughput regardless of CL
[ https://issues.apache.org/jira/browse/CASSANDRA-18120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17849074#comment-17849074 ] Michael Semb Wever edited comment on CASSANDRA-18120 at 5/23/24 6:38 PM: - [~shunsaker], do you want to share the patch you're willing to upstream ? This patch has had a lot of production exposure already, so it has my preference. [~maximc], are you ok if we focus on Shayne's patch ? I know you've done a lot of work already, and it sucks when you've completed a patch and it was the first patch offered. Given your expertise now, and not letting it go to waste, it would be very valuable to have you as a reviewer (and tester). bq. Michael Semb Wever and Maxim Chanturiay provide strong arguments against Dynamic snitch. This is not related to logged batch writes, and today the dynamic snitch does nothing for it anyway. The advice to disable the dynamic snitch has been a long standing recommendation from The Last Pickle, aimed at competent Cassandra operators that have healthy and performant clusters, and solid enough monitoring and alerting in place to otherwise detect and deal with a slow node. The dynamic snitch comes with its own overhead, and on healthy performant clusters can't keep up, so offers very little value. (Don't look past those caveats though!) If you have a problem with slow nodes, and don't have a way to deal with it, then the dynamic snitch is a good option, and adding the same ability to the batchlog makes sense. was (Author: michaelsembwever): [~shunsaker], do you want to share the patch you're willing to upstream ? This patch has had a lot of production exposure already, so it has my preference. [~maximc], are you ok if we focus on Shayne's patch ? I know you've done a lot of work already, and it sucks when you've completed a patch and it was the first patch offered. Given your expertise now, and not letting it go to waste, it would be very valuable to have you as a reviewer (and tester). bq. Michael Semb Wever and Maxim Chanturiay provide strong arguments against Dynamic snitch. This is not related to logged batch writes, and today the dynamic snitch does nothing for it anyway. The advice to disable the dynamic snitch has been a long standing recommendation from The Last Pickle, aimed at competent Cassandra operators that have healthy and performant clusters, and solid enough monitoring and alerting in place to otherwise detect and deal with a slow node. The dynamic snitch comes with its own overhead, and on healthy performant clusters can't keep up, so offers very little value. (Don't look past those caveats though!) If you have a problem with slow nodes, and don't have a way to deal with it, then the dynamic snitch is a good option, and adding the same ability to the batchlog adds to that. > Single slow node dramatically reduces cluster logged batch write throughput > regardless of CL > > > Key: CASSANDRA-18120 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18120 > Project: Cassandra > Issue Type: Improvement >Reporter: Dan Sarisky >Assignee: Maxim Chanturiay >Priority: Normal > > We issue writes to Cassandra as logged batches(RF=3, Consistency levels=TWO, > QUORUM, or LOCAL_QUORUM) > > On clusters of any size - a single extremely slow node causes a ~90% loss of > cluster-wide throughput using batched writes. We can replicate this in the > lab via CPU or disk throttling. I observe this in 3.11, 4.0, and 4.1. > > It appears the mechanism in play is: > Those logged batches are immediately written to two replica nodes and the > actual mutations aren't processed until those two nodes acknowledge the batch > statements. Those replica nodes are selected randomly from all nodes in the > local data center currently up in gossip. If a single node is slow, but > still thought to be up in gossip, this eventually causes every other node to > have all of its MutationStages to be waiting while the slow replica accepts > batch writes. > > The code in play appears to be: > See > [https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/locator/ReplicaPlans.java#L245]. > In the method filterBatchlogEndpoints() there is a > Collections.shuffle() to order the endpoints and a > FailureDetector.isEndpointAlive() to test if the endpoint is acceptable. > > This behavior causes Cassandra to move from a multi-node fault tolerant > system toa collection of single points of failure. > > We try to take administrator actions to kill off the extremely slow nodes, &g
[jira] [Comment Edited] (CASSANDRA-18120) Single slow node dramatically reduces cluster logged batch write throughput regardless of CL
[ https://issues.apache.org/jira/browse/CASSANDRA-18120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17849074#comment-17849074 ] Michael Semb Wever edited comment on CASSANDRA-18120 at 5/23/24 6:38 PM: - [~shunsaker], do you want to share the patch you're willing to upstream ? That patch would have had a lot of production exposure already, so it would be my preference. [~maximc], are you ok if we focus on Shayne's patch ? I know you've done a lot of work already, and it sucks when you've completed a patch and it was the first patch offered. Given your expertise now, and not letting it go to waste, it would be very valuable to have you as a reviewer (and tester). bq. Michael Semb Wever and Maxim Chanturiay provide strong arguments against Dynamic snitch. This is not related to logged batch writes, and today the dynamic snitch does nothing for it anyway. The advice to disable the dynamic snitch has been a long standing recommendation from The Last Pickle, aimed at competent Cassandra operators that have healthy and performant clusters, and solid enough monitoring and alerting in place to otherwise detect and deal with a slow node. The dynamic snitch comes with its own overhead, and on healthy performant clusters can't keep up, so offers very little value. (Don't look past those caveats though!) If you have a problem with slow nodes, and don't have a way to deal with it, then the dynamic snitch is a good option, and adding the same ability to the batchlog makes sense. was (Author: michaelsembwever): [~shunsaker], do you want to share the patch you're willing to upstream ? This patch has had a lot of production exposure already, so it has my preference. [~maximc], are you ok if we focus on Shayne's patch ? I know you've done a lot of work already, and it sucks when you've completed a patch and it was the first patch offered. Given your expertise now, and not letting it go to waste, it would be very valuable to have you as a reviewer (and tester). bq. Michael Semb Wever and Maxim Chanturiay provide strong arguments against Dynamic snitch. This is not related to logged batch writes, and today the dynamic snitch does nothing for it anyway. The advice to disable the dynamic snitch has been a long standing recommendation from The Last Pickle, aimed at competent Cassandra operators that have healthy and performant clusters, and solid enough monitoring and alerting in place to otherwise detect and deal with a slow node. The dynamic snitch comes with its own overhead, and on healthy performant clusters can't keep up, so offers very little value. (Don't look past those caveats though!) If you have a problem with slow nodes, and don't have a way to deal with it, then the dynamic snitch is a good option, and adding the same ability to the batchlog makes sense. > Single slow node dramatically reduces cluster logged batch write throughput > regardless of CL > > > Key: CASSANDRA-18120 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18120 > Project: Cassandra > Issue Type: Improvement >Reporter: Dan Sarisky >Assignee: Maxim Chanturiay >Priority: Normal > > We issue writes to Cassandra as logged batches(RF=3, Consistency levels=TWO, > QUORUM, or LOCAL_QUORUM) > > On clusters of any size - a single extremely slow node causes a ~90% loss of > cluster-wide throughput using batched writes. We can replicate this in the > lab via CPU or disk throttling. I observe this in 3.11, 4.0, and 4.1. > > It appears the mechanism in play is: > Those logged batches are immediately written to two replica nodes and the > actual mutations aren't processed until those two nodes acknowledge the batch > statements. Those replica nodes are selected randomly from all nodes in the > local data center currently up in gossip. If a single node is slow, but > still thought to be up in gossip, this eventually causes every other node to > have all of its MutationStages to be waiting while the slow replica accepts > batch writes. > > The code in play appears to be: > See > [https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/locator/ReplicaPlans.java#L245]. > In the method filterBatchlogEndpoints() there is a > Collections.shuffle() to order the endpoints and a > FailureDetector.isEndpointAlive() to test if the endpoint is acceptable. > > This behavior causes Cassandra to move from a multi-node fault tolerant > system toa collection of single points of failure. > > We try to take administrator actions to kill off the extremely slow nodes, &g
[jira] [Updated] (CASSANDRA-18120) Single slow node dramatically reduces cluster logged batch write throughput regardless of CL
[ https://issues.apache.org/jira/browse/CASSANDRA-18120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-18120: --- Summary: Single slow node dramatically reduces cluster logged batch write throughput regardless of CL (was: Single slow node dramatically reduces cluster write throughput regardless of CL) > Single slow node dramatically reduces cluster logged batch write throughput > regardless of CL > > > Key: CASSANDRA-18120 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18120 > Project: Cassandra > Issue Type: Improvement >Reporter: Dan Sarisky >Assignee: Maxim Chanturiay >Priority: Normal > > We issue writes to Cassandra as logged batches(RF=3, Consistency levels=TWO, > QUORUM, or LOCAL_QUORUM) > > On clusters of any size - a single extremely slow node causes a ~90% loss of > cluster-wide throughput using batched writes. We can replicate this in the > lab via CPU or disk throttling. I observe this in 3.11, 4.0, and 4.1. > > It appears the mechanism in play is: > Those logged batches are immediately written to two replica nodes and the > actual mutations aren't processed until those two nodes acknowledge the batch > statements. Those replica nodes are selected randomly from all nodes in the > local data center currently up in gossip. If a single node is slow, but > still thought to be up in gossip, this eventually causes every other node to > have all of its MutationStages to be waiting while the slow replica accepts > batch writes. > > The code in play appears to be: > See > [https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/locator/ReplicaPlans.java#L245]. > In the method filterBatchlogEndpoints() there is a > Collections.shuffle() to order the endpoints and a > FailureDetector.isEndpointAlive() to test if the endpoint is acceptable. > > This behavior causes Cassandra to move from a multi-node fault tolerant > system toa collection of single points of failure. > > We try to take administrator actions to kill off the extremely slow nodes, > but it would be great to have some notion of "what node is a bad choice" when > writing log batches to replica nodes. > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18120) Single slow node dramatically reduces cluster write throughput regardless of CL
[ https://issues.apache.org/jira/browse/CASSANDRA-18120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17849074#comment-17849074 ] Michael Semb Wever commented on CASSANDRA-18120: [~shunsaker], do you want to share the patch you're willing to upstream ? This patch has had a lot of production exposure already, so it has my preference. [~maximc], are you ok if we focus on Shayne's patch ? I know you've done a lot of work already, and it sucks when you've completed a patch and it was the first patch offered. Given your expertise now, and not letting it go to waste, it would be very valuable to have you as a reviewer (and tester). bq. Michael Semb Wever and Maxim Chanturiay provide strong arguments against Dynamic snitch. This is not related to logged batch writes, and today the dynamic snitch does nothing for it anyway. The advice to disable the dynamic snitch has been a long standing recommendation from The Last Pickle, aimed at competent Cassandra operators that have healthy and performant clusters, and solid enough monitoring and alerting in place to otherwise detect and deal with a slow node. The dynamic snitch comes with its own overhead, and on healthy performant clusters can't keep up, so offers very little value. (Don't look past those caveats though!) If you have a problem with slow nodes, and don't have a way to deal with it, then the dynamic snitch is a good option, and adding the same ability to the batchlog adds to that. > Single slow node dramatically reduces cluster write throughput regardless of > CL > --- > > Key: CASSANDRA-18120 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18120 > Project: Cassandra > Issue Type: Improvement >Reporter: Dan Sarisky >Assignee: Maxim Chanturiay >Priority: Normal > > We issue writes to Cassandra as logged batches(RF=3, Consistency levels=TWO, > QUORUM, or LOCAL_QUORUM) > > On clusters of any size - a single extremely slow node causes a ~90% loss of > cluster-wide throughput using batched writes. We can replicate this in the > lab via CPU or disk throttling. I observe this in 3.11, 4.0, and 4.1. > > It appears the mechanism in play is: > Those logged batches are immediately written to two replica nodes and the > actual mutations aren't processed until those two nodes acknowledge the batch > statements. Those replica nodes are selected randomly from all nodes in the > local data center currently up in gossip. If a single node is slow, but > still thought to be up in gossip, this eventually causes every other node to > have all of its MutationStages to be waiting while the slow replica accepts > batch writes. > > The code in play appears to be: > See > [https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/locator/ReplicaPlans.java#L245]. > In the method filterBatchlogEndpoints() there is a > Collections.shuffle() to order the endpoints and a > FailureDetector.isEndpointAlive() to test if the endpoint is acceptable. > > This behavior causes Cassandra to move from a multi-node fault tolerant > system toa collection of single points of failure. > > We try to take administrator actions to kill off the extremely slow nodes, > but it would be great to have some notion of "what node is a bad choice" when > writing log batches to replica nodes. > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-12937) Default setting (yaml) for SSTable compression
[
https://issues.apache.org/jira/browse/CASSANDRA-12937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-12937:
--
Status: In Progress (was: Patch Available)
> Default setting (yaml) for SSTable compression
> --
>
> Key: CASSANDRA-12937
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12937
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Michael Semb Wever
>Assignee: Stefan Miklosovic
>Priority: Low
> Labels: AdventCalendar2021
> Fix For: 5.x
>
> Time Spent: 8h 20m
> Remaining Estimate: 0h
>
> In many situations the choice of compression for sstables is more relevant to
> the disks attached than to the schema and data.
> This issue is to add to cassandra.yaml a default value for sstable
> compression that new tables will inherit (instead of the defaults found in
> {{CompressionParams.DEFAULT}}.
> Examples where this can be relevant are filesystems that do on-the-fly
> compression (btrfs, zfs) or specific disk configurations or even specific C*
> versions (see CASSANDRA-10995 ).
> +Additional information for newcomers+
> Some new fields need to be added to {{cassandra.yaml}} to allow specifying
> the field required for defining the default compression parameters. In
> {{DatabaseDescriptor}} a new {{CompressionParams}} field should be added for
> the default compression. This field should be initialized in
> {{DatabaseDescriptor.applySimpleConfig()}}. At the different places where
> {{CompressionParams.DEFAULT}} was used the code should call
> {{DatabaseDescriptor#getDefaultCompressionParams}} that should return some
> copy of configured {{CompressionParams}}.
> Some unit test using {{OverrideConfigurationLoader}} should be used to test
> that the table schema use the new default when a new table is created (see
> CreateTest for some example).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-19651) idealCLWriteLatency metric reports the worst response time instead of the time when ideal CL is satisfied
[
https://issues.apache.org/jira/browse/CASSANDRA-19651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17849025#comment-17849025
]
Dmitry Konstantinov edited comment on CASSANDRA-19651 at 5/23/24 4:05 PM:
--
I have found one more place in the current logic to fix: currently we consider
that requestedCLAchieved = true if
org.apache.cassandra.service.AbstractWriteResponseHandler#signal is invoked but
this method is invoked not only when we have enough successful responses to
treat the operation as complete, there is also signal() invocation from
org.apache.cassandra.service.AbstractWriteResponseHandler#onFailure when we
have got too many failures and can say that there is no chance to get enough
successful responses.
So, a condition: if (blockFor() + failures <= candidateReplicaCount()) should
be added into the signal() logic for ideal CL logic.
I am going to share an updated patch version.
was (Author: dnk):
I have found one more place in the current logic to fix: currently we consider
that requestedCLAchieved = true if
org.apache.cassandra.service.AbstractWriteResponseHandler#signal is invoked but
this method is invoked not only when we have enough successful responses to
treat the operation as complete, there is also signal() invocation from
org.apache.cassandra.service.AbstractWriteResponseHandler#onFailure when we
have got too many failures and can say that there is no change to get enough
successful responses.
So, a condition: if (blockFor() + failures <= candidateReplicaCount()) should
be added into the signal() logic for ideal CL logic.
I am going to share an updated patch version.
> idealCLWriteLatency metric reports the worst response time instead of the
> time when ideal CL is satisfied
> -
>
> Key: CASSANDRA-19651
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19651
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Observability
>Reporter: Dmitry Konstantinov
>Assignee: Dmitry Konstantinov
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
> Attachments: 19651-4.1.patch
>
>
> org.apache.cassandra.service.AbstractWriteResponseHandler:
> {code:java}
> private final void decrementResponseOrExpired()
> {
> int decrementedValue = responsesAndExpirations.decrementAndGet();
> if (decrementedValue == 0)
> {
> // The condition being signaled is a valid proxy for the CL being
> achieved
> // Only mark it as failed if the requested CL was achieved.
> if (!condition.isSignalled() && requestedCLAchieved)
> {
> replicaPlan.keyspace().metric.writeFailedIdealCL.inc();
> }
> else
> {
>
> replicaPlan.keyspace().metric.idealCLWriteLatency.addNano(nanoTime() -
> queryStartNanoTime);
> }
> }
> } {code}
> Actual result: responsesAndExpirations is a total number of replicas across
> all DCs which does not depend on the ideal CL, so the metric value for
> replicaPlan.keyspace().metric.idealCLWriteLatency is updated when we get the
> latest response/timeout for all replicas.
> Expected result: replicaPlan.keyspace().metric.idealCLWriteLatency is updated
> when we get enough responses from replicas according to the ideal CL.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19651) idealCLWriteLatency metric reports the worst response time instead of the time when ideal CL is satisfied
[
https://issues.apache.org/jira/browse/CASSANDRA-19651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17849025#comment-17849025
]
Dmitry Konstantinov commented on CASSANDRA-19651:
-
I have found one more place in the current logic to fix: currently we consider
that requestedCLAchieved = true if
org.apache.cassandra.service.AbstractWriteResponseHandler#signal is invoked but
this method is invoked not only when we have enough successful responses to
treat the operation as complete, there is also signal() invocation from
org.apache.cassandra.service.AbstractWriteResponseHandler#onFailure when we
have got too many failures and can say that there is no change to get enough
successful responses.
So, a condition: if (blockFor() + failures <= candidateReplicaCount()) should
be added into the signal() logic for ideal CL logic.
I am going to share an updated patch version.
> idealCLWriteLatency metric reports the worst response time instead of the
> time when ideal CL is satisfied
> -
>
> Key: CASSANDRA-19651
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19651
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Observability
>Reporter: Dmitry Konstantinov
>Assignee: Dmitry Konstantinov
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
> Attachments: 19651-4.1.patch
>
>
> org.apache.cassandra.service.AbstractWriteResponseHandler:
> {code:java}
> private final void decrementResponseOrExpired()
> {
> int decrementedValue = responsesAndExpirations.decrementAndGet();
> if (decrementedValue == 0)
> {
> // The condition being signaled is a valid proxy for the CL being
> achieved
> // Only mark it as failed if the requested CL was achieved.
> if (!condition.isSignalled() && requestedCLAchieved)
> {
> replicaPlan.keyspace().metric.writeFailedIdealCL.inc();
> }
> else
> {
>
> replicaPlan.keyspace().metric.idealCLWriteLatency.addNano(nanoTime() -
> queryStartNanoTime);
> }
> }
> } {code}
> Actual result: responsesAndExpirations is a total number of replicas across
> all DCs which does not depend on the ideal CL, so the metric value for
> replicaPlan.keyspace().metric.idealCLWriteLatency is updated when we get the
> latest response/timeout for all replicas.
> Expected result: replicaPlan.keyspace().metric.idealCLWriteLatency is updated
> when we get enough responses from replicas according to the ideal CL.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19651) idealCLWriteLatency metric reports the worst response time instead of the time when ideal CL is satisfied
[
https://issues.apache.org/jira/browse/CASSANDRA-19651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Konstantinov updated CASSANDRA-19651:
Status: In Progress (was: Patch Available)
> idealCLWriteLatency metric reports the worst response time instead of the
> time when ideal CL is satisfied
> -
>
> Key: CASSANDRA-19651
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19651
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Observability
>Reporter: Dmitry Konstantinov
>Assignee: Dmitry Konstantinov
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
> Attachments: 19651-4.1.patch
>
>
> org.apache.cassandra.service.AbstractWriteResponseHandler:
> {code:java}
> private final void decrementResponseOrExpired()
> {
> int decrementedValue = responsesAndExpirations.decrementAndGet();
> if (decrementedValue == 0)
> {
> // The condition being signaled is a valid proxy for the CL being
> achieved
> // Only mark it as failed if the requested CL was achieved.
> if (!condition.isSignalled() && requestedCLAchieved)
> {
> replicaPlan.keyspace().metric.writeFailedIdealCL.inc();
> }
> else
> {
>
> replicaPlan.keyspace().metric.idealCLWriteLatency.addNano(nanoTime() -
> queryStartNanoTime);
> }
> }
> } {code}
> Actual result: responsesAndExpirations is a total number of replicas across
> all DCs which does not depend on the ideal CL, so the metric value for
> replicaPlan.keyspace().metric.idealCLWriteLatency is updated when we get the
> latest response/timeout for all replicas.
> Expected result: replicaPlan.keyspace().metric.idealCLWriteLatency is updated
> when we get enough responses from replicas according to the ideal CL.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-12937) Default setting (yaml) for SSTable compression
[
https://issues.apache.org/jira/browse/CASSANDRA-12937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17849018#comment-17849018
]
Stefan Miklosovic commented on CASSANDRA-12937:
---
I consolidated the links for PR's as it was getting confusing.
Claude's PR: [https://github.com/apache/cassandra/pull/3168]
mine which is same as his but squashed:
[https://github.com/apache/cassandra/pull/3330]
I rebased mine against current trunk where CASSANDRA-19592 was merged and I see
that the problematic test (SSTableCompressionTest#configChangeIsolation) passes
now which is indeed good news.
I will run a CI to see if something else is broken.
btw [~jlewandowski] mentioned me privately that it would be nice if we had the
configuration like this:
{code}
sstable:
selected_format: big
default_compression: lz4 check this
format:
big:
option1: abc
option2: 123
bti:
option3: xyz
option4: 999
compression: check this
lz4:
enabled: true
chunk_length: 16KiB
max_compressed_length: 16KiB
snappy:
enabled: true
chunk_length: 16KiB
max_compressed_length: 16KiB
deflate:
enabled: false
chunk_length: 16KiB
max_compressed_length: 16KiB
{code}
instead of what we have now:
{code}
sstable_compression:
- class_name: lz4
parameters:
- enabled: "true"
chunk_length: 16KiB
max_compressed_length: 16KiB
{code}
The reasoning behind that is that we are just enriching existing configuration
section, we are not inventing anything new. Plus it would be cool to have
predefined compression options so if we just use lz4 in CQL then all parameters
will be automatically taken into consideration as well. If we provide some
parameters on CQL, these will be merged into what is in cassandra.yaml.
[~claude] I can take a look into this.
> Default setting (yaml) for SSTable compression
> --
>
> Key: CASSANDRA-12937
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12937
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Michael Semb Wever
>Assignee: Stefan Miklosovic
>Priority: Low
> Labels: AdventCalendar2021
> Fix For: 5.x
>
> Time Spent: 8h 20m
> Remaining Estimate: 0h
>
> In many situations the choice of compression for sstables is more relevant to
> the disks attached than to the schema and data.
> This issue is to add to cassandra.yaml a default value for sstable
> compression that new tables will inherit (instead of the defaults found in
> {{CompressionParams.DEFAULT}}.
> Examples where this can be relevant are filesystems that do on-the-fly
> compression (btrfs, zfs) or specific disk configurations or even specific C*
> versions (see CASSANDRA-10995 ).
> +Additional information for newcomers+
> Some new fields need to be added to {{cassandra.yaml}} to allow specifying
> the field required for defining the default compression parameters. In
> {{DatabaseDescriptor}} a new {{CompressionParams}} field should be added for
> the default compression. This field should be initialized in
> {{DatabaseDescriptor.applySimpleConfig()}}. At the different places where
> {{CompressionParams.DEFAULT}} was used the code should call
> {{DatabaseDescriptor#getDefaultCompressionParams}} that should return some
> copy of configured {{CompressionParams}}.
> Some unit test using {{OverrideConfigurationLoader}} should be used to test
> that the table schema use the new default when a new table is created (see
> CreateTest for some example).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19660) Support for netty-tcnative 2.0.62+
[ https://issues.apache.org/jira/browse/CASSANDRA-19660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17849002#comment-17849002 ] Brandon Williams commented on CASSANDRA-19660: -- 2.0.62 for trunk sounds reasonable to me. > Support for netty-tcnative 2.0.62+ > -- > > Key: CASSANDRA-19660 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19660 > Project: Cassandra > Issue Type: Improvement >Reporter: Zbyszek Z >Priority: Normal > > Hello, > Are there plans to support netty-tcnative in version 2.0.62? Current version > 2.0.36 does not work with openssl3.x. Motivation is that openssl 3.0.9+ is > FIPS certified. > Currently i am able to replace library default boringSSL implementation with > openssl by recompiling netty-tcnative but cassandra fails to load 2.0.62 > regardless if it is compiled with 1.1.1 or 3.0. > Or is there other way to implement openssl3.x ? > Thank you -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19660) Support for netty-tcnative 2.0.62+
[ https://issues.apache.org/jira/browse/CASSANDRA-19660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17848999#comment-17848999 ] Zbyszek Z commented on CASSANDRA-19660: --- Oh, thats bummer as this is only 1 version up. On the github there is wrong version number suggesting that .61 added openssl version but it was infact in .62. No way to reconsider ? > Support for netty-tcnative 2.0.62+ > -- > > Key: CASSANDRA-19660 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19660 > Project: Cassandra > Issue Type: Improvement >Reporter: Zbyszek Z >Priority: Normal > > Hello, > Are there plans to support netty-tcnative in version 2.0.62? Current version > 2.0.36 does not work with openssl3.x. Motivation is that openssl 3.0.9+ is > FIPS certified. > Currently i am able to replace library default boringSSL implementation with > openssl by recompiling netty-tcnative but cassandra fails to load 2.0.62 > regardless if it is compiled with 1.1.1 or 3.0. > Or is there other way to implement openssl3.x ? > Thank you -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19592) Expand CREATE TABLE CQL on a coordinating node before submitting to CMS
[ https://issues.apache.org/jira/browse/CASSANDRA-19592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sam Tunnicliffe updated CASSANDRA-19592: Reviewers: Sam Tunnicliffe, Stefan Miklosovic (was: Sam Tunnicliffe) > Expand CREATE TABLE CQL on a coordinating node before submitting to CMS > --- > > Key: CASSANDRA-19592 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19592 > Project: Cassandra > Issue Type: Bug > Components: Cluster/Schema >Reporter: Alex Petrov >Assignee: Alex Petrov >Priority: Normal > Fix For: 5.1 > > Attachments: ci_summary-1.html, ci_summary.html > > > This is done to unblock CASSANDRA-12937 and allow preserving defaults with > which the table was created between node bounces and between nodes with > different configurations. For now, we are preserving 5.0 behaviour. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19592) Expand CREATE TABLE CQL on a coordinating node before submitting to CMS
[ https://issues.apache.org/jira/browse/CASSANDRA-19592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sam Tunnicliffe updated CASSANDRA-19592: Fix Version/s: 5.1 Since Version: NA Source Control Link: https://github.com/apache/cassandra/commit/7fe30fc313ac35b1156f5a37d2069e29cded710b Resolution: Fixed Status: Resolved (was: Ready to Commit) committed, thanks. > Expand CREATE TABLE CQL on a coordinating node before submitting to CMS > --- > > Key: CASSANDRA-19592 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19592 > Project: Cassandra > Issue Type: Bug > Components: Cluster/Schema >Reporter: Alex Petrov >Assignee: Alex Petrov >Priority: Normal > Fix For: 5.1 > > Attachments: ci_summary-1.html, ci_summary.html > > > This is done to unblock CASSANDRA-12937 and allow preserving defaults with > which the table was created between node bounces and between nodes with > different configurations. For now, we are preserving 5.0 behaviour. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19592) Expand CREATE TABLE CQL on a coordinating node before submitting to CMS
[ https://issues.apache.org/jira/browse/CASSANDRA-19592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sam Tunnicliffe updated CASSANDRA-19592: Status: Ready to Commit (was: Review In Progress) > Expand CREATE TABLE CQL on a coordinating node before submitting to CMS > --- > > Key: CASSANDRA-19592 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19592 > Project: Cassandra > Issue Type: Bug > Components: Cluster/Schema >Reporter: Alex Petrov >Assignee: Alex Petrov >Priority: Normal > Attachments: ci_summary-1.html, ci_summary.html > > > This is done to unblock CASSANDRA-12937 and allow preserving defaults with > which the table was created between node bounces and between nodes with > different configurations. For now, we are preserving 5.0 behaviour. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19592) Expand CREATE TABLE CQL on a coordinating node before submitting to CMS
[
https://issues.apache.org/jira/browse/CASSANDRA-19592?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17848984#comment-17848984
]
Sam Tunnicliffe commented on CASSANDRA-19592:
-
{quote}Does anything else need to be done except merging?
{quote}
No, I think it just fell between Alex & me. I'll get it rebased & merged.
> Expand CREATE TABLE CQL on a coordinating node before submitting to CMS
> ---
>
> Key: CASSANDRA-19592
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19592
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Schema
>Reporter: Alex Petrov
>Assignee: Alex Petrov
>Priority: Normal
> Attachments: ci_summary-1.html, ci_summary.html
>
>
> This is done to unblock CASSANDRA-12937 and allow preserving defaults with
> which the table was created between node bounces and between nodes with
> different configurations. For now, we are preserving 5.0 behaviour.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19660) Support for netty-tcnative 2.0.62+
[ https://issues.apache.org/jira/browse/CASSANDRA-19660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17848982#comment-17848982 ] Brandon Williams commented on CASSANDRA-19660: -- Trunk is already at 2.0.61: https://github.com/apache/cassandra/blob/trunk/.build/parent-pom-template.xml#L802 We won't be upgrading libs in released majors (including 5.0 at this point since it is so close.) > Support for netty-tcnative 2.0.62+ > -- > > Key: CASSANDRA-19660 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19660 > Project: Cassandra > Issue Type: Improvement >Reporter: Zbyszek Z >Priority: Normal > > Hello, > Are there plans to support netty-tcnative in version 2.0.62? Current version > 2.0.36 does not work with openssl3.x. Motivation is that openssl 3.0.9+ is > FIPS certified. > Currently i am able to replace library default boringSSL implementation with > openssl by recompiling netty-tcnative but cassandra fails to load 2.0.62 > regardless if it is compiled with 1.1.1 or 3.0. > Or is there other way to implement openssl3.x ? > Thank you -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17667) Text value containing "/*" interpreted as multiline comment in cqlsh
[
https://issues.apache.org/jira/browse/CASSANDRA-17667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brad Schoening updated CASSANDRA-17667:
---
Status: Patch Available (was: In Progress)
> Text value containing "/*" interpreted as multiline comment in cqlsh
>
>
> Key: CASSANDRA-17667
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17667
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: ANOOP THOMAS
>Assignee: Brad Schoening
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x
>
>
> I use CQLSH command line utility to load some DDLs. The version of utility I
> use is this:
> {noformat}
> [cqlsh 6.0.0 | Cassandra 4.0.0.47 | CQL spec 3.4.5 | Native protocol
> v5]{noformat}
> Command that loads DDL.cql:
> {noformat}
> cqlsh -u username -p password cassandra.example.com 65503 --ssl -f DDL.cql
> {noformat}
> I have a line in CQL script that breaks the syntax.
> {noformat}
> INSERT into tablename (key,columnname1,columnname2) VALUES
> ('keyName','value1','/value2/*/value3');{noformat}
> {{/*}} here is interpreted as start of multi-line comment. It used to work on
> older versions of cqlsh. The error I see looks like this:
> {noformat}
> SyntaxException: line 4:2 mismatched input 'Update' expecting ')'
> (...,'value1','/value2INSERT into tablename(INSERT into tablename
> (key,columnname1,columnname2)) VALUES ('[Update]-...) SyntaxException: line
> 1:0 no viable alternative at input '(' ([(]...)
> {noformat}
> Same behavior while running in interactive mode too. {{/*}} inside a CQL
> statement should not be interpreted as start of multi-line comment.
> With schema:
> {code:java}
> CREATE TABLE tablename ( key text primary key, columnname1 text, columnname2
> text);{code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19592) Expand CREATE TABLE CQL on a coordinating node before submitting to CMS
[ https://issues.apache.org/jira/browse/CASSANDRA-19592?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17848969#comment-17848969 ] Stefan Miklosovic commented on CASSANDRA-19592: --- Does anything else need to be done except merging? This would unblock CASSANDRA-12937 as you are for sure aware of. > Expand CREATE TABLE CQL on a coordinating node before submitting to CMS > --- > > Key: CASSANDRA-19592 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19592 > Project: Cassandra > Issue Type: Bug > Components: Cluster/Schema >Reporter: Alex Petrov >Assignee: Alex Petrov >Priority: Normal > Attachments: ci_summary-1.html, ci_summary.html > > > This is done to unblock CASSANDRA-12937 and allow preserving defaults with > which the table was created between node bounces and between nodes with > different configurations. For now, we are preserving 5.0 behaviour. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19450) Hygiene updates for warnings and pytests
[ https://issues.apache.org/jira/browse/CASSANDRA-19450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brad Schoening updated CASSANDRA-19450: --- Description: * -Update 'Warning' message to write to stderr- * -Replace TimeoutError Exception with builtin (since Python 3.3)- * -Remove re.pattern_type (removed since Python 3.7)- * Fix mutable arg [] in read_until() * Remove redirect of stderr to stdout in pytest fixture with tty=false; Deprecation warnings can otherwise fail unit tests when stdout & stderr output is combined. * Fix several pycodestyle issues was: * Update 'Warning' message to write to stderr * -Replace TimeoutError Exception with builtin (since Python 3.3)- * -Remove re.pattern_type (removed since Python 3.7)- * Fix mutable arg [] in read_until() * Remove redirect of stderr to stdout in pytest fixture with tty=false; Deprecation warnings can otherwise fail unit tests when stdout & stderr output is combined. * Fix several pycodestyle issues > Hygiene updates for warnings and pytests > > > Key: CASSANDRA-19450 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19450 > Project: Cassandra > Issue Type: Improvement > Components: CQL/Interpreter >Reporter: Brad Schoening >Assignee: Brad Schoening >Priority: Low > Fix For: 5.x > > > > * -Update 'Warning' message to write to stderr- > * -Replace TimeoutError Exception with builtin (since Python 3.3)- > * -Remove re.pattern_type (removed since Python 3.7)- > * Fix mutable arg [] in read_until() > * Remove redirect of stderr to stdout in pytest fixture with tty=false; > Deprecation warnings can otherwise fail unit tests when stdout & stderr > output is combined. > * Fix several pycodestyle issues -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-19660) Support for netty-tcnative 2.0.62+
Zbyszek Z created CASSANDRA-19660: - Summary: Support for netty-tcnative 2.0.62+ Key: CASSANDRA-19660 URL: https://issues.apache.org/jira/browse/CASSANDRA-19660 Project: Cassandra Issue Type: Improvement Reporter: Zbyszek Z Hello, Are there plans to support netty-tcnative in version 2.0.62? Current version 2.0.36 does not work with openssl3.x. Motivation is that openssl 3.0.9+ is FIPS certified. Currently i am able to replace library default boringSSL implementation with openssl by recompiling netty-tcnative but cassandra fails to load 2.0.62 regardless if it is compiled with 1.1.1 or 3.0. Or is there other way to implement openssl3.x ? Thank you -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19632) wrap tracing logs in isTraceEnabled across the codebase
[ https://issues.apache.org/jira/browse/CASSANDRA-19632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-19632: -- Status: Needs Committer (was: Patch Available) > wrap tracing logs in isTraceEnabled across the codebase > --- > > Key: CASSANDRA-19632 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19632 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Core >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 5.x > > Time Spent: 0.5h > Remaining Estimate: 0h > > Our usage of logger.isTraceEnabled across the codebase is inconsistent. This > would also fix issues similar in e.g. CASSANDRA-19429 as [~rustyrazorblade] > suggested. > We should fix this at least in trunk and 5.0 (not critical though) and > probably come up with a checkstyle rule to prevent not calling isTraceEnabled > while logging with TRACE level. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-19632) wrap tracing logs in isTraceEnabled across the codebase
[
https://issues.apache.org/jira/browse/CASSANDRA-19632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17848940#comment-17848940
]
Stefan Miklosovic edited comment on CASSANDRA-19632 at 5/23/24 12:59 PM:
-
I went through all logger.trace in the production code and I modified only 59
files instead of 127 in the first PR.
[https://github.com/apache/cassandra/pull/3329]
The perception I got by going through all of that is that people were already
following the rule of "if it has more than 2 arguments then wrap it in
logger.isTraceEnabled" so I went by that logic as well everywhere where it was
not done like that.
There were also inconsistent usages of logger.trace() with 0 / 1 / 2 arguments.
Sometimes it was wrapped in isTraceEnabled, sometimes it was not, without any
apparent reason. I think that for simple cases it is not necessary to wrap it,
we have majority of cases like that in the code base (not wrapped).
I have also fixed the cases where string concatenation was used and similar.
Not all people also seem to understand that when it is logged like this:
{code:java}
logger.trace("abc {}", object);
{code}
then the actual object.toString() is evaluated _after_ we are absolutely sure
we go to indeed log. I do not think that this is necessary, even "object" is
some "heavyweight" when it comes to toString because it is not called
prematurely anyway.
{code:java}
if (logger.isTraceEnabled())
logger.trace("abc {}", object);
{code}
as per [https://www.slf4j.org/faq.html#string_contents]
{quote}The logging system will invoke complexObject.toString() method only
after it has ascertained that the log statement was enabled. Otherwise, the
cost of complexObject.toString() conversion will be advantageously avoided.
{quote}
was (Author: smiklosovic):
I went through all logger.trace in the production code and I modified only 59
files instead of 127 in the first one.
https://github.com/apache/cassandra/pull/3329
The perception I got by going through all of that is that people were already
following the rule of "it it has more than 2 arguments then wrap it in
logger.isTraceEnabled" so I went by that logic as well everywhere where it was
not done like that.
There were also inconsistent usages of logger.trace() with 0 / 1 / 2 arguments.
Sometimes it was wrapped in isTraceEnabled, sometimes it was not, without any
apparent reason. I think that for simple cases it is not necessary to wrap it,
we have majority of cases like that in the code base (not wrapped).
I have also fixed the cases where string concatenation was used and similar.
Not all people also seem to understand that when it is logged like this:
{code}
logger.trace("abc {}", object);
{code}
then the actual object.toString() is evaluated _after_ we are absolutely sure
we go to indeed log. I do not think that this is necessary, even "object" is
some "heavyweight" when it comes to toString because it is not called
prematurely anyway.
{code}
if (logger.isTraceEnabled())
logger.trace("abc {}", object);
{code}
as per https://www.slf4j.org/faq.html#string_contents
{quote}
The logging system will invoke complexObject.toString() method only after it
has ascertained that the log statement was enabled. Otherwise, the cost of
complexObject.toString() conversion will be advantageously avoided.
{quote}
> wrap tracing logs in isTraceEnabled across the codebase
> ---
>
> Key: CASSANDRA-19632
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19632
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Core
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Our usage of logger.isTraceEnabled across the codebase is inconsistent. This
> would also fix issues similar in e.g. CASSANDRA-19429 as [~rustyrazorblade]
> suggested.
> We should fix this at least in trunk and 5.0 (not critical though) and
> probably come up with a checkstyle rule to prevent not calling isTraceEnabled
> while logging with TRACE level.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-19632) wrap tracing logs in isTraceEnabled across the codebase
[
https://issues.apache.org/jira/browse/CASSANDRA-19632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17848940#comment-17848940
]
Stefan Miklosovic edited comment on CASSANDRA-19632 at 5/23/24 12:57 PM:
-
I went through all logger.trace in the production code and I modified only 59
files instead of 127 in the first one.
https://github.com/apache/cassandra/pull/3329
The perception I got by going through all of that is that people were already
following the rule of "it it has more than 2 arguments then wrap it in
logger.isTraceEnabled" so I went by that logic as well everywhere where it was
not done like that.
There were also inconsistent usages of logger.trace() with 0 / 1 / 2 arguments.
Sometimes it was wrapped in isTraceEnabled, sometimes it was not, without any
apparent reason. I think that for simple cases it is not necessary to wrap it,
we have majority of cases like that in the code base (not wrapped).
I have also fixed the cases where string concatenation was used and similar.
Not all people also seem to understand that when it is logged like this:
{code}
logger.trace("abc {}", object);
{code}
then the actual object.toString() is evaluated _after_ we are absolutely sure
we go to indeed log. I do not think that this is necessary, even "object" is
some "heavyweight" when it comes to toString because it is not called
prematurely anyway.
{code}
if (logger.isTraceEnabled())
logger.trace("abc {}", object);
{code}
as per https://www.slf4j.org/faq.html#string_contents
{quote}
The logging system will invoke complexObject.toString() method only after it
has ascertained that the log statement was enabled. Otherwise, the cost of
complexObject.toString() conversion will be advantageously avoided.
{quote}
was (Author: smiklosovic):
I went through all logger.trace in the production code and I modified only 59
files instead of 127 in the first one.
https://github.com/apache/cassandra/pull/3329
The perception I got by going through all of that is that people were already
following the rule of "it it has more than 2 arguments then wrap it in
logger.isTraceEnabled" so I went by that logic as well everywhere where it was
not done like that.
There were also inconsistent usages of logger.trace() with 0 / 1 / 2 arguments.
Sometimes it was wrapped in isTraceEnabled, sometimes it was not, without any
apparent reason. I think that for simple cases it is not necessary to wrap it,
we have majority of cases like that in the code base (not wrapped).
I have also fixed the cases where string concatenation was used and similar.
Not all people also seem to understand that when it is logged like this:
{code}
logger.trace("abc {}", object);
{code}
then the actual object.toString() is evaluated _after_ we are absolutely sure
we go to indeed log. I do not think that this is necessary, even "object" is
some "heavyweight" when it comes to toString because it is not called
prematurely anyway.
{code}
if (logger.isTraceEnabled())
logger.trace("abc {}", object);
{code}
> wrap tracing logs in isTraceEnabled across the codebase
> ---
>
> Key: CASSANDRA-19632
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19632
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Core
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Our usage of logger.isTraceEnabled across the codebase is inconsistent. This
> would also fix issues similar in e.g. CASSANDRA-19429 as [~rustyrazorblade]
> suggested.
> We should fix this at least in trunk and 5.0 (not critical though) and
> probably come up with a checkstyle rule to prevent not calling isTraceEnabled
> while logging with TRACE level.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-19632) wrap tracing logs in isTraceEnabled across the codebase
[
https://issues.apache.org/jira/browse/CASSANDRA-19632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17848940#comment-17848940
]
Stefan Miklosovic edited comment on CASSANDRA-19632 at 5/23/24 12:55 PM:
-
I went through all logger.trace in the production code and I modified only 59
files instead of 127 in the first one.
https://github.com/apache/cassandra/pull/3329
The perception I got by going through all of that is that people were already
following the rule of "it it has more than 2 arguments then wrap it in
logger.isTraceEnabled" so I went by that logic as well everywhere where it was
not done like that.
There were also inconsistent usages of logger.trace() with 0 / 1 / 2 arguments.
Sometimes it was wrapped in isTraceEnabled, sometimes it was not, without any
apparent reason. I think that for simple cases it is not necessary to wrap it,
we have majority of cases like that in the code base (not wrapped).
I have also fixed the cases where string concatenation was used and similar.
Not all people also dont seem to understand that when it is logger like this:
{code}
logger.trace("abc {}", object);
{code}
then the actual object.toString() is evaluated _after_ we are absolutely sure
we go to indeed log. I do not think that this is necessary, even "object" is
some "heavyweight" when it comes to toString because it is not called
prematurely anyway.
{code}
if (logger.isTraceEnabled())
logger.trace("abc {}", object);
{code}
was (Author: smiklosovic):
I went through all logger.trace in the production code and I modified only 59
files instead of 127 in the first one.
https://github.com/apache/cassandra/pull/3329
The perception I got by going through all of that is that people were already
following the rule of "it it has more than 2 arguments then wrap it in
logger.isTraceEnabled" so I went by that logic as well everywhere where it was
not done like that.
There were also inconsistent usages of logger.trace() with 0 / 1 / 2 arguments.
Sometimes it was wrapped in isTraceEnabled, sometimes it was not, without any
apparent reason. I think that for simple cases it is not necessary to wrap it,
we have majority of cases like that in the code base (not wrapped).
I have also fixed the cases where string concatenation was used and similar.
> wrap tracing logs in isTraceEnabled across the codebase
> ---
>
> Key: CASSANDRA-19632
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19632
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Core
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Our usage of logger.isTraceEnabled across the codebase is inconsistent. This
> would also fix issues similar in e.g. CASSANDRA-19429 as [~rustyrazorblade]
> suggested.
> We should fix this at least in trunk and 5.0 (not critical though) and
> probably come up with a checkstyle rule to prevent not calling isTraceEnabled
> while logging with TRACE level.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-19632) wrap tracing logs in isTraceEnabled across the codebase
[
https://issues.apache.org/jira/browse/CASSANDRA-19632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17848940#comment-17848940
]
Stefan Miklosovic edited comment on CASSANDRA-19632 at 5/23/24 12:55 PM:
-
I went through all logger.trace in the production code and I modified only 59
files instead of 127 in the first one.
https://github.com/apache/cassandra/pull/3329
The perception I got by going through all of that is that people were already
following the rule of "it it has more than 2 arguments then wrap it in
logger.isTraceEnabled" so I went by that logic as well everywhere where it was
not done like that.
There were also inconsistent usages of logger.trace() with 0 / 1 / 2 arguments.
Sometimes it was wrapped in isTraceEnabled, sometimes it was not, without any
apparent reason. I think that for simple cases it is not necessary to wrap it,
we have majority of cases like that in the code base (not wrapped).
I have also fixed the cases where string concatenation was used and similar.
Not all people also seem to understand that when it is logged like this:
{code}
logger.trace("abc {}", object);
{code}
then the actual object.toString() is evaluated _after_ we are absolutely sure
we go to indeed log. I do not think that this is necessary, even "object" is
some "heavyweight" when it comes to toString because it is not called
prematurely anyway.
{code}
if (logger.isTraceEnabled())
logger.trace("abc {}", object);
{code}
was (Author: smiklosovic):
I went through all logger.trace in the production code and I modified only 59
files instead of 127 in the first one.
https://github.com/apache/cassandra/pull/3329
The perception I got by going through all of that is that people were already
following the rule of "it it has more than 2 arguments then wrap it in
logger.isTraceEnabled" so I went by that logic as well everywhere where it was
not done like that.
There were also inconsistent usages of logger.trace() with 0 / 1 / 2 arguments.
Sometimes it was wrapped in isTraceEnabled, sometimes it was not, without any
apparent reason. I think that for simple cases it is not necessary to wrap it,
we have majority of cases like that in the code base (not wrapped).
I have also fixed the cases where string concatenation was used and similar.
Not all people also seem to understand that when it is logger like this:
{code}
logger.trace("abc {}", object);
{code}
then the actual object.toString() is evaluated _after_ we are absolutely sure
we go to indeed log. I do not think that this is necessary, even "object" is
some "heavyweight" when it comes to toString because it is not called
prematurely anyway.
{code}
if (logger.isTraceEnabled())
logger.trace("abc {}", object);
{code}
> wrap tracing logs in isTraceEnabled across the codebase
> ---
>
> Key: CASSANDRA-19632
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19632
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Core
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Our usage of logger.isTraceEnabled across the codebase is inconsistent. This
> would also fix issues similar in e.g. CASSANDRA-19429 as [~rustyrazorblade]
> suggested.
> We should fix this at least in trunk and 5.0 (not critical though) and
> probably come up with a checkstyle rule to prevent not calling isTraceEnabled
> while logging with TRACE level.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-19632) wrap tracing logs in isTraceEnabled across the codebase
[
https://issues.apache.org/jira/browse/CASSANDRA-19632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17848940#comment-17848940
]
Stefan Miklosovic edited comment on CASSANDRA-19632 at 5/23/24 12:55 PM:
-
I went through all logger.trace in the production code and I modified only 59
files instead of 127 in the first one.
https://github.com/apache/cassandra/pull/3329
The perception I got by going through all of that is that people were already
following the rule of "it it has more than 2 arguments then wrap it in
logger.isTraceEnabled" so I went by that logic as well everywhere where it was
not done like that.
There were also inconsistent usages of logger.trace() with 0 / 1 / 2 arguments.
Sometimes it was wrapped in isTraceEnabled, sometimes it was not, without any
apparent reason. I think that for simple cases it is not necessary to wrap it,
we have majority of cases like that in the code base (not wrapped).
I have also fixed the cases where string concatenation was used and similar.
Not all people also seem to understand that when it is logger like this:
{code}
logger.trace("abc {}", object);
{code}
then the actual object.toString() is evaluated _after_ we are absolutely sure
we go to indeed log. I do not think that this is necessary, even "object" is
some "heavyweight" when it comes to toString because it is not called
prematurely anyway.
{code}
if (logger.isTraceEnabled())
logger.trace("abc {}", object);
{code}
was (Author: smiklosovic):
I went through all logger.trace in the production code and I modified only 59
files instead of 127 in the first one.
https://github.com/apache/cassandra/pull/3329
The perception I got by going through all of that is that people were already
following the rule of "it it has more than 2 arguments then wrap it in
logger.isTraceEnabled" so I went by that logic as well everywhere where it was
not done like that.
There were also inconsistent usages of logger.trace() with 0 / 1 / 2 arguments.
Sometimes it was wrapped in isTraceEnabled, sometimes it was not, without any
apparent reason. I think that for simple cases it is not necessary to wrap it,
we have majority of cases like that in the code base (not wrapped).
I have also fixed the cases where string concatenation was used and similar.
Not all people also dont seem to understand that when it is logger like this:
{code}
logger.trace("abc {}", object);
{code}
then the actual object.toString() is evaluated _after_ we are absolutely sure
we go to indeed log. I do not think that this is necessary, even "object" is
some "heavyweight" when it comes to toString because it is not called
prematurely anyway.
{code}
if (logger.isTraceEnabled())
logger.trace("abc {}", object);
{code}
> wrap tracing logs in isTraceEnabled across the codebase
> ---
>
> Key: CASSANDRA-19632
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19632
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Core
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Our usage of logger.isTraceEnabled across the codebase is inconsistent. This
> would also fix issues similar in e.g. CASSANDRA-19429 as [~rustyrazorblade]
> suggested.
> We should fix this at least in trunk and 5.0 (not critical though) and
> probably come up with a checkstyle rule to prevent not calling isTraceEnabled
> while logging with TRACE level.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19632) wrap tracing logs in isTraceEnabled across the codebase
[ https://issues.apache.org/jira/browse/CASSANDRA-19632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17848940#comment-17848940 ] Stefan Miklosovic commented on CASSANDRA-19632: --- I went through all logger.trace in the production code and I modified only 59 files instead of 127 in the first one. https://github.com/apache/cassandra/pull/3329 The perception I got by going through all of that is that people were already following the rule of "it it has more than 2 arguments then wrap it in logger.isTraceEnabled" so I went by that logic as well everywhere where it was not done like that. There were also inconsistent usages of logger.trace() with 0 / 1 / 2 arguments. Sometimes it was wrapped in isTraceEnabled, sometimes it was not, without any apparent reason. I think that for simple cases it is not necessary to wrap it, we have majority of cases like that in the code base (not wrapped). I have also fixed the cases where string concatenation was used and similar. > wrap tracing logs in isTraceEnabled across the codebase > --- > > Key: CASSANDRA-19632 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19632 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Core >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 5.x > > Time Spent: 20m > Remaining Estimate: 0h > > Our usage of logger.isTraceEnabled across the codebase is inconsistent. This > would also fix issues similar in e.g. CASSANDRA-19429 as [~rustyrazorblade] > suggested. > We should fix this at least in trunk and 5.0 (not critical though) and > probably come up with a checkstyle rule to prevent not calling isTraceEnabled > while logging with TRACE level. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-19659) null values injected while drop compact storage was executed
Matthias Pfau created CASSANDRA-19659: - Summary: null values injected while drop compact storage was executed Key: CASSANDRA-19659 URL: https://issues.apache.org/jira/browse/CASSANDRA-19659 Project: Cassandra Issue Type: Bug Components: Cluster/Schema Reporter: Matthias Pfau We noticed that values of some inserts that were run in parallel to an alter table drop compact storage statement turned into null values. This happened with version 3.11.10. Since then, we upgraded to 3.11.17. We tried to write a reproducer (inserting millions of rows/columns in parallel to drop compact storage) but we were not able to reproduce the bug with 3.11.17. This was reported on the mailing list first ([https://lists.apache.org/thread/hgwyd917yp01q0k9op79gztkx3qwypbc)] and seems to relate to https://issues.apache.org/jira/browse/CASSANDRA-13004. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
