Re: [PR] JAVA-3142: Ability to optionally specify remote dcs for deterministic failovers when remote dcs are used in query plan [cassandra-java-driver]
nitinitt commented on PR #1896: URL: https://github.com/apache/cassandra-java-driver/pull/1896#issuecomment-1874927651 Thanks @adutra for the insightful code review comments, really appreciate it. I'll address all of them and have an open question/clarification posted above. Happy New Year! -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
Re: [PR] JAVA-3142: Ability to optionally specify remote dcs for deterministic failovers when remote dcs are used in query plan [cassandra-java-driver]
nitinitt commented on code in PR #1896:
URL:
https://github.com/apache/cassandra-java-driver/pull/1896#discussion_r1440126405
##
core/src/main/java/com/datastax/oss/driver/internal/core/loadbalancing/BasicLoadBalancingPolicy.java:
##
@@ -325,24 +338,63 @@ protected Queue maybeAddDcFailover(@Nullable
Request request, @NonNull Que
@Override
protected Object[] computeNodes() {
-Object[] remoteNodes =
-liveNodes.dcs().stream()
-.filter(Predicates.not(Predicates.equalTo(localDc)))
-.flatMap(dc ->
liveNodes.dc(dc).stream().limit(maxNodesPerRemoteDc))
-.toArray();
-
-int remoteNodesLength = remoteNodes.length;
-if (remoteNodesLength == 0) {
- return EMPTY_NODES;
+if (!preferredRemoteLocalDcs.isEmpty()) {
Review Comment:
Should the nodes within the same preferred remote DC be shuffled? For eg: If
node1, node2 are in remote dc1 and node3, node4 in remote dc2 and
maxNodesPerRemoteDc=2 and preference order specified is dc1, dc2. In this
example, the remote nodes in query plan will always be: node1, node2, node3,
node4. Does it make sense to shuffle the nodes within a preferred remote DC,
i.e it can be ((node2, node1), (node4, node3))?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19105) Using Capture to save results in CQLSH with Tracing on incorrectly saves the trace details
[
https://issues.apache.org/jira/browse/CASSANDRA-19105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17802002#comment-17802002
]
Brad Schoening commented on CASSANDRA-19105:
[~gautamg] yes, looks ok. My view is that the color isn't too important. I
don't understand issue #2.
> Using Capture to save results in CQLSH with Tracing on incorrectly saves the
> trace details
> --
>
> Key: CASSANDRA-19105
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19105
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: Brad Schoening
>Assignee: Gautam G
>Priority: Normal
>
> When using *Tracing* in CQLSH, it's sometimes helpful to use *Capture* to
> avoid paging through output when you want to see the trace results. However,
> the trace results are also incorrectly captured to the output file.
> According to *Help Capture* (below), only the query result should be saved.
> The correct behavior should display the trace results and only capture the
> query results.
> {_}Help capture message{_}: Only query result output is captured.
> Errors and output from cqlsh-only commands will still be shown in the cqlsh
> session.
>
--
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-19120) local consistencies may get timeout if blocking read repair is sending the read repair mutation to other DC
[ https://issues.apache.org/jira/browse/CASSANDRA-19120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17801958#comment-17801958 ] Runtian Liu commented on CASSANDRA-19120: - 4.1: [https://github.com/apache/cassandra/pull/3019] 5.0: [https://github.com/apache/cassandra/pull/3020] trunk: [https://github.com/apache/cassandra/pull/3021] > local consistencies may get timeout if blocking read repair is sending the > read repair mutation to other DC > > > Key: CASSANDRA-19120 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19120 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Repair >Reporter: Runtian Liu >Assignee: Runtian Liu >Priority: Normal > Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x > > Attachments: image-2023-11-29-15-26-08-056.png, signature.asc > > Time Spent: 10m > Remaining Estimate: 0h > > For a two DCs cluster setup. When a new node is being added to DC1, for > blocking read repair triggered by local_quorum in DC1, it will require to > send read repair mutation to an extra node(1)(2). The selector for read > repair may select *ANY* node that has not been contacted before(3) instead of > selecting the DC1 nodes. If a node from DC2 is selected, this will cause 100% > timeout because of the bug described below: > When we initialized the latch(4) for blocking read repair, the shouldBlockOn > function will only return true for local nodes(5), the blockFor value will be > reduced if a local node doesn't require repair(6). The blockFor is same as > the number of read repair mutation sent out. But when the coordinator node > receives the response from the target nodes, the latch only count down for > nodes in same DC(7). The latch will wait till timeout and the read request > will timeout. > This can be reproduced if you have a constant load on a 3 + 3 cluster when > adding a node. If you have someway to trigger blocking read repair(maybe by > adding load using stress tool). If you use local_quorum consistency with a > constant read after write load in the same DC that you are adding node. You > will see read timeout issue from time to time because of the bug described > above > > I think for read repair when selecting the extra node to do repair, we should > prefer local nodes than the nodes from other region. Also, we need to fix the > latch part so even if we send mutation to the nodes in other DC, we don't get > a timeout. > (1)[https://github.com/apache/cassandra/blob/cassandra-4.0.11/src/java/org/apache/cassandra/locator/ReplicaPlans.java#L455] > (2)[https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/ConsistencyLevel.java#L183] > (3)[https://github.com/apache/cassandra/blob/cassandra-4.0.11/src/java/org/apache/cassandra/locator/ReplicaPlans.java#L458] > (4)[https://github.com/apache/cassandra/blob/cassandra-4.0.11/src/java/org/apache/cassandra/service/reads/repair/BlockingPartitionRepair.java#L96] > (5)[https://github.com/apache/cassandra/blob/cassandra-4.0.11/src/java/org/apache/cassandra/service/reads/repair/BlockingPartitionRepair.java#L71] > (6)[https://github.com/apache/cassandra/blob/cassandra-4.0.11/src/java/org/apache/cassandra/service/reads/repair/BlockingPartitionRepair.java#L88] > (7)[https://github.com/apache/cassandra/blob/cassandra-4.0.11/src/java/org/apache/cassandra/service/reads/repair/BlockingPartitionRepair.java#L113] > -- 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-18263) Update gc settings in build.xml
[ https://issues.apache.org/jira/browse/CASSANDRA-18263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17801946#comment-17801946 ] Michael Semb Wever commented on CASSANDRA-18263: No objection to switching jdk11 testing to g1 too, given that we now have extensive data on the state of jdk17 g1 testing. > Update gc settings in build.xml > --- > > Key: CASSANDRA-18263 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18263 > Project: Cassandra > Issue Type: Task > Components: Local/Config >Reporter: Ekaterina Dimitrova >Assignee: Jacek Lewandowski >Priority: Normal > Fix For: 5.x > > > As part of CASSANDRA-18027 we switched trunk to default to G1GC. We need to > update also our test settings in build.xml to test with what we default to in > trunk > CC [~mck] -- 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-90) Fix Sidecar TokenRangeReplicas endpoint to unwrap the token-range by partitioner's range for a single node clusters
[ https://issues.apache.org/jira/browse/CASSANDRASC-90?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francisco Guerrero updated CASSANDRASC-90: -- Reviewers: Francisco Guerrero, Francisco Guerrero (was: Francisco Guerrero) Francisco Guerrero, Francisco Guerrero (was: Francisco Guerrero) Status: Review In Progress (was: Patch Available) +1 Thanks for the fix > Fix Sidecar TokenRangeReplicas endpoint to unwrap the token-range by > partitioner's range for a single node clusters > --- > > Key: CASSANDRASC-90 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-90 > Project: Sidecar for Apache Cassandra > Issue Type: Bug > Components: Rest API >Reporter: Arjun Ashok >Assignee: Arjun Ashok >Priority: Normal > Labels: pull-request-available > > The sidecar token-range-replicas endpoint returns an empty range for the > write replicas for single node clusters, due to a bug that fails to unwrap > such ranges returned from Cassandra around the partitioner's token boundary. -- 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-90) Fix Sidecar TokenRangeReplicas endpoint to unwrap the token-range by partitioner's range for a single node clusters
[ https://issues.apache.org/jira/browse/CASSANDRASC-90?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arjun Ashok updated CASSANDRASC-90: --- Authors: Arjun Ashok Test and Documentation Plan: Added relevant unit tests to validate fix. Status: Patch Available (was: In Progress) > Fix Sidecar TokenRangeReplicas endpoint to unwrap the token-range by > partitioner's range for a single node clusters > --- > > Key: CASSANDRASC-90 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-90 > Project: Sidecar for Apache Cassandra > Issue Type: Bug > Components: Rest API >Reporter: Arjun Ashok >Assignee: Arjun Ashok >Priority: Normal > Labels: pull-request-available > > The sidecar token-range-replicas endpoint returns an empty range for the > write replicas for single node clusters, due to a bug that fails to unwrap > such ranges returned from Cassandra around the partitioner's token boundary. -- 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-90) Fix Sidecar TokenRangeReplicas endpoint to unwrap the token-range by partitioner's range for a single node clusters
[ https://issues.apache.org/jira/browse/CASSANDRASC-90?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arjun Ashok updated CASSANDRASC-90: --- Bug Category: Parent values: Correctness(12982) Complexity: Normal Discovered By: DTest Reviewers: Francisco Guerrero Severity: Normal Status: Open (was: Triage Needed) > Fix Sidecar TokenRangeReplicas endpoint to unwrap the token-range by > partitioner's range for a single node clusters > --- > > Key: CASSANDRASC-90 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-90 > Project: Sidecar for Apache Cassandra > Issue Type: Bug > Components: Rest API >Reporter: Arjun Ashok >Assignee: Arjun Ashok >Priority: Normal > Labels: pull-request-available > > The sidecar token-range-replicas endpoint returns an empty range for the > write replicas for single node clusters, due to a bug that fails to unwrap > such ranges returned from Cassandra around the partitioner's token boundary. -- 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-19104) Standardize tablestats formatting and data units
[ https://issues.apache.org/jira/browse/CASSANDRA-19104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-19104: - Status: Ready to Commit (was: Review In Progress) > Standardize tablestats formatting and data units > > > Key: CASSANDRA-19104 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19104 > Project: Cassandra > Issue Type: Bug > Components: Tool/nodetool >Reporter: Brad Schoening >Assignee: Leo Toff >Priority: Normal > Fix For: 5.x > > Time Spent: 4h 10m > Remaining Estimate: 0h > > Tablestats reports output in plaintext, JSON or YAML. The human readable > output currently has a mix of KiB, bytes with inconsistent spacing > Simplify and default output to 'human readable'. Machine readable output is > available as an option and the current mixed output formatting is neither > friendly for human or machine reading and can be replaced. > !image-2023-11-27-13-49-14-247.png! > *Not a goal now (consider a follow up Jira):* > Fix inconsistencies with KiB/MiB/GiB and KB/MB/GB formatting: > * gcstats - uses MB > * getcompactionthroughput - uses MB/s > * getstreamthroughput - uses MB/s > * info - uses MiB/GiB -- 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-19104) Standardize tablestats formatting and data units
[ https://issues.apache.org/jira/browse/CASSANDRA-19104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-19104: - Status: Review In Progress (was: Needs Committer) > Standardize tablestats formatting and data units > > > Key: CASSANDRA-19104 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19104 > Project: Cassandra > Issue Type: Bug > Components: Tool/nodetool >Reporter: Brad Schoening >Assignee: Leo Toff >Priority: Normal > Fix For: 5.x > > Time Spent: 4h 10m > Remaining Estimate: 0h > > Tablestats reports output in plaintext, JSON or YAML. The human readable > output currently has a mix of KiB, bytes with inconsistent spacing > Simplify and default output to 'human readable'. Machine readable output is > available as an option and the current mixed output formatting is neither > friendly for human or machine reading and can be replaced. > !image-2023-11-27-13-49-14-247.png! > *Not a goal now (consider a follow up Jira):* > Fix inconsistencies with KiB/MiB/GiB and KB/MB/GB formatting: > * gcstats - uses MB > * getcompactionthroughput - uses MB/s > * getstreamthroughput - uses MB/s > * info - uses MiB/GiB -- 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-19104) Standardize tablestats formatting and data units
[ https://issues.apache.org/jira/browse/CASSANDRA-19104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17801937#comment-17801937 ] Brandon Williams commented on CASSANDRA-19104: -- Looks good to me, [~smiklosovic]. +1 > Standardize tablestats formatting and data units > > > Key: CASSANDRA-19104 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19104 > Project: Cassandra > Issue Type: Bug > Components: Tool/nodetool >Reporter: Brad Schoening >Assignee: Leo Toff >Priority: Normal > Fix For: 5.x > > Time Spent: 4h 10m > Remaining Estimate: 0h > > Tablestats reports output in plaintext, JSON or YAML. The human readable > output currently has a mix of KiB, bytes with inconsistent spacing > Simplify and default output to 'human readable'. Machine readable output is > available as an option and the current mixed output formatting is neither > friendly for human or machine reading and can be replaced. > !image-2023-11-27-13-49-14-247.png! > *Not a goal now (consider a follow up Jira):* > Fix inconsistencies with KiB/MiB/GiB and KB/MB/GB formatting: > * gcstats - uses MB > * getcompactionthroughput - uses MB/s > * getstreamthroughput - uses MB/s > * info - uses MiB/GiB -- 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-19001) Check whether the startup warnings for unknown modules represent a legit problem or cosmetic issue
[
https://issues.apache.org/jira/browse/CASSANDRA-19001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17801934#comment-17801934
]
Michael Semb Wever commented on CASSANDRA-19001:
bq. I would prefer not to dis-recommend the use of JRE for FQL/Audit Logging
unless we have evidence that it does not work via a unit test or user report so
I created this commit to remove this recommendation from the documentation and
cassandra.yaml.
Agree, given your analysis.
> Check whether the startup warnings for unknown modules represent a legit
> problem or cosmetic issue
> --
>
> Key: CASSANDRA-19001
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19001
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Other
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.0-rc, 5.0.x, 5.x
>
>
> During the 5.0 alpha 2 release
> [vote|https://lists.apache.org/thread/lt3x0obr5cpbcydf5490pj6b2q0mz5zr],
> [~paulo] raised the following concerns:
> {code:java}
> Launched a tarball-based 5.0-alpha2 container on top of
> "eclipse-temurin:17-jre-focal" and the server starts up fine, can run
> nodetool and cqlsh.
> I got these seemingly harmless JDK17 warnings during startup and when
> running nodetool (no warnings on JDK11):
> WARNING: Unknown module: jdk.attach specified to --add-exports
> WARNING: Unknown module: jdk.compiler specified to --add-exports
> WARNING: Unknown module: jdk.compiler specified to --add-opens
> WARNING: A terminally deprecated method in java.lang.System has been called
> WARNING: System::setSecurityManager has been called by
> org.apache.cassandra.security.ThreadAwareSecurityManager
> (file:/opt/cassandra/lib/apache-cassandra-5.0-alpha2-SNAPSHOT.jar)
> WARNING: Please consider reporting this to the maintainers of
> org.apache.cassandra.security.ThreadAwareSecurityManager
> WARNING: System::setSecurityManager will be removed in a future release
> Anybody knows if these warnings are legit/expected ? We can create
> follow-up tickets if needed.
> $ java --version
> openjdk 17.0.9 2023-10-17
> OpenJDK Runtime Environment Temurin-17.0.9+9 (build 17.0.9+9)
> OpenJDK 64-Bit Server VM Temurin-17.0.9+9 (build 17.0.9+9, mixed mode,
> sharing)
> {code}
> {code:java}
> Clarification: - When running nodetool only the "Unknown module" warnings
> show up. All warnings show up during startup.{code}
> We need to verify whether this presents a real problem in the features where
> those modules are expected to be used, or if it is a false alarm.
>
--
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-18688) Limit Java runtime in 5.0 to JDK 11 and 17 in scripts; add a flag to opt out of that
[ https://issues.apache.org/jira/browse/CASSANDRA-18688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17801925#comment-17801925 ] shylaja kokoori commented on CASSANDRA-18688: - Thanks [~mck] , I will wait to hear from Ekaterina also & push the changes > Limit Java runtime in 5.0 to JDK 11 and 17 in scripts; add a flag to opt out > of that > > > Key: CASSANDRA-18688 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18688 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Ekaterina Dimitrova >Assignee: shylaja kokoori >Priority: Normal > Fix For: 5.0.x, 5.x > > Time Spent: 3.5h > Remaining Estimate: 0h > > Currently, we limit our users from building with non-default Java versions in > build.xml. > They can easily hack build.xml for test purposes with different versions. > Cassandra–5.0 will be run on JDK11 and JDK17, but on startup, we do not limit > people to those two, but only to everything >= 11. We should also put an > upper limit of 17 in our Cassandra startup scripts. We can also add a flag to > opt-out if someone wants to test with newer versions. -- 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-19246) BLOG - Contributor and townhall replay posts
Paul Au created CASSANDRA-19246: --- Summary: BLOG - Contributor and townhall replay posts Key: CASSANDRA-19246 URL: https://issues.apache.org/jira/browse/CASSANDRA-19246 Project: Cassandra Issue Type: Task Reporter: Paul Au Adding the Town Hall and Contributor November meetup replays. -- 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-92) Add restore SSTables from S3 into Cassandra feature to Cassandra Sidecar
[ https://issues.apache.org/jira/browse/CASSANDRASC-92?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Saranya Krishnakumar updated CASSANDRASC-92: Description: Through this proposal we want to add restore capability to Sidecar, for Sidecar to allow restoring data from S3. As part of this patch we want to add APIs for creating, updating and getting information about the restore jobs. We also want to add background tasks for managing these restore jobs. (was: Through this proposal we want to add restore capability to Sidecar, for Sidecar to allow restoring data from S3. As part of this patch we want to add APIs for creating, updating and getting information about the restore jobs. We also want to add background tasks for managing these restore jobs. Patch: [https://github.com/apache/cassandra-sidecar/pull/89]) > Add restore SSTables from S3 into Cassandra feature to Cassandra Sidecar > > > Key: CASSANDRASC-92 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-92 > Project: Sidecar for Apache Cassandra > Issue Type: New Feature > Components: Rest API >Reporter: Saranya Krishnakumar >Assignee: Saranya Krishnakumar >Priority: Normal > > Through this proposal we want to add restore capability to Sidecar, for > Sidecar to allow restoring data from S3. As part of this patch we want to add > APIs for creating, updating and getting information about the restore jobs. > We also want to add background tasks for managing these restore jobs. -- 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] (CASSANDRASC-92) Add restore SSTables from S3 into Cassandra feature to Cassandra Sidecar
[ https://issues.apache.org/jira/browse/CASSANDRASC-92 ] Saranya Krishnakumar deleted comment on CASSANDRASC-92: - was (Author: saranya_k): Tested with unit tests > Add restore SSTables from S3 into Cassandra feature to Cassandra Sidecar > > > Key: CASSANDRASC-92 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-92 > Project: Sidecar for Apache Cassandra > Issue Type: New Feature > Components: Rest API >Reporter: Saranya Krishnakumar >Assignee: Saranya Krishnakumar >Priority: Normal > > Through this proposal we want to add restore capability to Sidecar, for > Sidecar to allow restoring data from S3. As part of this patch we want to add > APIs for creating, updating and getting information about the restore jobs. > We also want to add background tasks for managing these restore jobs. > Patch: [https://github.com/apache/cassandra-sidecar/pull/89] -- 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-92) Add restore SSTables from S3 into Cassandra feature to Cassandra Sidecar
[ https://issues.apache.org/jira/browse/CASSANDRASC-92?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Saranya Krishnakumar updated CASSANDRASC-92: Authors: Saranya Krishnakumar, Yifan Cai Test and Documentation Plan: Tested with unit tests Status: Patch Available (was: Open) Patch: [https://github.com/apache/cassandra-sidecar/pull/89] > Add restore SSTables from S3 into Cassandra feature to Cassandra Sidecar > > > Key: CASSANDRASC-92 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-92 > Project: Sidecar for Apache Cassandra > Issue Type: New Feature > Components: Rest API >Reporter: Saranya Krishnakumar >Assignee: Saranya Krishnakumar >Priority: Normal > > Through this proposal we want to add restore capability to Sidecar, for > Sidecar to allow restoring data from S3. As part of this patch we want to add > APIs for creating, updating and getting information about the restore jobs. > We also want to add background tasks for managing these restore jobs. > Patch: [https://github.com/apache/cassandra-sidecar/pull/89] -- 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-92) Add restore SSTables from S3 into Cassandra feature to Cassandra Sidecar
[ https://issues.apache.org/jira/browse/CASSANDRASC-92?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Saranya Krishnakumar updated CASSANDRASC-92: Description: Through this proposal we want to add restore capability to Sidecar, for Sidecar to allow restoring data from S3. As part of this patch we want to add APIs for creating, updating and getting information about the restore jobs. We also want to add background tasks for managing these restore jobs. Patch: [https://github.com/apache/cassandra-sidecar/pull/89] was:Through this proposal we want to add restore capability to Sidecar, for Sidecar to allow restoring data from S3. As part of this patch we want to add APIs for creating, updating and getting information about the restore jobs. We also want to add background tasks for managing these restore jobs. > Add restore SSTables from S3 into Cassandra feature to Cassandra Sidecar > > > Key: CASSANDRASC-92 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-92 > Project: Sidecar for Apache Cassandra > Issue Type: New Feature > Components: Rest API >Reporter: Saranya Krishnakumar >Assignee: Saranya Krishnakumar >Priority: Normal > > Through this proposal we want to add restore capability to Sidecar, for > Sidecar to allow restoring data from S3. As part of this patch we want to add > APIs for creating, updating and getting information about the restore jobs. > We also want to add background tasks for managing these restore jobs. > Patch: [https://github.com/apache/cassandra-sidecar/pull/89] -- 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-18932) Harry-found CorruptSSTableException / RT Closer issue when reading entire partition
[
https://issues.apache.org/jira/browse/CASSANDRA-18932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-18932:
---
Fix Version/s: 5.0
> Harry-found CorruptSSTableException / RT Closer issue when reading entire
> partition
> ---
>
> Key: CASSANDRA-18932
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18932
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
>Reporter: Alex Petrov
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 5.0-beta1, 5.0
>
> Attachments: node1_.zip, operation.log.zip, screenshot-1.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> While testing some new machinery for Harry, I have encountered a new RT
> closer / SSTable Corruption issue. I have grounds to believe this was
> introduced during the last year.
> Issue seems to happen because of intricate interleaving of flushes with
> writes and deletes.
> {code:java}
> ERROR [ReadStage-2] 2023-10-16 18:47:06,696 JVMStabilityInspector.java:76 -
> Exception in thread Thread[ReadStage-2,5,SharedPool]
> org.apache.cassandra.io.sstable.CorruptSSTableException: Corrupted:
> RandomAccessReader:BufferManagingRebufferer.Aligned:CompressedChunkReader.Mmap(/Users/ifesdjeen/foss/java/apache-cassandra-4.0/data/data1/harry/table_1-07c35a606c0a11eeae7a4f6ca489eb0c/nc-5-big-Data.db
> - LZ4Compressor, chunk length 16384, data length 232569)
> at
> org.apache.cassandra.io.sstable.AbstractSSTableIterator$AbstractReader.hasNext(AbstractSSTableIterator.java:381)
> at
> org.apache.cassandra.io.sstable.AbstractSSTableIterator.hasNext(AbstractSSTableIterator.java:242)
> at
> org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.computeNext(LazilyInitializedUnfilteredRowIterator.java:95)
> at
> org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.computeNext(LazilyInitializedUnfilteredRowIterator.java:32)
> at
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47)
> at
> org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:133)
> at
> org.apache.cassandra.utils.MergeIterator$Candidate.advance(MergeIterator.java:376)
> at
> org.apache.cassandra.utils.MergeIterator$ManyToOne.advance(MergeIterator.java:188)
> at
> org.apache.cassandra.utils.MergeIterator$ManyToOne.computeNext(MergeIterator.java:157)
> at
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47)
> at
> org.apache.cassandra.db.rows.UnfilteredRowIterators$UnfilteredRowMergeIterator.computeNext(UnfilteredRowIterators.java:534)
> at
> org.apache.cassandra.db.rows.UnfilteredRowIterators$UnfilteredRowMergeIterator.computeNext(UnfilteredRowIterators.java:402)
> at
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47)
> at
> org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.computeNext(LazilyInitializedUnfilteredRowIterator.java:95)
> at
> org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.computeNext(LazilyInitializedUnfilteredRowIterator.java:32)
> at
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47)
> at
> org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:133)
> at
> org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:133)
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:151)
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:101)
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:86)
> at
> org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$Serializer.serialize(UnfilteredPartitionIterators.java:343)
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.build(ReadResponse.java:201)
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:186)
> at
> org.apache.cassandra.db.ReadResponse.createDataResponse(ReadResponse.java:48)
> at
> org.apache.cassandra.db.ReadCommand.createResponse(ReadCommand.java:346)
> at
> org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:2186)
> at
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2581)
> at
> org.apache.cassandra.concurrent.ExecutionFailure$2.run(ExecutionFailure.java:163)
> at
[jira] [Updated] (CASSANDRA-19210) Bring Harry into OSS Cassandra tree
[ https://issues.apache.org/jira/browse/CASSANDRA-19210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-19210: --- Fix Version/s: 5.1 > Bring Harry into OSS Cassandra tree > --- > > Key: CASSANDRA-19210 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19210 > Project: Cassandra > Issue Type: Improvement > Components: Test/fuzz >Reporter: Alex Petrov >Assignee: Alex Petrov >Priority: High > Fix For: 5.1-alpha1, 5.1 > > Attachments: ci_summary-1.html, ci_summary.html, > result_details.tar-1.gz, result_details.tar.gz > > > This patch introduces Harry into tree. > _No_ modifications were made to Harry code, so technically our tree has > already relied on it. The intention to introduce Harry to tree to lower the > entry barrier and allow quicker developer turnarounds. > CI results attached; all tests are green. Python tests are skipped because > this patch does not make any changes to production code, it's all testonly. -- 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-18688) Limit Java runtime in 5.0 to JDK 11 and 17 in scripts; add a flag to opt out of that
[ https://issues.apache.org/jira/browse/CASSANDRA-18688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17801922#comment-17801922 ] Michael Semb Wever commented on CASSANDRA-18688: Works for me [~skokoori]. > Limit Java runtime in 5.0 to JDK 11 and 17 in scripts; add a flag to opt out > of that > > > Key: CASSANDRA-18688 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18688 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Ekaterina Dimitrova >Assignee: shylaja kokoori >Priority: Normal > Fix For: 5.0.x, 5.x > > Time Spent: 3.5h > Remaining Estimate: 0h > > Currently, we limit our users from building with non-default Java versions in > build.xml. > They can easily hack build.xml for test purposes with different versions. > Cassandra–5.0 will be run on JDK11 and JDK17, but on startup, we do not limit > people to those two, but only to everything >= 11. We should also put an > upper limit of 17 in our Cassandra startup scripts. We can also add a flag to > opt-out if someone wants to test with newer versions. -- 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-19105) Using Capture to save results in CQLSH with Tracing on incorrectly saves the trace details
[
https://issues.apache.org/jira/browse/CASSANDRA-19105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17801920#comment-17801920
]
Gautam G commented on CASSANDRA-19105:
--
[~bschoeni] i tried to make some changes
[github|https://github.com/GautamGottipati/cassandra/commit/4a1228f2721476db94d1bc3692a2a880b7099708?diff=split=0]
Some of the issues after these changes : 1) When we enable capture the
self.color becomes false (line 1649 in qlshmain.py), due to this the trace is
not colored when printed in shell( sysout) 2) There is some issue on printing
Tracing session to the file. The Tracing session: does n't appear in the first
run, it appears in the next runs.
Wanted to know if I am on right track. Open for suggestions.
Thank you
> Using Capture to save results in CQLSH with Tracing on incorrectly saves the
> trace details
> --
>
> Key: CASSANDRA-19105
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19105
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: Brad Schoening
>Assignee: Gautam G
>Priority: Normal
>
> When using *Tracing* in CQLSH, it's sometimes helpful to use *Capture* to
> avoid paging through output when you want to see the trace results. However,
> the trace results are also incorrectly captured to the output file.
> According to *Help Capture* (below), only the query result should be saved.
> The correct behavior should display the trace results and only capture the
> query results.
> {_}Help capture message{_}: Only query result output is captured.
> Errors and output from cqlsh-only commands will still be shown in the cqlsh
> session.
>
--
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-18718) Fix gen-doc task
[
https://issues.apache.org/jira/browse/CASSANDRA-18718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-18718:
---
Fix Version/s: 5.0
5.0-alpha1
(was: 5.x)
Since Version: 5.0-alpha1
Source Control Link: https://github.com/apache/cassandra/commit/1e2c88f
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
> Fix gen-doc task
>
>
> Key: CASSANDRA-18718
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18718
> Project: Cassandra
> Issue Type: Bug
> Components: Documentation
>Reporter: Ekaterina Dimitrova
>Assignee: Lorina Poland
>Priority: Normal
> Fix For: 5.0, 5.0-alpha1
>
>
> As discussed on CASSANDRA-17687, we see below errors when ant gen-doc is run:
> {code:java}
> gen-asciidoc: [exec] python3 ./scripts/gen-nodetool-docs.py [exec] python3
> ./scripts/convert_yaml_to_adoc.py ../conf/cassandra.yaml
> ./modules/cassandra/pages/configuration/cass_yaml_file.adoc [exec] Traceback
> (most recent call last): [exec] File
> "/home/jlewandowski/dev/cassandra/trunk/doc/./scripts/convert_yaml_to_adoc.py",
> line 144, in [exec] convert(yaml_file, dest_file) [exec] File
> "/home/jlewandowski/dev/cassandra/trunk/doc/./scripts/convert_yaml_to_adoc.py",
> line 61, in convert [exec] with open(dest_file, 'w') as outfile: [exec]
> FileNotFoundError: [Errno 2] No such file or directory:
> './modules/cassandra/pages/configuration/cass_yaml_file.adoc' [exec] make:
> *** [Makefile:26: gen-asciidoc] Error 1 [exec] Result: 2{code}
> -This seems to have been broken during the migration from rst to asciidoc.-
--
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-18718) Fix gen-doc task
[
https://issues.apache.org/jira/browse/CASSANDRA-18718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-18718:
---
Reviewers: Michael Semb Wever, Michael Semb Wever
Michael Semb Wever, Michael Semb Wever (was: Michael Semb Wever)
Status: Review In Progress (was: Patch Available)
> Fix gen-doc task
>
>
> Key: CASSANDRA-18718
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18718
> Project: Cassandra
> Issue Type: Bug
> Components: Documentation
>Reporter: Ekaterina Dimitrova
>Assignee: Lorina Poland
>Priority: Normal
> Fix For: 5.x
>
>
> As discussed on CASSANDRA-17687, we see below errors when ant gen-doc is run:
> {code:java}
> gen-asciidoc: [exec] python3 ./scripts/gen-nodetool-docs.py [exec] python3
> ./scripts/convert_yaml_to_adoc.py ../conf/cassandra.yaml
> ./modules/cassandra/pages/configuration/cass_yaml_file.adoc [exec] Traceback
> (most recent call last): [exec] File
> "/home/jlewandowski/dev/cassandra/trunk/doc/./scripts/convert_yaml_to_adoc.py",
> line 144, in [exec] convert(yaml_file, dest_file) [exec] File
> "/home/jlewandowski/dev/cassandra/trunk/doc/./scripts/convert_yaml_to_adoc.py",
> line 61, in convert [exec] with open(dest_file, 'w') as outfile: [exec]
> FileNotFoundError: [Errno 2] No such file or directory:
> './modules/cassandra/pages/configuration/cass_yaml_file.adoc' [exec] make:
> *** [Makefile:26: gen-asciidoc] Error 1 [exec] Result: 2{code}
> -This seems to have been broken during the migration from rst to asciidoc.-
--
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-18718) Fix gen-doc task
[
https://issues.apache.org/jira/browse/CASSANDRA-18718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-18718:
---
Status: Ready to Commit (was: Review In Progress)
> Fix gen-doc task
>
>
> Key: CASSANDRA-18718
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18718
> Project: Cassandra
> Issue Type: Bug
> Components: Documentation
>Reporter: Ekaterina Dimitrova
>Assignee: Lorina Poland
>Priority: Normal
> Fix For: 5.x
>
>
> As discussed on CASSANDRA-17687, we see below errors when ant gen-doc is run:
> {code:java}
> gen-asciidoc: [exec] python3 ./scripts/gen-nodetool-docs.py [exec] python3
> ./scripts/convert_yaml_to_adoc.py ../conf/cassandra.yaml
> ./modules/cassandra/pages/configuration/cass_yaml_file.adoc [exec] Traceback
> (most recent call last): [exec] File
> "/home/jlewandowski/dev/cassandra/trunk/doc/./scripts/convert_yaml_to_adoc.py",
> line 144, in [exec] convert(yaml_file, dest_file) [exec] File
> "/home/jlewandowski/dev/cassandra/trunk/doc/./scripts/convert_yaml_to_adoc.py",
> line 61, in convert [exec] with open(dest_file, 'w') as outfile: [exec]
> FileNotFoundError: [Errno 2] No such file or directory:
> './modules/cassandra/pages/configuration/cass_yaml_file.adoc' [exec] make:
> *** [Makefile:26: gen-asciidoc] Error 1 [exec] Result: 2{code}
> -This seems to have been broken during the migration from rst to asciidoc.-
--
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-18718) Fix gen-doc task
[
https://issues.apache.org/jira/browse/CASSANDRA-18718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lorina Poland updated CASSANDRA-18718:
--
Test and Documentation Plan: n/a
Status: Patch Available (was: In Progress)
Fixed in commit 1e2c88f.
> Fix gen-doc task
>
>
> Key: CASSANDRA-18718
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18718
> Project: Cassandra
> Issue Type: Bug
> Components: Documentation
>Reporter: Ekaterina Dimitrova
>Assignee: Lorina Poland
>Priority: Normal
> Fix For: 5.x
>
>
> As discussed on CASSANDRA-17687, we see below errors when ant gen-doc is run:
> {code:java}
> gen-asciidoc: [exec] python3 ./scripts/gen-nodetool-docs.py [exec] python3
> ./scripts/convert_yaml_to_adoc.py ../conf/cassandra.yaml
> ./modules/cassandra/pages/configuration/cass_yaml_file.adoc [exec] Traceback
> (most recent call last): [exec] File
> "/home/jlewandowski/dev/cassandra/trunk/doc/./scripts/convert_yaml_to_adoc.py",
> line 144, in [exec] convert(yaml_file, dest_file) [exec] File
> "/home/jlewandowski/dev/cassandra/trunk/doc/./scripts/convert_yaml_to_adoc.py",
> line 61, in convert [exec] with open(dest_file, 'w') as outfile: [exec]
> FileNotFoundError: [Errno 2] No such file or directory:
> './modules/cassandra/pages/configuration/cass_yaml_file.adoc' [exec] make:
> *** [Makefile:26: gen-asciidoc] Error 1 [exec] Result: 2{code}
> -This seems to have been broken during the migration from rst to asciidoc.-
--
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-18718) Fix gen-doc task
[
https://issues.apache.org/jira/browse/CASSANDRA-18718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17801915#comment-17801915
]
Lorina Poland commented on CASSANDRA-18718:
---
Fixed with commit 1e2c88f.
> Fix gen-doc task
>
>
> Key: CASSANDRA-18718
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18718
> Project: Cassandra
> Issue Type: Bug
> Components: Documentation
>Reporter: Ekaterina Dimitrova
>Assignee: Lorina Poland
>Priority: Normal
> Fix For: 5.x
>
>
> As discussed on CASSANDRA-17687, we see below errors when ant gen-doc is run:
> {code:java}
> gen-asciidoc: [exec] python3 ./scripts/gen-nodetool-docs.py [exec] python3
> ./scripts/convert_yaml_to_adoc.py ../conf/cassandra.yaml
> ./modules/cassandra/pages/configuration/cass_yaml_file.adoc [exec] Traceback
> (most recent call last): [exec] File
> "/home/jlewandowski/dev/cassandra/trunk/doc/./scripts/convert_yaml_to_adoc.py",
> line 144, in [exec] convert(yaml_file, dest_file) [exec] File
> "/home/jlewandowski/dev/cassandra/trunk/doc/./scripts/convert_yaml_to_adoc.py",
> line 61, in convert [exec] with open(dest_file, 'w') as outfile: [exec]
> FileNotFoundError: [Errno 2] No such file or directory:
> './modules/cassandra/pages/configuration/cass_yaml_file.adoc' [exec] make:
> *** [Makefile:26: gen-asciidoc] Error 1 [exec] Result: 2{code}
> -This seems to have been broken during the migration from rst to asciidoc.-
--
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-19207) Inquiry and Clarification on Addition of java-cup-runtime-11b-20160615.jar in Cassandra 4.0.10 Upgrade
[ https://issues.apache.org/jira/browse/CASSANDRA-19207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17801911#comment-17801911 ] Brandon Williams commented on CASSANDRA-19207: -- [~zony] I'm unable to find any place we are including java-cup-runtime, can you show me? > Inquiry and Clarification on Addition of java-cup-runtime-11b-20160615.jar in > Cassandra 4.0.10 Upgrade > -- > > Key: CASSANDRA-19207 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19207 > Project: Cassandra > Issue Type: Bug >Reporter: Zongyue Li >Priority: Normal > Attachments: image-2023-12-19-11-36-26-925.png, > image-2023-12-19-11-36-49-151.png, image-2023-12-19-11-37-32-251.png, > image-2023-12-19-11-43-19-071.png, image-2023-12-19-11-43-36-536.png, > image-2023-12-19-11-45-06-345.png, image-2023-12-19-11-45-18-681.png, > image-2023-12-19-11-45-30-576.png, image-2023-12-19-13-44-16-660.png > > > During the recent upgrade from Cassandra 3 to Cassandra 4.0.10, I noticed the > introduction of a GPL-Compatible dependency, specifically > "java-cup-runtime-11b-20160615.jar." Upon further investigation, the > declaration of this dependency seems to add an extra layer of complexity. > While I understand that introducing GPL-Compatible dependencies into Apache > is generally acceptable, the necessity of this declaration and whether it is > an additional step has raised concerns. > !image-2023-12-19-13-44-16-660.png|width=841,height=196! > !image-2023-12-19-11-43-19-071.png|width=611,height=373! > [This LINCENSE|https://www2.cs.tum.edu/projects/cup/licence.php] refer to > "Historical Permission Notice and Disclaimer" > !image-2023-12-19-11-45-06-345.png|width=556,height=430! > This uncommon license falls under Category A. > !image-2023-12-19-11-45-18-681.png|width=490,height=478! > Additionally, I observed that some portions of the code are explicitly marked > as GPL (①). However, in the README file on the project's homepage, there is a > clear indication of the licenses for different distribution packages. I > believe we should reference Protocol ② or ③, namely the Historical protocol. > !image-2023-12-19-11-45-30-576.png|width=523,height=308! > I would like to bring attention to these two issues to ensure that we adhere > to the correct protocols when using and distributing the code. Please > consider explicitly stating in the relevant documentation or instructions > that we are using the Historical protocol. > Thank you for your attention to these issues. I believe addressing them will > contribute to ensuring the legality of our code usage and distribution. > > > -- 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] [Assigned] (CASSANDRA-18234) Write docs for CEP-21
[ https://issues.apache.org/jira/browse/CASSANDRA-18234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lorina Poland reassigned CASSANDRA-18234: - Assignee: Lorina Poland > Write docs for CEP-21 > - > > Key: CASSANDRA-18234 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18234 > Project: Cassandra > Issue Type: New Feature > Components: Documentation >Reporter: Lorina Poland >Assignee: Lorina Poland >Priority: High > Fix For: 5.x > > -- 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-18227) Documentation work to accomplish for C* 5.0 launch
[ https://issues.apache.org/jira/browse/CASSANDRA-18227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lorina Poland updated CASSANDRA-18227: -- Fix Version/s: 5.x > Documentation work to accomplish for C* 5.0 launch > -- > > Key: CASSANDRA-18227 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18227 > Project: Cassandra > Issue Type: Epic > Components: Documentation >Reporter: Lorina Poland >Assignee: Lorina Poland >Priority: High > Fix For: 5.x > > > This epic describes the major items that must be completed by the time Apache > C* 5.0 launches. Tickets will be added as required. > Cassandra 5.0 Doc Plan: > https://docs.google.com/document/d/1FAACcAxtV9qLJS05RLt85S_6Gb4C4t4g9DhmfLufjOk/edit?usp=sharing -- 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-18234) Write docs for CEP-21
[ https://issues.apache.org/jira/browse/CASSANDRA-18234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lorina Poland updated CASSANDRA-18234: -- Priority: High (was: Normal) > Write docs for CEP-21 > - > > Key: CASSANDRA-18234 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18234 > Project: Cassandra > Issue Type: New Feature > Components: Documentation >Reporter: Lorina Poland >Priority: High > Fix For: 5.x > > -- 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-18227) Documentation work to accomplish for C* 5.0 launch
[ https://issues.apache.org/jira/browse/CASSANDRA-18227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lorina Poland updated CASSANDRA-18227: -- Priority: High (was: Normal) > Documentation work to accomplish for C* 5.0 launch > -- > > Key: CASSANDRA-18227 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18227 > Project: Cassandra > Issue Type: Epic > Components: Documentation >Reporter: Lorina Poland >Assignee: Lorina Poland >Priority: High > > This epic describes the major items that must be completed by the time Apache > C* 5.0 launches. Tickets will be added as required. > Cassandra 5.0 Doc Plan: > https://docs.google.com/document/d/1FAACcAxtV9qLJS05RLt85S_6Gb4C4t4g9DhmfLufjOk/edit?usp=sharing -- 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-18939) Creating a SASI index after creating an SAI index breaks secondary index queries
[
https://issues.apache.org/jira/browse/CASSANDRA-18939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17801895#comment-17801895
]
Stefan Miklosovic commented on CASSANDRA-18939:
---
[~adelapena] I rewrote the thing, pushed the changes into 5.0 PR
> Creating a SASI index after creating an SAI index breaks secondary index
> queries
>
>
> Key: CASSANDRA-18939
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18939
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/2i Index
>Reporter: Jon Haddad
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> In the 5.0 branch, HEAD is e45c1092f91edd63591f562b2120ea6a5fd3edd5, I was
> able to break secondary indexes by doing the following:
> {code}
> cqlsh -e "create KEYSPACE test WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': 1};"
> cqlsh -e "create table test.blah (id int primary key, val text);"
> cqlsh -e "create INDEX on test.blah (val) using 'sai';"
> bin/nodetool flush
> ❯ cqlsh -e "SELECT * from test.blah WHERE val = 'something';"
> id | val
> +-
> (0 rows)
> cqlsh -e "create custom INDEX on test.blah (val) using
> 'org.apache.cassandra.index.sasi.SASIIndex';"
> Warnings :
> SASI indexes are experimental and are not recommended for production use.
> cqlsh -e "SELECT * from test.blah WHERE val = 'something';"
> :1:ReadFailure: Error from server: code=1300 [Replica(s) failed to
> execute read] message="Operation failed - received 0 responses and 1
> failures: UNKNOWN from localhost/127.0.0.1:7000" info={'consistency': 'ONE',
> 'required_responses': 1, 'received_responses': 0, 'failures': 1,
> 'error_code_map': {'127.0.0.1': '0x'}}
> {code}
> Server throws an exception:
> {code}
> ERROR [ReadStage-2] 2023-10-18 12:09:42,391 JVMStabilityInspector.java:70 -
> Exception in thread Thread[ReadStage-2,10,SharedPool]
> java.lang.RuntimeException: java.lang.ClassCastException: class
> org.apache.cassandra.index.sai.StorageAttachedIndex cannot be cast to class
> org.apache.cassandra.index.sasi.SASIIndex
> (org.apache.cassandra.index.sai.StorageAttachedIndex and
> org.apache.cassandra.index.sasi.SASIIndex are in unnamed module of loader
> 'app')
> at
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2585)
> at
> org.apache.cassandra.concurrent.ExecutionFailure$2.run(ExecutionFailure.java:163)
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:143)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:829)
> Caused by: java.lang.ClassCastException: class
> org.apache.cassandra.index.sai.StorageAttachedIndex cannot be cast to class
> org.apache.cassandra.index.sasi.SASIIndex
> (org.apache.cassandra.index.sai.StorageAttachedIndex and
> org.apache.cassandra.index.sasi.SASIIndex are in unnamed module of loader
> 'app')
> at
> org.apache.cassandra.index.sasi.plan.QueryController.getIndex(QueryController.java:96)
> at
> org.apache.cassandra.index.sasi.plan.Operation.analyzeGroup(Operation.java:282)
> at
> org.apache.cassandra.index.sasi.plan.Operation$Builder.complete(Operation.java:433)
> at
> org.apache.cassandra.index.sasi.plan.SASIIndexSearcher.analyze(SASIIndexSearcher.java:65)
> at
> org.apache.cassandra.index.sasi.plan.SASIIndexSearcher.search(SASIIndexSearcher.java:77)
> at
> org.apache.cassandra.db.ReadCommand.executeLocally(ReadCommand.java:425)
> at
> org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:2184)
> at org.apache.cassandra.service
> {code}
> Dropping the SASI index restores correct behavior.
--
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-92) Add restore SSTables from S3 into Cassandra feature to Cassandra Sidecar
[ https://issues.apache.org/jira/browse/CASSANDRASC-92?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Saranya Krishnakumar updated CASSANDRASC-92: Change Category: Performance Complexity: Normal Component/s: Rest API Reviewers: Francisco Guerrero, Yifan Cai Assignee: Saranya Krishnakumar Status: Open (was: Triage Needed) Tested with unit tests > Add restore SSTables from S3 into Cassandra feature to Cassandra Sidecar > > > Key: CASSANDRASC-92 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-92 > Project: Sidecar for Apache Cassandra > Issue Type: New Feature > Components: Rest API >Reporter: Saranya Krishnakumar >Assignee: Saranya Krishnakumar >Priority: Normal > > Through this proposal we want to add restore capability to Sidecar, for > Sidecar to allow restoring data from S3. As part of this patch we want to add > APIs for creating, updating and getting information about the restore jobs. > We also want to add background tasks for managing these restore jobs. -- 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-92) Add restore SSTables from S3 into Cassandra feature to Cassandra Sidecar
Saranya Krishnakumar created CASSANDRASC-92: --- Summary: Add restore SSTables from S3 into Cassandra feature to Cassandra Sidecar Key: CASSANDRASC-92 URL: https://issues.apache.org/jira/browse/CASSANDRASC-92 Project: Sidecar for Apache Cassandra Issue Type: New Feature Reporter: Saranya Krishnakumar Through this proposal we want to add restore capability to Sidecar, for Sidecar to allow restoring data from S3. As part of this patch we want to add APIs for creating, updating and getting information about the restore jobs. We also want to add background tasks for managing these restore jobs. -- 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-19187) nodetool assassinate may cause thread serialization for that node
[
https://issues.apache.org/jira/browse/CASSANDRA-19187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-19187:
-
Status: Needs Committer (was: Patch Available)
> nodetool assassinate may cause thread serialization for that node
> -
>
> Key: CASSANDRA-19187
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19187
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Membership
>Reporter: Runtian Liu
>Assignee: Runtian Liu
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0.x
>
>
> When assassinate an ip address that is not in the gossip map, a "corrupted"
> entry will be inserted into the gossip map.
> [(1)|https://github.com/apache/cassandra/blob/cassandra-4.0/src/java/org/apache/cassandra/gms/Gossiper.java#L810]
> For example, if we do "nodetool assassinate 10.1.1.1"
> we will get an entry like below by running "nodetool gossipinfo":
>
> {code:java}
> /10.1.1.1
> generation:1702006511
> heartbeat:
> STATUS:209516:LEFT,-8393921141401589197,1702265651923
> STATUS_WITH_PORT:209515:LEFT,-8393921141401589197,1702265651923
> TOKENS: not present {code}
>
> This entry in endpointStateMap will cause issue for
> [isUpgradingFromVersionLowerThan|https://github.com/apache/cassandra/blob/cassandra-4.0/src/java/org/apache/cassandra/gms/Gossiper.java#L2284]
> function. Because the
> [upgradeFromVersionSupplier|https://github.com/apache/cassandra/blob/cassandra-4.0/src/java/org/apache/cassandra/gms/Gossiper.java#L191]
> supplier will always set the
> [allHostsHaveKnownVersion|https://github.com/apache/cassandra/blob/cassandra-4.0/src/java/org/apache/cassandra/gms/Gossiper.java#L216]
> flag to false so no memoized value will be returned. The "get" function will
> always require a lock from this
> [line|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/utils/ExpiringMemoizingSupplier.java#L66].
> If application is using "fetchAll", the native-transport-requests thread will
> hit this
> [line|https://github.com/apache/cassandra/blob/cassandra-4.0/src/java/org/apache/cassandra/db/filter/ColumnFilter.java#L574].
> This means all the native-transport-requests thread is serialized, also, the
> lock is shared by GossipStage threads. It means if a node in a cluster with
> the corrupted gossip map is restart, the node will run into this problem.
> To fix the issue,
> # Why we want to add a dummy entry for nodetool assassinate if the endpoint
> is not in the map anymore. Should we do nothing or throw exception if the
> node is not in the gossip map anymore?
> # Before checking if a version is null, we should make sure the node is not
> a dead node. A decommissioned node, a left node should not be considered part
> of the cluster anymore when calculating "upgradeInProgressPossible"
>
--
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-19187) nodetool assassinate may cause thread serialization for that node
[
https://issues.apache.org/jira/browse/CASSANDRA-19187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17801884#comment-17801884
]
Brandon Williams commented on CASSANDRA-19187:
--
Everything passed, +1 from me.
> nodetool assassinate may cause thread serialization for that node
> -
>
> Key: CASSANDRA-19187
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19187
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Membership
>Reporter: Runtian Liu
>Assignee: Runtian Liu
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0.x
>
>
> When assassinate an ip address that is not in the gossip map, a "corrupted"
> entry will be inserted into the gossip map.
> [(1)|https://github.com/apache/cassandra/blob/cassandra-4.0/src/java/org/apache/cassandra/gms/Gossiper.java#L810]
> For example, if we do "nodetool assassinate 10.1.1.1"
> we will get an entry like below by running "nodetool gossipinfo":
>
> {code:java}
> /10.1.1.1
> generation:1702006511
> heartbeat:
> STATUS:209516:LEFT,-8393921141401589197,1702265651923
> STATUS_WITH_PORT:209515:LEFT,-8393921141401589197,1702265651923
> TOKENS: not present {code}
>
> This entry in endpointStateMap will cause issue for
> [isUpgradingFromVersionLowerThan|https://github.com/apache/cassandra/blob/cassandra-4.0/src/java/org/apache/cassandra/gms/Gossiper.java#L2284]
> function. Because the
> [upgradeFromVersionSupplier|https://github.com/apache/cassandra/blob/cassandra-4.0/src/java/org/apache/cassandra/gms/Gossiper.java#L191]
> supplier will always set the
> [allHostsHaveKnownVersion|https://github.com/apache/cassandra/blob/cassandra-4.0/src/java/org/apache/cassandra/gms/Gossiper.java#L216]
> flag to false so no memoized value will be returned. The "get" function will
> always require a lock from this
> [line|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/utils/ExpiringMemoizingSupplier.java#L66].
> If application is using "fetchAll", the native-transport-requests thread will
> hit this
> [line|https://github.com/apache/cassandra/blob/cassandra-4.0/src/java/org/apache/cassandra/db/filter/ColumnFilter.java#L574].
> This means all the native-transport-requests thread is serialized, also, the
> lock is shared by GossipStage threads. It means if a node in a cluster with
> the corrupted gossip map is restart, the node will run into this problem.
> To fix the issue,
> # Why we want to add a dummy entry for nodetool assassinate if the endpoint
> is not in the map anymore. Should we do nothing or throw exception if the
> node is not in the gossip map anymore?
> # Before checking if a version is null, we should make sure the node is not
> a dead node. A decommissioned node, a left node should not be considered part
> of the cluster anymore when calculating "upgradeInProgressPossible"
>
--
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-19187) nodetool assassinate may cause thread serialization for that node
[
https://issues.apache.org/jira/browse/CASSANDRA-19187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-19187:
-
Test and Documentation Plan: Test added, CI
Status: Patch Available (was: Open)
> nodetool assassinate may cause thread serialization for that node
> -
>
> Key: CASSANDRA-19187
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19187
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Membership
>Reporter: Runtian Liu
>Assignee: Runtian Liu
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0.x
>
>
> When assassinate an ip address that is not in the gossip map, a "corrupted"
> entry will be inserted into the gossip map.
> [(1)|https://github.com/apache/cassandra/blob/cassandra-4.0/src/java/org/apache/cassandra/gms/Gossiper.java#L810]
> For example, if we do "nodetool assassinate 10.1.1.1"
> we will get an entry like below by running "nodetool gossipinfo":
>
> {code:java}
> /10.1.1.1
> generation:1702006511
> heartbeat:
> STATUS:209516:LEFT,-8393921141401589197,1702265651923
> STATUS_WITH_PORT:209515:LEFT,-8393921141401589197,1702265651923
> TOKENS: not present {code}
>
> This entry in endpointStateMap will cause issue for
> [isUpgradingFromVersionLowerThan|https://github.com/apache/cassandra/blob/cassandra-4.0/src/java/org/apache/cassandra/gms/Gossiper.java#L2284]
> function. Because the
> [upgradeFromVersionSupplier|https://github.com/apache/cassandra/blob/cassandra-4.0/src/java/org/apache/cassandra/gms/Gossiper.java#L191]
> supplier will always set the
> [allHostsHaveKnownVersion|https://github.com/apache/cassandra/blob/cassandra-4.0/src/java/org/apache/cassandra/gms/Gossiper.java#L216]
> flag to false so no memoized value will be returned. The "get" function will
> always require a lock from this
> [line|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/utils/ExpiringMemoizingSupplier.java#L66].
> If application is using "fetchAll", the native-transport-requests thread will
> hit this
> [line|https://github.com/apache/cassandra/blob/cassandra-4.0/src/java/org/apache/cassandra/db/filter/ColumnFilter.java#L574].
> This means all the native-transport-requests thread is serialized, also, the
> lock is shared by GossipStage threads. It means if a node in a cluster with
> the corrupted gossip map is restart, the node will run into this problem.
> To fix the issue,
> # Why we want to add a dummy entry for nodetool assassinate if the endpoint
> is not in the map anymore. Should we do nothing or throw exception if the
> node is not in the gossip map anymore?
> # Before checking if a version is null, we should make sure the node is not
> a dead node. A decommissioned node, a left node should not be considered part
> of the cluster anymore when calculating "upgradeInProgressPossible"
>
--
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-19187) nodetool assassinate may cause thread serialization for that node
[
https://issues.apache.org/jira/browse/CASSANDRA-19187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17801876#comment-17801876
]
Brandon Williams commented on CASSANDRA-19187:
--
Just the repeated tests:
||Branch||CI||
|[4.0|https://github.com/driftx/cassandra/tree/CASSANDRA-19187-4.0]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/1420/workflows/0a168da1-c2e8-4da4-b001-ae9f96e95588],
[j11|https://app.circleci.com/pipelines/github/driftx/cassandra/1420/workflows/a9d53818-ee40-43f3-a9a3-e57087a5a0a7]|
|[4.1|https://github.com/driftx/cassandra/tree/CASSANDRA-19187-4.1]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/1421/workflows/08063fdc-5449-4934-b2cc-29a6b0012ce6],
[j11|https://app.circleci.com/pipelines/github/driftx/cassandra/1421/workflows/35092cdc-37fa-456f-91c4-760285917cdf]|
|[5.0|https://github.com/driftx/cassandra/tree/CASSANDRA-19187-5.0]|[j11|https://app.circleci.com/pipelines/github/driftx/cassandra/1422/workflows/6877cced-1df0-4b1c-8d66-34cebcf2e8dc],
[j17|https://app.circleci.com/pipelines/github/driftx/cassandra/1422/workflows/8f57d636-542e-457d-a3de-4930af0d9b02]|
> nodetool assassinate may cause thread serialization for that node
> -
>
> Key: CASSANDRA-19187
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19187
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Membership
>Reporter: Runtian Liu
>Assignee: Runtian Liu
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0.x
>
>
> When assassinate an ip address that is not in the gossip map, a "corrupted"
> entry will be inserted into the gossip map.
> [(1)|https://github.com/apache/cassandra/blob/cassandra-4.0/src/java/org/apache/cassandra/gms/Gossiper.java#L810]
> For example, if we do "nodetool assassinate 10.1.1.1"
> we will get an entry like below by running "nodetool gossipinfo":
>
> {code:java}
> /10.1.1.1
> generation:1702006511
> heartbeat:
> STATUS:209516:LEFT,-8393921141401589197,1702265651923
> STATUS_WITH_PORT:209515:LEFT,-8393921141401589197,1702265651923
> TOKENS: not present {code}
>
> This entry in endpointStateMap will cause issue for
> [isUpgradingFromVersionLowerThan|https://github.com/apache/cassandra/blob/cassandra-4.0/src/java/org/apache/cassandra/gms/Gossiper.java#L2284]
> function. Because the
> [upgradeFromVersionSupplier|https://github.com/apache/cassandra/blob/cassandra-4.0/src/java/org/apache/cassandra/gms/Gossiper.java#L191]
> supplier will always set the
> [allHostsHaveKnownVersion|https://github.com/apache/cassandra/blob/cassandra-4.0/src/java/org/apache/cassandra/gms/Gossiper.java#L216]
> flag to false so no memoized value will be returned. The "get" function will
> always require a lock from this
> [line|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/utils/ExpiringMemoizingSupplier.java#L66].
> If application is using "fetchAll", the native-transport-requests thread will
> hit this
> [line|https://github.com/apache/cassandra/blob/cassandra-4.0/src/java/org/apache/cassandra/db/filter/ColumnFilter.java#L574].
> This means all the native-transport-requests thread is serialized, also, the
> lock is shared by GossipStage threads. It means if a node in a cluster with
> the corrupted gossip map is restart, the node will run into this problem.
> To fix the issue,
> # Why we want to add a dummy entry for nodetool assassinate if the endpoint
> is not in the map anymore. Should we do nothing or throw exception if the
> node is not in the gossip map anymore?
> # Before checking if a version is null, we should make sure the node is not
> a dead node. A decommissioned node, a left node should not be considered part
> of the cluster anymore when calculating "upgradeInProgressPossible"
>
--
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-19219) CMS: restarting a CMS node with different ip address
[
https://issues.apache.org/jira/browse/CASSANDRA-19219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17801869#comment-17801869
]
Paul Chandler commented on CASSANDRA-19219:
---
I have tested the patch, and this fixes the problem I was having, the node will
now restart after a ip address change.
> CMS: restarting a CMS node with different ip address
>
>
> Key: CASSANDRA-19219
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19219
> Project: Cassandra
> Issue Type: Bug
> Components: Transactional Cluster Metadata
>Reporter: Paul Chandler
>Assignee: Alex Petrov
>Priority: Normal
> Fix For: 5.1-alpha1
>
> Attachments: ci_summary.html, result_details.tar.gz
>
>
> I am simulating running a cluster in Kubernetes and testing what happens when
> a pod goes down and is re created with a new ip address, the data is all
> stored on a detached volume so when the new pod is created all the old data
> for the node is reattached. In 4.0 this is handled correctly the node will
> come back up with the same hostid, tokens etc, just a new ip address and the
> cluster is healthy throughout.
>
> To simulate this I create a 3 node cluster on a local machine using 3
> loopback addresses
> 127.0.0.1
> 127.0.0.2
> 127.0.0.3
> I then run nodetool -p 7199 reconfigurecms datacenter1:3 --sync to create 3
> CMS nodes
> I then bring down 127.0.0.1 and replace the rpc_address and listen_address
> with 127.0.0.4 and re start the node. The node then hangs with this as the
> last error message:
> (8821185654333640868,9200867415893016118]=ForRange\{lastModified=Epoch{epoch=12},
>
> endpointsForRange=[Full(/127.0.0.1:7000,(8821185654333640868,9200867415893016118]),
> Full(/127.0.0.2:7000,(8821185654333640868,9200867415893016118]),
> Full(/127.0.0.3:7000,(8821185654333640868,9200867415893016118])]},
> }}}, lockedRanges=LockedRanges\{lastModified=Epoch{epoch=14}, locked={}}}.
> This can mean that this node is configured differently from CMS.
> java.lang.AssertionError: not aware of any cluster members
> at
> org.apache.cassandra.locator.NetworkTopologyStrategy.calculateNaturalReplicas(NetworkTopologyStrategy.java:233)
> at
> org.apache.cassandra.locator.CMSPlacementStrategy$DatacenterAware.reconfigure(CMSPlacementStrategy.java:119)
> at
> org.apache.cassandra.tcm.transformations.cms.PrepareCMSReconfiguration$Complex.execute(PrepareCMSReconfiguration.java:164)
> at
> org.apache.cassandra.tcm.log.LocalLog.processPendingInternal(LocalLog.java:429)
> at
> org.apache.cassandra.tcm.log.LocalLog$Async$AsyncRunnable.run(LocalLog.java:682)
> at
> org.apache.cassandra.concurrent.InfiniteLoopExecutor.loop(InfiniteLoopExecutor.java:121)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:829)
> WARN [GlobalLogFollower] 2023-12-21 11:11:34,408 LocalLog.java:693 -
> Stopping log processing on the node... All subsequent epochs will be ignored.
> org.apache.cassandra.tcm.log.LocalLog$StopProcessingException:
> java.lang.AssertionError: not aware of any cluster members
> at
> org.apache.cassandra.tcm.log.LocalLog.processPendingInternal(LocalLog.java:434)
> at
> org.apache.cassandra.tcm.log.LocalLog$Async$AsyncRunnable.run(LocalLog.java:682)
> at
> org.apache.cassandra.concurrent.InfiniteLoopExecutor.loop(InfiniteLoopExecutor.java:121)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:829)
> Caused by: java.lang.AssertionError: not aware of any cluster members
> at
> org.apache.cassandra.locator.NetworkTopologyStrategy.calculateNaturalReplicas(NetworkTopologyStrategy.java:233)
> at
> org.apache.cassandra.locator.CMSPlacementStrategy$DatacenterAware.reconfigure(CMSPlacementStrategy.java:119)
> at
> org.apache.cassandra.tcm.transformations.cms.PrepareCMSReconfiguration$Complex.execute(PrepareCMSReconfiguration.java:164)
> at
> org.apache.cassandra.tcm.log.LocalLog.processPendingInternal(LocalLog.java:429)
> ... 4 common frames omitted
--
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-18688) Limit Java runtime in 5.0 to JDK 11 and 17 in scripts; add a flag to opt out of that
[
https://issues.apache.org/jira/browse/CASSANDRA-18688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17801866#comment-17801866
]
shylaja kokoori commented on CASSANDRA-18688:
-
Thanks everyone for all the feedback you have given me, helped me understand
the process:)
I was on vacation last week, saw this just now. I do agree with what was
discussed.
I could change the messaging to say,
{code:java}
echo "If you would like to test with newer Java versions set
CASSANDRA_JDK_UNSUPPORTED to any value (for example,
CASSANDRA_JDK_UNSUPPORTED=true), unset the parameter for default behavior"{code}
Please let me know if everyone agrees & I will change it & remove the check for
'false' value
> Limit Java runtime in 5.0 to JDK 11 and 17 in scripts; add a flag to opt out
> of that
>
>
> Key: CASSANDRA-18688
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18688
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Ekaterina Dimitrova
>Assignee: shylaja kokoori
>Priority: Normal
> Fix For: 5.0.x, 5.x
>
> Time Spent: 3.5h
> Remaining Estimate: 0h
>
> Currently, we limit our users from building with non-default Java versions in
> build.xml.
> They can easily hack build.xml for test purposes with different versions.
> Cassandra–5.0 will be run on JDK11 and JDK17, but on startup, we do not limit
> people to those two, but only to everything >= 11. We should also put an
> upper limit of 17 in our Cassandra startup scripts. We can also add a flag to
> opt-out if someone wants to test with newer versions.
--
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=17801865#comment-17801865
]
Brandon Williams commented on CASSANDRA-17667:
--
This passed all the cqlsh tests. [~ahomoki] would you like to prepare the
other branches? I think this one will cover 5.0 and trunk, and another will
cover 4.0 and 4.1.
> 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.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] [Updated] (CASSANDRA-19202) A multi-line comment containing semi colon as the end of line throws error
[
https://issues.apache.org/jira/browse/CASSANDRA-19202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-19202:
-
Resolution: Duplicate
Status: Resolved (was: Triage Needed)
Marking this as dupe since the cause is the same.
> A multi-line comment containing semi colon as the end of line throws error
> --
>
> Key: CASSANDRA-19202
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19202
> Project: Cassandra
> Issue Type: Bug
>Reporter: Madhavan
>Priority: Normal
>
> {{Tested this with C* 4.0.latest.}}
> Let's say I've a comment section as follows, it fails today,
>
> {quote}{{/*}}
> {{ Licensed under the Apache License, Version 2.0 (the "License");}}
> {{ you may not use this file except in compliance with the License.}}
> {{ You may obtain a copy of the License at}}
> {{ [http://www.apache.org/licenses/LICENSE-2.0]}}
> {{ Unless required by applicable law or agreed to in writing, software}}
> {{ distributed under the License is distributed on an "AS IS" BASIS,}}
> {{ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.}}
> {{ See the License for the specific language governing permissions and}}
> {{ limitations under the License.}}
> {{*/}}
> {{SELECT * FROM origin.table_a;}}
> {quote}
> which throws an exception as follows when execute it as,
> {quote}
> cqlsh -f test.cql
> {quote}
>
> error,
> {quote}/tmp/test.cql:3:SyntaxException: line 2:64 mismatched character
> '' expecting '*'
> /tmp/test.cql:14:SyntaxException: line 1:0 no viable alternative at input
> 'you' ([you]...)
> {quote}
> This is because of having a semi-colon at the end of the [1st] line. If that
> same line ended as follows,
> {quote}Version 2.0 (the "License"); you
> {quote}
> This error will not occur.
--
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=17801847#comment-17801847
]
Brandon Williams commented on CASSANDRA-17667:
--
Hmm, I read the comment that said it removed the ability to have comments
inside statements and it seemed true, but I see now that it is not. I started
a CI run against trunk
[here|https://app.circleci.com/pipelines/github/driftx/cassandra/1423/workflows/b4e8d8e8-bb09-4475-be60-dd649761444c],
if that checks out then we can prepare the other 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.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-18939) Creating a SASI index after creating an SAI index breaks secondary index queries
[
https://issues.apache.org/jira/browse/CASSANDRA-18939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17801844#comment-17801844
]
Andres de la Peña commented on CASSANDRA-18939:
---
The fix looks good to me. That version on {{getBestIndexFor}} might have a
better name, such as {{{}getIndexesFor{}}}. After all, it's not returning the
best/first index for the expression, but the set of all the indexes for the
specified expression and class. Alternatively, it could keep the current name
and return the first index matching the arguments, like the other version of
{{{}getBestIndexFor{}}}.
> Creating a SASI index after creating an SAI index breaks secondary index
> queries
>
>
> Key: CASSANDRA-18939
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18939
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/2i Index
>Reporter: Jon Haddad
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> In the 5.0 branch, HEAD is e45c1092f91edd63591f562b2120ea6a5fd3edd5, I was
> able to break secondary indexes by doing the following:
> {code}
> cqlsh -e "create KEYSPACE test WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': 1};"
> cqlsh -e "create table test.blah (id int primary key, val text);"
> cqlsh -e "create INDEX on test.blah (val) using 'sai';"
> bin/nodetool flush
> ❯ cqlsh -e "SELECT * from test.blah WHERE val = 'something';"
> id | val
> +-
> (0 rows)
> cqlsh -e "create custom INDEX on test.blah (val) using
> 'org.apache.cassandra.index.sasi.SASIIndex';"
> Warnings :
> SASI indexes are experimental and are not recommended for production use.
> cqlsh -e "SELECT * from test.blah WHERE val = 'something';"
> :1:ReadFailure: Error from server: code=1300 [Replica(s) failed to
> execute read] message="Operation failed - received 0 responses and 1
> failures: UNKNOWN from localhost/127.0.0.1:7000" info={'consistency': 'ONE',
> 'required_responses': 1, 'received_responses': 0, 'failures': 1,
> 'error_code_map': {'127.0.0.1': '0x'}}
> {code}
> Server throws an exception:
> {code}
> ERROR [ReadStage-2] 2023-10-18 12:09:42,391 JVMStabilityInspector.java:70 -
> Exception in thread Thread[ReadStage-2,10,SharedPool]
> java.lang.RuntimeException: java.lang.ClassCastException: class
> org.apache.cassandra.index.sai.StorageAttachedIndex cannot be cast to class
> org.apache.cassandra.index.sasi.SASIIndex
> (org.apache.cassandra.index.sai.StorageAttachedIndex and
> org.apache.cassandra.index.sasi.SASIIndex are in unnamed module of loader
> 'app')
> at
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2585)
> at
> org.apache.cassandra.concurrent.ExecutionFailure$2.run(ExecutionFailure.java:163)
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:143)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:829)
> Caused by: java.lang.ClassCastException: class
> org.apache.cassandra.index.sai.StorageAttachedIndex cannot be cast to class
> org.apache.cassandra.index.sasi.SASIIndex
> (org.apache.cassandra.index.sai.StorageAttachedIndex and
> org.apache.cassandra.index.sasi.SASIIndex are in unnamed module of loader
> 'app')
> at
> org.apache.cassandra.index.sasi.plan.QueryController.getIndex(QueryController.java:96)
> at
> org.apache.cassandra.index.sasi.plan.Operation.analyzeGroup(Operation.java:282)
> at
> org.apache.cassandra.index.sasi.plan.Operation$Builder.complete(Operation.java:433)
> at
> org.apache.cassandra.index.sasi.plan.SASIIndexSearcher.analyze(SASIIndexSearcher.java:65)
> at
> org.apache.cassandra.index.sasi.plan.SASIIndexSearcher.search(SASIIndexSearcher.java:77)
> at
> org.apache.cassandra.db.ReadCommand.executeLocally(ReadCommand.java:425)
> at
> org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:2184)
> at org.apache.cassandra.service
> {code}
> Dropping the SASI index restores correct behavior.
--
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] [Assigned] (CASSANDRA-18498) Add option to sstablepartitions for aggregating stats
[
https://issues.apache.org/jira/browse/CASSANDRA-18498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña reassigned CASSANDRA-18498:
-
Assignee: (was: Andres de la Peña)
> Add option to sstablepartitions for aggregating stats
> -
>
> Key: CASSANDRA-18498
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18498
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/sstable
>Reporter: Andres de la Peña
>Priority: Normal
>
> The {{sstablepartitions}} offline tool added by CASSANDRA-8720 processes
> sstables one by one. If a partition is spread across multiple sstables, the
> tool will separately report the metrics of the partition fragment on each
> sstable. For example, if we are looking for partitions larger than 100MiB,
> and a partition has a 50MiB fragment in one table and 50MiB in another table,
> the partition won't be found.
> It would be useful to add a kind of {{--aggregate}} option to
> {{sstablepartitions}} so it aggregates the results of all the analyzed
> sstables that belong to the same 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-18999) Gossiper::hasMajorVersion3Nodes returns true when a cluster is upgrading patch version without Cassandra 3 nodes.
[
https://issues.apache.org/jira/browse/CASSANDRA-18999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17801833#comment-17801833
]
Stefan Miklosovic commented on CASSANDRA-18999:
---
I dont have such Circle plan. You need to ask somebody from Apple or DS.
> Gossiper::hasMajorVersion3Nodes returns true when a cluster is upgrading
> patch version without Cassandra 3 nodes.
> -
>
> Key: CASSANDRA-18999
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18999
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Distributed Metadata
>Reporter: Isaac Reath
>Assignee: Isaac Reath
>Priority: Low
> Labels: lhf
> Fix For: 4.0.x, 4.1.x, 5.0.x
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> When working on https://issues.apache.org/jira/browse/CASSANDRA-18968 we
> found that {{Gossiper::hasMajorVersion3Nodes}} will return true when the
> cluster is undergoing an upgrade from a patch version even if the cluster has
> no Cassandra 3 nodes in it.
> This can be reproduced by running this Gossiper test:
> {code:java}
> @Test
> public void
> testHasVersion3NodesShouldReturnFalseWhenNoVersion3NodesDetectedAndCassandra4UpgradeInProgress()
> throws Exception
> {
> Gossiper.instance.start(0);
> Gossiper.instance.expireUpgradeFromVersion();
> VersionedValue.VersionedValueFactory factory = new
> VersionedValue.VersionedValueFactory(null);
> EndpointState es = new EndpointState((HeartBeatState) null);
> es.addApplicationState(ApplicationState.RELEASE_VERSION,
> factory.releaseVersion(CURRENT_VERSION.toString()));
>
> Gossiper.instance.endpointStateMap.put(InetAddressAndPort.getByName("127.0.0.1"),
> es);
>
> Gossiper.instance.liveEndpoints.add(InetAddressAndPort.getByName("127.0.0.1"));
> es = new EndpointState((HeartBeatState) null);
> String previousPatchVersion = String.valueOf(CURRENT_VERSION.major) +
> '.' + (CURRENT_VERSION.minor) + '.' + (CURRENT_VERSION.patch - 1);
> es.addApplicationState(ApplicationState.RELEASE_VERSION,
> factory.releaseVersion(previousPatchVersion));
>
> Gossiper.instance.endpointStateMap.put(InetAddressAndPort.getByName("127.0.0.2"),
> es);
>
> Gossiper.instance.liveEndpoints.add(InetAddressAndPort.getByName("127.0.0.2"));
> assertFalse(Gossiper.instance.hasMajorVersion3Nodes());
> }
> {code}
> This seems to be because of
> [https://github.com/apache/cassandra/blob/cassandra-4.1/src/java/org/apache/cassandra/gms/Gossiper.java#L2360],
> where an upgrade in progress is possible but we are not upgrading from a
> lower family version (i.e from 4.1.1 to 4.1.2).
> From the comment in this function, it seems instead of the existing check, we
> would want to iterate over all known endpoints in gossip and return true if
> any of them do not have a version (similar to
> [https://github.com/apache/cassandra/blob/cassandra-4.1/src/java/org/apache/cassandra/gms/Gossiper.java#L227-L236)
>
> |https://github.com/apache/cassandra/blob/cassandra-4.1/src/java/org/apache/cassandra/gms/Gossiper.java#L227-L236).]
--
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-18999) Gossiper::hasMajorVersion3Nodes returns true when a cluster is upgrading patch version without Cassandra 3 nodes.
[
https://issues.apache.org/jira/browse/CASSANDRA-18999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17801825#comment-17801825
]
Paulo Motta commented on CASSANDRA-18999:
-
{quote}I have tested 5.0 already, links are in my last comments above. Have you
done some changes to it? I think 5.0 is fully covered, the only thing we need
is upgrade dtests for 4.0 and 4.1.
{quote}
The 5.0 version you submitted was based on the
[CASSANDRA-18999-5.0-hasMajVer3removal|https://github.com/apache/cassandra/compare/trunk...instaclustr:cassandra:CASSANDRA-18999-5.0-hasMajVer3removal]
branch which removes {{hasMajorVersion3Nodes}} from 5.0.
We need to submit CI for [this
branch|https://github.com/pauloricardomg/cassandra/tree/cassandra-5.0] where
{{hasMajorVersion3Nodes}} is fixed but not removed (the removal will be done on
CASSANDRA-19243).
We also need to submit upgrade tests for 4.0/4.1/5.0. Can you do this in
circle? If not I guess we'll have to wait until asf ci is bac.
> Gossiper::hasMajorVersion3Nodes returns true when a cluster is upgrading
> patch version without Cassandra 3 nodes.
> -
>
> Key: CASSANDRA-18999
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18999
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Distributed Metadata
>Reporter: Isaac Reath
>Assignee: Isaac Reath
>Priority: Low
> Labels: lhf
> Fix For: 4.0.x, 4.1.x, 5.0.x
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> When working on https://issues.apache.org/jira/browse/CASSANDRA-18968 we
> found that {{Gossiper::hasMajorVersion3Nodes}} will return true when the
> cluster is undergoing an upgrade from a patch version even if the cluster has
> no Cassandra 3 nodes in it.
> This can be reproduced by running this Gossiper test:
> {code:java}
> @Test
> public void
> testHasVersion3NodesShouldReturnFalseWhenNoVersion3NodesDetectedAndCassandra4UpgradeInProgress()
> throws Exception
> {
> Gossiper.instance.start(0);
> Gossiper.instance.expireUpgradeFromVersion();
> VersionedValue.VersionedValueFactory factory = new
> VersionedValue.VersionedValueFactory(null);
> EndpointState es = new EndpointState((HeartBeatState) null);
> es.addApplicationState(ApplicationState.RELEASE_VERSION,
> factory.releaseVersion(CURRENT_VERSION.toString()));
>
> Gossiper.instance.endpointStateMap.put(InetAddressAndPort.getByName("127.0.0.1"),
> es);
>
> Gossiper.instance.liveEndpoints.add(InetAddressAndPort.getByName("127.0.0.1"));
> es = new EndpointState((HeartBeatState) null);
> String previousPatchVersion = String.valueOf(CURRENT_VERSION.major) +
> '.' + (CURRENT_VERSION.minor) + '.' + (CURRENT_VERSION.patch - 1);
> es.addApplicationState(ApplicationState.RELEASE_VERSION,
> factory.releaseVersion(previousPatchVersion));
>
> Gossiper.instance.endpointStateMap.put(InetAddressAndPort.getByName("127.0.0.2"),
> es);
>
> Gossiper.instance.liveEndpoints.add(InetAddressAndPort.getByName("127.0.0.2"));
> assertFalse(Gossiper.instance.hasMajorVersion3Nodes());
> }
> {code}
> This seems to be because of
> [https://github.com/apache/cassandra/blob/cassandra-4.1/src/java/org/apache/cassandra/gms/Gossiper.java#L2360],
> where an upgrade in progress is possible but we are not upgrading from a
> lower family version (i.e from 4.1.1 to 4.1.2).
> From the comment in this function, it seems instead of the existing check, we
> would want to iterate over all known endpoints in gossip and return true if
> any of them do not have a version (similar to
> [https://github.com/apache/cassandra/blob/cassandra-4.1/src/java/org/apache/cassandra/gms/Gossiper.java#L227-L236)
>
> |https://github.com/apache/cassandra/blob/cassandra-4.1/src/java/org/apache/cassandra/gms/Gossiper.java#L227-L236).]
--
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-18839) Catch SSLHandshakeExceptions exceptions
[
https://issues.apache.org/jira/browse/CASSANDRA-18839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17801805#comment-17801805
]
Stefan Miklosovic edited comment on CASSANDRA-18839 at 1/2/24 2:32 PM:
---
[4.0 PR|https://github.com/apache/cassandra/pull/3015]
[4.1 PR|https://github.com/apache/cassandra/pull/3016]
[5.0 PR|https://github.com/apache/cassandra/pull/3017]
[trunk PR|https://github.com/apache/cassandra/pull/3018]
I created all branches. Patch from trunk applied quite cleanly to all older
branches but 4.0. It is colliding with this (1). In 4.0, I just logged that and
excluded call to ExceptionHandlers.logClientNetworkingExceptions because it
does not exist there yet.
As agreed, metrics are not anywhere but in trunk.
[~brandon.williams] [~maedhroz] does this make sense to you before I start to
build it all?
(1)
https://github.com/apache/cassandra/commit/d220d24994400d4342f5281f1a51514a6ae8c2fd
was (Author: smiklosovic):
[4.0 PR|https://github.com/apache/cassandra/pull/3015]
[4.1 PR|https://github.com/apache/cassandra/pull/3016]
[5.0 PR|https://github.com/apache/cassandra/pull/3017]
[trunk PR|https://github.com/apache/cassandra/pull/3018]
I created all branches. Patch from trunk applied quite cleanly to all older
branches but 4.0. It is colliding with this (1). In 4.0, I just logged that and
excluded call to ExceptionHandlers.logClientNetworkingExceptions because it
does not exist there yet.
As agreed, metrics are not anywhere but in trunk.
[~brandon.williams] does this make sense to you before I start to build it all?
(1)
https://github.com/apache/cassandra/commit/d220d24994400d4342f5281f1a51514a6ae8c2fd
> Catch SSLHandshakeExceptions exceptions
> ---
>
> Key: CASSANDRA-18839
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18839
> Project: Cassandra
> Issue Type: Improvement
> Components: Messaging/Client
>Reporter: Brad Schoening
>Assignee: James Hu
>Priority: Low
> Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x
>
> Time Spent: 3h 20m
> Remaining Estimate: 0h
>
> When SSL connection errors occur, they tend to flood the log with stack
> traces and lack the identity of the remote client IP. Instead,
> PreV5Handlers.decode() could catch SSLHandshakeException and provide a brief,
> more informative WARN level message instead of the verbose and mostly
> unhelpful stack trace.
> I.e.,
> {code:java}
> [WARN ] [epollEventLoopGroup-5-5] cluster_id=3 ip_address=10.0.0.1
> PreV5Handlers.java:261 - SSLHandshakeException in client networking with peer
> 10.0.0.10:9042 error:10d7:SSL
> routines:OPENSSL_internal:SSL_HANDSHAKE_FAILURE {code}
> instead of the current ones which flood the logs:
> {code:java}
> 2023-09-12 00:00:25,368 [WARN ] [epollEventLoopGroup-5-5] cluster_id=3
> ip_address=10.0.0.1 PreV5Handlers.java:261 - Unknown exception in client
> networking
> io.netty.handler.codec.DecoderException: javax.net.ssl.SSLHandshakeException:
> error:10d7:SSL routines:OPENSSL_internal:SSL_HANDSHAKE_FAILURE
> at
> io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:478)
> at
> io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:276)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
> at
> io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919)
> at
> io.netty.channel.epoll.AbstractEpollStreamChannel$EpollStreamUnsafe.epollInReady(AbstractEpollStreamChannel.java:795)
> at
> io.netty.channel.epoll.EpollEventLoop.processReady(EpollEventLoop.java:480)
> at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:378)
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
> at
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: javax.net.ssl.SSLHandshakeException: error:10d7:SSL
> routines:OPENSSL_internal:SSL_HANDSHAKE_FAILURE
[jira] [Updated] (CASSANDRA-18839) Catch SSLHandshakeExceptions exceptions
[
https://issues.apache.org/jira/browse/CASSANDRA-18839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-18839:
--
Fix Version/s: 5.0.x
5.x
(was: 5.0)
> Catch SSLHandshakeExceptions exceptions
> ---
>
> Key: CASSANDRA-18839
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18839
> Project: Cassandra
> Issue Type: Improvement
> Components: Messaging/Client
>Reporter: Brad Schoening
>Assignee: James Hu
>Priority: Low
> Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x
>
> Time Spent: 3h 20m
> Remaining Estimate: 0h
>
> When SSL connection errors occur, they tend to flood the log with stack
> traces and lack the identity of the remote client IP. Instead,
> PreV5Handlers.decode() could catch SSLHandshakeException and provide a brief,
> more informative WARN level message instead of the verbose and mostly
> unhelpful stack trace.
> I.e.,
> {code:java}
> [WARN ] [epollEventLoopGroup-5-5] cluster_id=3 ip_address=10.0.0.1
> PreV5Handlers.java:261 - SSLHandshakeException in client networking with peer
> 10.0.0.10:9042 error:10d7:SSL
> routines:OPENSSL_internal:SSL_HANDSHAKE_FAILURE {code}
> instead of the current ones which flood the logs:
> {code:java}
> 2023-09-12 00:00:25,368 [WARN ] [epollEventLoopGroup-5-5] cluster_id=3
> ip_address=10.0.0.1 PreV5Handlers.java:261 - Unknown exception in client
> networking
> io.netty.handler.codec.DecoderException: javax.net.ssl.SSLHandshakeException:
> error:10d7:SSL routines:OPENSSL_internal:SSL_HANDSHAKE_FAILURE
> at
> io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:478)
> at
> io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:276)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
> at
> io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919)
> at
> io.netty.channel.epoll.AbstractEpollStreamChannel$EpollStreamUnsafe.epollInReady(AbstractEpollStreamChannel.java:795)
> at
> io.netty.channel.epoll.EpollEventLoop.processReady(EpollEventLoop.java:480)
> at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:378)
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
> at
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: javax.net.ssl.SSLHandshakeException: error:10d7:SSL
> routines:OPENSSL_internal:SSL_HANDSHAKE_FAILURE
> at
> io.netty.handler.ssl.ReferenceCountedOpenSslEngine.shutdownWithError(ReferenceCountedOpenSslEngine.java:1031)
> at
> io.netty.handler.ssl.ReferenceCountedOpenSslEngine.sslReadErrorResult(ReferenceCountedOpenSslEngine.java:1321)
> at
> io.netty.handler.ssl.ReferenceCountedOpenSslEngine.unwrap(ReferenceCountedOpenSslEngine.java:1270)
> at
> io.netty.handler.ssl.ReferenceCountedOpenSslEngine.unwrap(ReferenceCountedOpenSslEngine.java:1346)
> at
> io.netty.handler.ssl.ReferenceCountedOpenSslEngine.unwrap(ReferenceCountedOpenSslEngine.java:1389)
> at
> io.netty.handler.ssl.SslHandler$SslEngineType$1.unwrap(SslHandler.java:206)
> at io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1387)
> at
> io.netty.handler.ssl.SslHandler.decodeNonJdkCompatible(SslHandler.java:1294)
> at io.netty.handler.ssl.SslHandler.decode(SslHandler.java:1331)
> at
> io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:508)
> at
> io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:447)
> ... 15 common frames omitted {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-18839) Catch SSLHandshakeExceptions exceptions
[
https://issues.apache.org/jira/browse/CASSANDRA-18839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17801805#comment-17801805
]
Stefan Miklosovic commented on CASSANDRA-18839:
---
[4.0 PR|https://github.com/apache/cassandra/pull/3015]
[4.1 PR|https://github.com/apache/cassandra/pull/3016]
[5.0 PR|https://github.com/apache/cassandra/pull/3017]
[trunk PR|https://github.com/apache/cassandra/pull/3018]
I created all branches. Patch from trunk applied quite cleanly to all older
branches but 4.0. It is colliding with this (1). In 4.0, I just logged that and
excluded call to ExceptionHandlers.logClientNetworkingExceptions because it
does not exist there yet.
As agreed, metrics are not anywhere but in trunk.
[~brandon.williams] does this make sense to you before I start to build it all?
(1)
https://github.com/apache/cassandra/commit/d220d24994400d4342f5281f1a51514a6ae8c2fd
> Catch SSLHandshakeExceptions exceptions
> ---
>
> Key: CASSANDRA-18839
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18839
> Project: Cassandra
> Issue Type: Improvement
> Components: Messaging/Client
>Reporter: Brad Schoening
>Assignee: James Hu
>Priority: Low
> Fix For: 4.0.x, 4.1.x, 5.0
>
> Time Spent: 3h 20m
> Remaining Estimate: 0h
>
> When SSL connection errors occur, they tend to flood the log with stack
> traces and lack the identity of the remote client IP. Instead,
> PreV5Handlers.decode() could catch SSLHandshakeException and provide a brief,
> more informative WARN level message instead of the verbose and mostly
> unhelpful stack trace.
> I.e.,
> {code:java}
> [WARN ] [epollEventLoopGroup-5-5] cluster_id=3 ip_address=10.0.0.1
> PreV5Handlers.java:261 - SSLHandshakeException in client networking with peer
> 10.0.0.10:9042 error:10d7:SSL
> routines:OPENSSL_internal:SSL_HANDSHAKE_FAILURE {code}
> instead of the current ones which flood the logs:
> {code:java}
> 2023-09-12 00:00:25,368 [WARN ] [epollEventLoopGroup-5-5] cluster_id=3
> ip_address=10.0.0.1 PreV5Handlers.java:261 - Unknown exception in client
> networking
> io.netty.handler.codec.DecoderException: javax.net.ssl.SSLHandshakeException:
> error:10d7:SSL routines:OPENSSL_internal:SSL_HANDSHAKE_FAILURE
> at
> io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:478)
> at
> io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:276)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
> at
> io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919)
> at
> io.netty.channel.epoll.AbstractEpollStreamChannel$EpollStreamUnsafe.epollInReady(AbstractEpollStreamChannel.java:795)
> at
> io.netty.channel.epoll.EpollEventLoop.processReady(EpollEventLoop.java:480)
> at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:378)
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
> at
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: javax.net.ssl.SSLHandshakeException: error:10d7:SSL
> routines:OPENSSL_internal:SSL_HANDSHAKE_FAILURE
> at
> io.netty.handler.ssl.ReferenceCountedOpenSslEngine.shutdownWithError(ReferenceCountedOpenSslEngine.java:1031)
> at
> io.netty.handler.ssl.ReferenceCountedOpenSslEngine.sslReadErrorResult(ReferenceCountedOpenSslEngine.java:1321)
> at
> io.netty.handler.ssl.ReferenceCountedOpenSslEngine.unwrap(ReferenceCountedOpenSslEngine.java:1270)
> at
> io.netty.handler.ssl.ReferenceCountedOpenSslEngine.unwrap(ReferenceCountedOpenSslEngine.java:1346)
> at
> io.netty.handler.ssl.ReferenceCountedOpenSslEngine.unwrap(ReferenceCountedOpenSslEngine.java:1389)
> at
> io.netty.handler.ssl.SslHandler$SslEngineType$1.unwrap(SslHandler.java:206)
> at io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1387)
> at
>
[jira] [Updated] (CASSANDRA-19120) local consistencies may get timeout if blocking read repair is sending the read repair mutation to other DC
[ https://issues.apache.org/jira/browse/CASSANDRA-19120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-19120: -- Bug Category: Parent values: Correctness(12982)Level 1 values: Consistency(12989) Complexity: Normal Component/s: Consistency/Repair Discovered By: User Report Fix Version/s: 4.0.x 4.1.x 5.0.x 5.x Reviewers: Stefan Miklosovic Severity: Normal Assignee: Runtian Liu Status: Open (was: Triage Needed) > local consistencies may get timeout if blocking read repair is sending the > read repair mutation to other DC > > > Key: CASSANDRA-19120 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19120 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Repair >Reporter: Runtian Liu >Assignee: Runtian Liu >Priority: Normal > Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x > > Attachments: image-2023-11-29-15-26-08-056.png, signature.asc > > Time Spent: 10m > Remaining Estimate: 0h > > For a two DCs cluster setup. When a new node is being added to DC1, for > blocking read repair triggered by local_quorum in DC1, it will require to > send read repair mutation to an extra node(1)(2). The selector for read > repair may select *ANY* node that has not been contacted before(3) instead of > selecting the DC1 nodes. If a node from DC2 is selected, this will cause 100% > timeout because of the bug described below: > When we initialized the latch(4) for blocking read repair, the shouldBlockOn > function will only return true for local nodes(5), the blockFor value will be > reduced if a local node doesn't require repair(6). The blockFor is same as > the number of read repair mutation sent out. But when the coordinator node > receives the response from the target nodes, the latch only count down for > nodes in same DC(7). The latch will wait till timeout and the read request > will timeout. > This can be reproduced if you have a constant load on a 3 + 3 cluster when > adding a node. If you have someway to trigger blocking read repair(maybe by > adding load using stress tool). If you use local_quorum consistency with a > constant read after write load in the same DC that you are adding node. You > will see read timeout issue from time to time because of the bug described > above > > I think for read repair when selecting the extra node to do repair, we should > prefer local nodes than the nodes from other region. Also, we need to fix the > latch part so even if we send mutation to the nodes in other DC, we don't get > a timeout. > (1)[https://github.com/apache/cassandra/blob/cassandra-4.0.11/src/java/org/apache/cassandra/locator/ReplicaPlans.java#L455] > (2)[https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/ConsistencyLevel.java#L183] > (3)[https://github.com/apache/cassandra/blob/cassandra-4.0.11/src/java/org/apache/cassandra/locator/ReplicaPlans.java#L458] > (4)[https://github.com/apache/cassandra/blob/cassandra-4.0.11/src/java/org/apache/cassandra/service/reads/repair/BlockingPartitionRepair.java#L96] > (5)[https://github.com/apache/cassandra/blob/cassandra-4.0.11/src/java/org/apache/cassandra/service/reads/repair/BlockingPartitionRepair.java#L71] > (6)[https://github.com/apache/cassandra/blob/cassandra-4.0.11/src/java/org/apache/cassandra/service/reads/repair/BlockingPartitionRepair.java#L88] > (7)[https://github.com/apache/cassandra/blob/cassandra-4.0.11/src/java/org/apache/cassandra/service/reads/repair/BlockingPartitionRepair.java#L113] > -- 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-19120) local consistencies may get timeout if blocking read repair is sending the read repair mutation to other DC
[ https://issues.apache.org/jira/browse/CASSANDRA-19120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17801785#comment-17801785 ] Stefan Miklosovic commented on CASSANDRA-19120: --- [~curlylrt] would you mind to prepare all other branches? 4.1, 5.0, trunk ... I think there are some minor differences between them. > local consistencies may get timeout if blocking read repair is sending the > read repair mutation to other DC > > > Key: CASSANDRA-19120 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19120 > Project: Cassandra > Issue Type: Bug >Reporter: Runtian Liu >Priority: Normal > Attachments: image-2023-11-29-15-26-08-056.png, signature.asc > > Time Spent: 10m > Remaining Estimate: 0h > > For a two DCs cluster setup. When a new node is being added to DC1, for > blocking read repair triggered by local_quorum in DC1, it will require to > send read repair mutation to an extra node(1)(2). The selector for read > repair may select *ANY* node that has not been contacted before(3) instead of > selecting the DC1 nodes. If a node from DC2 is selected, this will cause 100% > timeout because of the bug described below: > When we initialized the latch(4) for blocking read repair, the shouldBlockOn > function will only return true for local nodes(5), the blockFor value will be > reduced if a local node doesn't require repair(6). The blockFor is same as > the number of read repair mutation sent out. But when the coordinator node > receives the response from the target nodes, the latch only count down for > nodes in same DC(7). The latch will wait till timeout and the read request > will timeout. > This can be reproduced if you have a constant load on a 3 + 3 cluster when > adding a node. If you have someway to trigger blocking read repair(maybe by > adding load using stress tool). If you use local_quorum consistency with a > constant read after write load in the same DC that you are adding node. You > will see read timeout issue from time to time because of the bug described > above > > I think for read repair when selecting the extra node to do repair, we should > prefer local nodes than the nodes from other region. Also, we need to fix the > latch part so even if we send mutation to the nodes in other DC, we don't get > a timeout. > (1)[https://github.com/apache/cassandra/blob/cassandra-4.0.11/src/java/org/apache/cassandra/locator/ReplicaPlans.java#L455] > (2)[https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/ConsistencyLevel.java#L183] > (3)[https://github.com/apache/cassandra/blob/cassandra-4.0.11/src/java/org/apache/cassandra/locator/ReplicaPlans.java#L458] > (4)[https://github.com/apache/cassandra/blob/cassandra-4.0.11/src/java/org/apache/cassandra/service/reads/repair/BlockingPartitionRepair.java#L96] > (5)[https://github.com/apache/cassandra/blob/cassandra-4.0.11/src/java/org/apache/cassandra/service/reads/repair/BlockingPartitionRepair.java#L71] > (6)[https://github.com/apache/cassandra/blob/cassandra-4.0.11/src/java/org/apache/cassandra/service/reads/repair/BlockingPartitionRepair.java#L88] > (7)[https://github.com/apache/cassandra/blob/cassandra-4.0.11/src/java/org/apache/cassandra/service/reads/repair/BlockingPartitionRepair.java#L113] > -- 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-19118) Add support of vector type to COPY command
[
https://issues.apache.org/jira/browse/CASSANDRA-19118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17801780#comment-17801780
]
Andres de la Peña commented on CASSANDRA-19118:
---
I can't figure out what the purpose of that test branch is. In the meantime,
Python driver 3.29.0 has been released. I have opened CASSANDRA-19245 to use
that driver version, and I'm also updating pylib requirements in that ticket to
use the same driver version.
> Add support of vector type to COPY command
> --
>
> Key: CASSANDRA-19118
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19118
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/cqlsh
>Reporter: Szymon Miezal
>Assignee: Szymon Miezal
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
> Time Spent: 9h 40m
> Remaining Estimate: 0h
>
> Currently it's not possible to import rows with vector literals via {{COPY}}
> command.
> STR:
> * Create a table
> {code:sql}
> CREATE TABLE testcopyfrom (id text PRIMARY KEY, embedding_vector
> VECTOR
> {code}
> * Prepare csv file with sample data, for instance:
> {code:sql}
> 1,"[0.1, 0.2, 0.3, 0.4, 0.5, 0.6]"
> 2,"[-0.1, -0.2, -0.3, -0.4, -0.5, -0.6]" {code}
> * in cqlsh run
> {code:sql}
> COPY ks.testcopyfrom FROM data.csv
> {code}
> It will result in getting:
> {code:sql}
> TypeError: Received an argument of invalid type for column
> "embedding_vector". Expected: ,
> Got: ; (required argument is not a float){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-19120) local consistencies may get timeout if blocking read repair is sending the read repair mutation to other DC
[ https://issues.apache.org/jira/browse/CASSANDRA-19120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17801779#comment-17801779 ] Stefan Miklosovic commented on CASSANDRA-19120: --- This is still on my radar, I should return to this sometimes this or next week. > local consistencies may get timeout if blocking read repair is sending the > read repair mutation to other DC > > > Key: CASSANDRA-19120 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19120 > Project: Cassandra > Issue Type: Bug >Reporter: Runtian Liu >Priority: Normal > Attachments: image-2023-11-29-15-26-08-056.png, signature.asc > > Time Spent: 10m > Remaining Estimate: 0h > > For a two DCs cluster setup. When a new node is being added to DC1, for > blocking read repair triggered by local_quorum in DC1, it will require to > send read repair mutation to an extra node(1)(2). The selector for read > repair may select *ANY* node that has not been contacted before(3) instead of > selecting the DC1 nodes. If a node from DC2 is selected, this will cause 100% > timeout because of the bug described below: > When we initialized the latch(4) for blocking read repair, the shouldBlockOn > function will only return true for local nodes(5), the blockFor value will be > reduced if a local node doesn't require repair(6). The blockFor is same as > the number of read repair mutation sent out. But when the coordinator node > receives the response from the target nodes, the latch only count down for > nodes in same DC(7). The latch will wait till timeout and the read request > will timeout. > This can be reproduced if you have a constant load on a 3 + 3 cluster when > adding a node. If you have someway to trigger blocking read repair(maybe by > adding load using stress tool). If you use local_quorum consistency with a > constant read after write load in the same DC that you are adding node. You > will see read timeout issue from time to time because of the bug described > above > > I think for read repair when selecting the extra node to do repair, we should > prefer local nodes than the nodes from other region. Also, we need to fix the > latch part so even if we send mutation to the nodes in other DC, we don't get > a timeout. > (1)[https://github.com/apache/cassandra/blob/cassandra-4.0.11/src/java/org/apache/cassandra/locator/ReplicaPlans.java#L455] > (2)[https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/ConsistencyLevel.java#L183] > (3)[https://github.com/apache/cassandra/blob/cassandra-4.0.11/src/java/org/apache/cassandra/locator/ReplicaPlans.java#L458] > (4)[https://github.com/apache/cassandra/blob/cassandra-4.0.11/src/java/org/apache/cassandra/service/reads/repair/BlockingPartitionRepair.java#L96] > (5)[https://github.com/apache/cassandra/blob/cassandra-4.0.11/src/java/org/apache/cassandra/service/reads/repair/BlockingPartitionRepair.java#L71] > (6)[https://github.com/apache/cassandra/blob/cassandra-4.0.11/src/java/org/apache/cassandra/service/reads/repair/BlockingPartitionRepair.java#L88] > (7)[https://github.com/apache/cassandra/blob/cassandra-4.0.11/src/java/org/apache/cassandra/service/reads/repair/BlockingPartitionRepair.java#L113] > -- 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-18335) Push LocalSessions info logs to debug
[ https://issues.apache.org/jira/browse/CASSANDRA-18335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17801777#comment-17801777 ] Brandon Williams commented on CASSANDRA-18335: -- That is the offending one, but I don't think any of the messages at info are particularly useful. > Push LocalSessions info logs to debug > - > > Key: CASSANDRA-18335 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18335 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Repair >Reporter: Brandon Williams >Priority: Normal > Fix For: 4.0.x, 4.1.x, 5.x > > > I don't think these are particularly useful to have at info, but the impetus > for this ticket is specifically [this > message|https://github.com/apache/cassandra/blob/cassandra-4.0/src/java/org/apache/cassandra/repair/consistent/LocalSessions.java#L456] > during automatic cleanup about skipping deleting sessions that seems to > confuse or alarm people. -- 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-19215) "Query start time" in native transport request threads should be the task enqueue time
[ https://issues.apache.org/jira/browse/CASSANDRA-19215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17801775#comment-17801775 ] Brandon Williams commented on CASSANDRA-19215: -- [~samt] can you take a look? > "Query start time" in native transport request threads should be the task > enqueue time > -- > > Key: CASSANDRA-19215 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19215 > Project: Cassandra > Issue Type: Bug > Components: Messaging/Client >Reporter: Runtian Liu >Priority: Normal > Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x > > > Recently, our Cassandra 4.0.6 cluster experienced an outage due to a surge in > expensive traffic from the application side. This surge involved a large > volume of costly read queries, which took a considerable amount of time to > process on the server side. The client had timeout settings; if a request > timed out, it might trigger the sending of new requests. Since the server > nodes were overloaded, numerous nodes had hundreds of thousands of tasks > queued in the Native-Transport-Request pending queue. I expected that once > the application ceased sending requests, the server node would quickly return > to normal, as most requests in the queue were over half an hour old and > should have timed out rapidly, clearing the queue. However, it actually took > an hour to clear the native transport's pending queue, even with native > transport disabled. Upon examining the code, I noticed that for read/write > requests, the > [queryStartNanoTime|https://github.com/apache/cassandra/blob/cassandra-4.0/src/java/org/apache/cassandra/transport/Dispatcher.java#L78], > which determines if a request has timed out, only begins when the task > starts processing. This means that no matter how long a request has been > pending, it doesn't contribute to the timeout. I believe this is incorrect. > The timer should start when the Cassandra server receives the request or when > it enqueues the task, not when the request/task begins processing. This way, > an overloaded node with many pending tasks can quickly discard timed-out > requests and recover from an outage once new requests stop. -- 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-19215) "Query start time" in native transport request threads should be the task enqueue time
[ https://issues.apache.org/jira/browse/CASSANDRA-19215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-19215: - Bug Category: Parent values: Correctness(12982) Complexity: Normal Component/s: Messaging/Client Discovered By: User Report Fix Version/s: 4.0.x 4.1.x 5.0.x 5.x Severity: Normal Status: Open (was: Triage Needed) > "Query start time" in native transport request threads should be the task > enqueue time > -- > > Key: CASSANDRA-19215 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19215 > Project: Cassandra > Issue Type: Bug > Components: Messaging/Client >Reporter: Runtian Liu >Priority: Normal > Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x > > > Recently, our Cassandra 4.0.6 cluster experienced an outage due to a surge in > expensive traffic from the application side. This surge involved a large > volume of costly read queries, which took a considerable amount of time to > process on the server side. The client had timeout settings; if a request > timed out, it might trigger the sending of new requests. Since the server > nodes were overloaded, numerous nodes had hundreds of thousands of tasks > queued in the Native-Transport-Request pending queue. I expected that once > the application ceased sending requests, the server node would quickly return > to normal, as most requests in the queue were over half an hour old and > should have timed out rapidly, clearing the queue. However, it actually took > an hour to clear the native transport's pending queue, even with native > transport disabled. Upon examining the code, I noticed that for read/write > requests, the > [queryStartNanoTime|https://github.com/apache/cassandra/blob/cassandra-4.0/src/java/org/apache/cassandra/transport/Dispatcher.java#L78], > which determines if a request has timed out, only begins when the task > starts processing. This means that no matter how long a request has been > pending, it doesn't contribute to the timeout. I believe this is incorrect. > The timer should start when the Cassandra server receives the request or when > it enqueues the task, not when the request/task begins processing. This way, > an overloaded node with many pending tasks can quickly discard timed-out > requests and recover from an outage once new requests stop. -- 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-19187) nodetool assassinate may cause thread serialization for that node
[
https://issues.apache.org/jira/browse/CASSANDRA-19187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17801773#comment-17801773
]
Brandon Williams commented on CASSANDRA-19187:
--
I've started just the repeated test for 4.0
[here|https://app.circleci.com/pipelines/github/driftx/cassandra/1420/workflows/a9d53818-ee40-43f3-a9a3-e57087a5a0a7].
> nodetool assassinate may cause thread serialization for that node
> -
>
> Key: CASSANDRA-19187
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19187
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Membership
>Reporter: Runtian Liu
>Assignee: Runtian Liu
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0.x
>
>
> When assassinate an ip address that is not in the gossip map, a "corrupted"
> entry will be inserted into the gossip map.
> [(1)|https://github.com/apache/cassandra/blob/cassandra-4.0/src/java/org/apache/cassandra/gms/Gossiper.java#L810]
> For example, if we do "nodetool assassinate 10.1.1.1"
> we will get an entry like below by running "nodetool gossipinfo":
>
> {code:java}
> /10.1.1.1
> generation:1702006511
> heartbeat:
> STATUS:209516:LEFT,-8393921141401589197,1702265651923
> STATUS_WITH_PORT:209515:LEFT,-8393921141401589197,1702265651923
> TOKENS: not present {code}
>
> This entry in endpointStateMap will cause issue for
> [isUpgradingFromVersionLowerThan|https://github.com/apache/cassandra/blob/cassandra-4.0/src/java/org/apache/cassandra/gms/Gossiper.java#L2284]
> function. Because the
> [upgradeFromVersionSupplier|https://github.com/apache/cassandra/blob/cassandra-4.0/src/java/org/apache/cassandra/gms/Gossiper.java#L191]
> supplier will always set the
> [allHostsHaveKnownVersion|https://github.com/apache/cassandra/blob/cassandra-4.0/src/java/org/apache/cassandra/gms/Gossiper.java#L216]
> flag to false so no memoized value will be returned. The "get" function will
> always require a lock from this
> [line|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/utils/ExpiringMemoizingSupplier.java#L66].
> If application is using "fetchAll", the native-transport-requests thread will
> hit this
> [line|https://github.com/apache/cassandra/blob/cassandra-4.0/src/java/org/apache/cassandra/db/filter/ColumnFilter.java#L574].
> This means all the native-transport-requests thread is serialized, also, the
> lock is shared by GossipStage threads. It means if a node in a cluster with
> the corrupted gossip map is restart, the node will run into this problem.
> To fix the issue,
> # Why we want to add a dummy entry for nodetool assassinate if the endpoint
> is not in the map anymore. Should we do nothing or throw exception if the
> node is not in the gossip map anymore?
> # Before checking if a version is null, we should make sure the node is not
> a dead node. A decommissioned node, a left node should not be considered part
> of the cluster anymore when calculating "upgradeInProgressPossible"
>
--
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-19245) Upgrade Python driver to 3.29.0
[
https://issues.apache.org/jira/browse/CASSANDRA-19245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-19245:
--
Test and Documentation Plan:
||PR||CI||
|[5.0
|https://github.com/apache/cassandra/pull/3013]|[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/3363/workflows/3f95c0e0-19a9-4615-9171-2f05513bf8ab]
[j17|https://app.circleci.com/pipelines/github/adelapena/cassandra/3363/workflows/4928c32c-b0f2-4a2b-a47a-daaab702f995]|
|[trunk|https://github.com/apache/cassandra/pull/3014]|[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/3364/workflows/94246a00-0160-45a6-8c5f-f0ae3bd9d235]
[j17|https://app.circleci.com/pipelines/github/adelapena/cassandra/3364/workflows/c4ba6ff1-cf6c-48f8-988b-edeff6c84587]|
Status: Patch Available (was: Open)
> Upgrade Python driver to 3.29.0
> ---
>
> Key: CASSANDRA-19245
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19245
> Project: Cassandra
> Issue Type: Task
> Components: Feature/Vector Search, Tool/cqlsh
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The version of the Python driver that is used by cqlsh (3.28.0) doesn't
> correctly support vectors of variable-width types. Wrong deserialization can
> either fail with an exception or silently provide wrong results. For example:
> {code:java}
> cqlsh:k> CREATE TABLE t (k int PRIMARY KEY, v vector);
> cqlsh:k> INSERT INTO t(k, v) VALUES (1,
> [23452352356235654634567437463767365783768, 3]);
> cqlsh:k> SELECT * FROM t;
> k | v
> ---+--
> 1 | [289729430, -1001073214]}}
> {code}
> The most recent driver at the moment (3.29.0) still doesn't support this kind
> of vector, but it always fails with a proper message instead of dangerously
> providing wrong results, thanks to
> [PYTHON-1371|https://datastax-oss.atlassian.net/browse/PYTHON-1371].
--
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-19245) Upgrade Python driver to 3.29.0
[
https://issues.apache.org/jira/browse/CASSANDRA-19245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-19245:
--
Fix Version/s: 5.0-rc
5.x
> Upgrade Python driver to 3.29.0
> ---
>
> Key: CASSANDRA-19245
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19245
> Project: Cassandra
> Issue Type: Task
> Components: Feature/Vector Search, Tool/cqlsh
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The version of the Python driver that is used by cqlsh (3.28.0) doesn't
> correctly support vectors of variable-width types. Wrong deserialization can
> either fail with an exception or silently provide wrong results. For example:
> {code:java}
> cqlsh:k> CREATE TABLE t (k int PRIMARY KEY, v vector);
> cqlsh:k> INSERT INTO t(k, v) VALUES (1,
> [23452352356235654634567437463767365783768, 3]);
> cqlsh:k> SELECT * FROM t;
> k | v
> ---+--
> 1 | [289729430, -1001073214]}}
> {code}
> The most recent driver at the moment (3.29.0) still doesn't support this kind
> of vector, but it always fails with a proper message instead of dangerously
> providing wrong results, thanks to
> [PYTHON-1371|https://datastax-oss.atlassian.net/browse/PYTHON-1371].
--
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-18999) Gossiper::hasMajorVersion3Nodes returns true when a cluster is upgrading patch version without Cassandra 3 nodes.
[
https://issues.apache.org/jira/browse/CASSANDRA-18999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17801762#comment-17801762
]
Stefan Miklosovic commented on CASSANDRA-18999:
---
[~paulo] I have tested 5.0 already, links are in my last comments above. Have
you done some changes to it? I think 5.0 is fully covered, the only thing we
need is upgrade dtests for 4.0 and 4.1.
> Gossiper::hasMajorVersion3Nodes returns true when a cluster is upgrading
> patch version without Cassandra 3 nodes.
> -
>
> Key: CASSANDRA-18999
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18999
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Distributed Metadata
>Reporter: Isaac Reath
>Assignee: Isaac Reath
>Priority: Low
> Labels: lhf
> Fix For: 4.0.x, 4.1.x, 5.0.x
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> When working on https://issues.apache.org/jira/browse/CASSANDRA-18968 we
> found that {{Gossiper::hasMajorVersion3Nodes}} will return true when the
> cluster is undergoing an upgrade from a patch version even if the cluster has
> no Cassandra 3 nodes in it.
> This can be reproduced by running this Gossiper test:
> {code:java}
> @Test
> public void
> testHasVersion3NodesShouldReturnFalseWhenNoVersion3NodesDetectedAndCassandra4UpgradeInProgress()
> throws Exception
> {
> Gossiper.instance.start(0);
> Gossiper.instance.expireUpgradeFromVersion();
> VersionedValue.VersionedValueFactory factory = new
> VersionedValue.VersionedValueFactory(null);
> EndpointState es = new EndpointState((HeartBeatState) null);
> es.addApplicationState(ApplicationState.RELEASE_VERSION,
> factory.releaseVersion(CURRENT_VERSION.toString()));
>
> Gossiper.instance.endpointStateMap.put(InetAddressAndPort.getByName("127.0.0.1"),
> es);
>
> Gossiper.instance.liveEndpoints.add(InetAddressAndPort.getByName("127.0.0.1"));
> es = new EndpointState((HeartBeatState) null);
> String previousPatchVersion = String.valueOf(CURRENT_VERSION.major) +
> '.' + (CURRENT_VERSION.minor) + '.' + (CURRENT_VERSION.patch - 1);
> es.addApplicationState(ApplicationState.RELEASE_VERSION,
> factory.releaseVersion(previousPatchVersion));
>
> Gossiper.instance.endpointStateMap.put(InetAddressAndPort.getByName("127.0.0.2"),
> es);
>
> Gossiper.instance.liveEndpoints.add(InetAddressAndPort.getByName("127.0.0.2"));
> assertFalse(Gossiper.instance.hasMajorVersion3Nodes());
> }
> {code}
> This seems to be because of
> [https://github.com/apache/cassandra/blob/cassandra-4.1/src/java/org/apache/cassandra/gms/Gossiper.java#L2360],
> where an upgrade in progress is possible but we are not upgrading from a
> lower family version (i.e from 4.1.1 to 4.1.2).
> From the comment in this function, it seems instead of the existing check, we
> would want to iterate over all known endpoints in gossip and return true if
> any of them do not have a version (similar to
> [https://github.com/apache/cassandra/blob/cassandra-4.1/src/java/org/apache/cassandra/gms/Gossiper.java#L227-L236)
>
> |https://github.com/apache/cassandra/blob/cassandra-4.1/src/java/org/apache/cassandra/gms/Gossiper.java#L227-L236).]
--
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-19245) Upgrade Python driver to 3.29.0
[
https://issues.apache.org/jira/browse/CASSANDRA-19245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-19245:
--
Change Category: Semantic
Complexity: Low Hanging Fruit
Status: Open (was: Triage Needed)
> Upgrade Python driver to 3.29.0
> ---
>
> Key: CASSANDRA-19245
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19245
> Project: Cassandra
> Issue Type: Task
> Components: Feature/Vector Search, Tool/cqlsh
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
>
> The version of the Python driver that is used by cqlsh (3.28.0) doesn't
> correctly support vectors of variable-width types. Wrong deserialization can
> either fail with an exception or silently provide wrong results. For example:
> {code:java}
> cqlsh:k> CREATE TABLE t (k int PRIMARY KEY, v vector);
> cqlsh:k> INSERT INTO t(k, v) VALUES (1,
> [23452352356235654634567437463767365783768, 3]);
> cqlsh:k> SELECT * FROM t;
> k | v
> ---+--
> 1 | [289729430, -1001073214]}}
> {code}
> The most recent driver at the moment (3.29.0) still doesn't support this kind
> of vector, but it always fails with a proper message instead of dangerously
> providing wrong results, thanks to
> [PYTHON-1371|https://datastax-oss.atlassian.net/browse/PYTHON-1371].
--
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-19245) Upgrade Python driver to 3.29.0
Andres de la Peña created CASSANDRA-19245:
-
Summary: Upgrade Python driver to 3.29.0
Key: CASSANDRA-19245
URL: https://issues.apache.org/jira/browse/CASSANDRA-19245
Project: Cassandra
Issue Type: Task
Components: Feature/Vector Search, Tool/cqlsh
Reporter: Andres de la Peña
Assignee: Andres de la Peña
The version of the Python driver that is used by cqlsh (3.28.0) doesn't
correctly support vectors of variable-width types. Wrong deserialization can
either fail with an exception or silently provide wrong results. For example:
{code:java}
cqlsh:k> CREATE TABLE t (k int PRIMARY KEY, v vector);
cqlsh:k> INSERT INTO t(k, v) VALUES (1,
[23452352356235654634567437463767365783768, 3]);
cqlsh:k> SELECT * FROM t;
k | v
---+--
1 | [289729430, -1001073214]}}
{code}
The most recent driver at the moment (3.29.0) still doesn't support this kind
of vector, but it always fails with a proper message instead of dangerously
providing wrong results, thanks to
[PYTHON-1371|https://datastax-oss.atlassian.net/browse/PYTHON-1371].
--
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-18939) Creating a SASI index after creating an SAI index breaks secondary index queries
[
https://issues.apache.org/jira/browse/CASSANDRA-18939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-18939:
--
Test and Documentation Plan: CI
Status: Patch Available (was: In Progress)
https://github.com/apache/cassandra/pull/3011
> Creating a SASI index after creating an SAI index breaks secondary index
> queries
>
>
> Key: CASSANDRA-18939
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18939
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/2i Index
>Reporter: Jon Haddad
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In the 5.0 branch, HEAD is e45c1092f91edd63591f562b2120ea6a5fd3edd5, I was
> able to break secondary indexes by doing the following:
> {code}
> cqlsh -e "create KEYSPACE test WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': 1};"
> cqlsh -e "create table test.blah (id int primary key, val text);"
> cqlsh -e "create INDEX on test.blah (val) using 'sai';"
> bin/nodetool flush
> ❯ cqlsh -e "SELECT * from test.blah WHERE val = 'something';"
> id | val
> +-
> (0 rows)
> cqlsh -e "create custom INDEX on test.blah (val) using
> 'org.apache.cassandra.index.sasi.SASIIndex';"
> Warnings :
> SASI indexes are experimental and are not recommended for production use.
> cqlsh -e "SELECT * from test.blah WHERE val = 'something';"
> :1:ReadFailure: Error from server: code=1300 [Replica(s) failed to
> execute read] message="Operation failed - received 0 responses and 1
> failures: UNKNOWN from localhost/127.0.0.1:7000" info={'consistency': 'ONE',
> 'required_responses': 1, 'received_responses': 0, 'failures': 1,
> 'error_code_map': {'127.0.0.1': '0x'}}
> {code}
> Server throws an exception:
> {code}
> ERROR [ReadStage-2] 2023-10-18 12:09:42,391 JVMStabilityInspector.java:70 -
> Exception in thread Thread[ReadStage-2,10,SharedPool]
> java.lang.RuntimeException: java.lang.ClassCastException: class
> org.apache.cassandra.index.sai.StorageAttachedIndex cannot be cast to class
> org.apache.cassandra.index.sasi.SASIIndex
> (org.apache.cassandra.index.sai.StorageAttachedIndex and
> org.apache.cassandra.index.sasi.SASIIndex are in unnamed module of loader
> 'app')
> at
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2585)
> at
> org.apache.cassandra.concurrent.ExecutionFailure$2.run(ExecutionFailure.java:163)
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:143)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:829)
> Caused by: java.lang.ClassCastException: class
> org.apache.cassandra.index.sai.StorageAttachedIndex cannot be cast to class
> org.apache.cassandra.index.sasi.SASIIndex
> (org.apache.cassandra.index.sai.StorageAttachedIndex and
> org.apache.cassandra.index.sasi.SASIIndex are in unnamed module of loader
> 'app')
> at
> org.apache.cassandra.index.sasi.plan.QueryController.getIndex(QueryController.java:96)
> at
> org.apache.cassandra.index.sasi.plan.Operation.analyzeGroup(Operation.java:282)
> at
> org.apache.cassandra.index.sasi.plan.Operation$Builder.complete(Operation.java:433)
> at
> org.apache.cassandra.index.sasi.plan.SASIIndexSearcher.analyze(SASIIndexSearcher.java:65)
> at
> org.apache.cassandra.index.sasi.plan.SASIIndexSearcher.search(SASIIndexSearcher.java:77)
> at
> org.apache.cassandra.db.ReadCommand.executeLocally(ReadCommand.java:425)
> at
> org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:2184)
> at org.apache.cassandra.service
> {code}
> Dropping the SASI index restores correct behavior.
--
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-18796) Optionally fail when a non-partition-restricted query is issued against a storage-attached index
[ https://issues.apache.org/jira/browse/CASSANDRA-18796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-18796: -- Status: Ready to Commit (was: Review In Progress) > Optionally fail when a non-partition-restricted query is issued against a > storage-attached index > > > Key: CASSANDRA-18796 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18796 > Project: Cassandra > Issue Type: Improvement > Components: Feature/2i Index, Feature/SAI, Local/Compaction/LCS >Reporter: Caleb Rackliffe >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 5.0-rc, 5.x > > Time Spent: 14.5h > Remaining Estimate: 0h > > With LCS, we will have potentially thousands of SSTables for a given user > table. Storage-attached also means SSTable-attached, and searching thousands > of attached indexes is not going to scale well at all locally, due to the > sheer number of searches and amount of postings list merging involved. We > should have a guardrail to prohibit this by default. > Partition-restricted queries, the use-case SAI is broadly designed for, > should be very efficient. > UPDATE: The consensus from the discussion below is that we'll add two > guardrails here. One is simply for whether we'll allow > non-partition-restricted 2i queries. The other is a warn/fail threshold pair > for the number of SSTable indexes read locally on a query. -- 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-18796) Optionally fail when a non-partition-restricted query is issued against a storage-attached index
[ https://issues.apache.org/jira/browse/CASSANDRA-18796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17801722#comment-17801722 ] Stefan Miklosovic commented on CASSANDRA-18796: --- [5.0 j17|https://app.circleci.com/pipelines/github/instaclustr/cassandra/3696/workflows/0557b89e-590b-432c-a850-844616f36abe] clean [5.0 j11|https://app.circleci.com/pipelines/github/instaclustr/cassandra/3696/workflows/e009b344-bef8-4708-87bb-fff84f4f8ce8] the only failure is CASSANDRA-18641 [trunk j17|https://app.circleci.com/pipelines/github/instaclustr/cassandra/3695/workflows/7420ba73-9889-4fa7-8f2a-d246a6f43045] failures are CASSANDRA-18360, CASSANDRA-19101 [trunk j11|https://app.circleci.com/pipelines/github/instaclustr/cassandra/3695/workflows/f4c8b6b9-38a9-4522-8f16-4ace82f4d60d] Other failures for trunk are of NativeTransportEncryptionOptionsTest. They all pass locally. > Optionally fail when a non-partition-restricted query is issued against a > storage-attached index > > > Key: CASSANDRA-18796 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18796 > Project: Cassandra > Issue Type: Improvement > Components: Feature/2i Index, Feature/SAI, Local/Compaction/LCS >Reporter: Caleb Rackliffe >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 5.0-rc, 5.x > > Time Spent: 14.5h > Remaining Estimate: 0h > > With LCS, we will have potentially thousands of SSTables for a given user > table. Storage-attached also means SSTable-attached, and searching thousands > of attached indexes is not going to scale well at all locally, due to the > sheer number of searches and amount of postings list merging involved. We > should have a guardrail to prohibit this by default. > Partition-restricted queries, the use-case SAI is broadly designed for, > should be very efficient. > UPDATE: The consensus from the discussion below is that we'll add two > guardrails here. One is simply for whether we'll allow > non-partition-restricted 2i queries. The other is a warn/fail threshold pair > for the number of SSTable indexes read locally on a query. -- 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-19126) Streaming appears to be incompatible with different storage_compatibility_mode settings
[
https://issues.apache.org/jira/browse/CASSANDRA-19126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17799836#comment-17799836
]
Jacek Lewandowski edited comment on CASSANDRA-19126 at 1/2/24 8:40 AM:
---
By running tests, I realized I don't know what the Scrubber should do, which
resulting format should it choose? Maybe we need to provide that explicitly?
what do you think?
EDIT: After thinking about it a bit, Scrubber is not actually something to be
run outside of the server, or at least, it would be pretty rare. Therefore, it
should take the server configuration. I'll also consider letting the user
provide the target format/version through the command line.
was (Author: jlewandowski):
By running tests, I realized I don't know what the Scrubber should do, which
resulting format should it choose? Maybe we need to provide that explicitly?
what do you think?
> Streaming appears to be incompatible with different
> storage_compatibility_mode settings
> ---
>
> Key: CASSANDRA-19126
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19126
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Streaming, Legacy/Streaming and Messaging,
> Messaging/Internode, Tool/bulk load
>Reporter: Branimir Lambov
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
>
> In particular, SSTableLoader appears to be incompatible with
> storage_compatibility_mode: NONE, which manifests as a failure of
> {{org.apache.cassandra.distributed.test.SSTableLoaderEncryptionOptionsTest}}
> when the flag is turned on (found during CASSANDRA-18753 testing). Setting
> {{storage_compatibility_mode: NONE}} in the tool configuration yaml does not
> help (according to the docs, this setting is not picked up).
> This is likely a bigger problem as the acceptable streaming version for C* 5
> is 12 only in legacy mode and 13 only in none, i.e. two C* 5 nodes do not
> appear to be able to stream with each other if their setting for the
> compatibility mode is different.
--
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
