svn commit: r58695 - /release/cassandra/4.1.0/redhat/
Author: mck Date: Tue Dec 13 07:34:40 2022 New Revision: 58695 Log: Apache Cassandra 4.1.0 redhat artifacts Removed: release/cassandra/4.1.0/redhat/ - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
svn commit: r58694 - /release/cassandra/4.1.0/debian/
Author: mck Date: Tue Dec 13 07:31:56 2022 New Revision: 58694 Log: Apache Cassandra 4.1.0 debian artifacts Removed: release/cassandra/4.1.0/debian/ - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
svn commit: r58693 - /dev/cassandra/4.1.0/ /release/cassandra/4.1.0/
Author: mck Date: Tue Dec 13 07:27:05 2022 New Revision: 58693 Log: Apache Cassandra 4.1.0 release Added: release/cassandra/4.1.0/ - copied from r58692, dev/cassandra/4.1.0/ Removed: dev/cassandra/4.1.0/ - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] tag 4.1.0-tentative deleted (was f9e033f519)
This is an automated email from the ASF dual-hosted git repository. mck pushed a change to tag 4.1.0-tentative in repository https://gitbox.apache.org/repos/asf/cassandra.git *** WARNING: tag 4.1.0-tentative was deleted! *** was f9e033f519 Prepare debian changelog for 4.1.0 The revisions that were on this tag are still contained in other references; therefore, this change does not discard any commits from the repository. - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] annotated tag cassandra-4.1.0 created (now 1e41b338c5)
This is an automated email from the ASF dual-hosted git repository. mck pushed a change to annotated tag cassandra-4.1.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git at 1e41b338c5 (tag) tagging f9e033f519c14596da4dc954875756a69aea4e78 (commit) replaces cassandra-4.1-rc1 by Mick Semb Wever on Tue Dec 13 08:25:47 2022 +0100 - Log - Apache Cassandra 4.1.0 release --- No new revisions were added by this update. - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated (f0ad7eadbe -> 2e1695426b)
This is an automated email from the ASF dual-hosted git repository. mck pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git from f0ad7eadbe Merge branch 'cassandra-4.1' into trunk add f9e033f519 Prepare debian changelog for 4.1.0 new 2e1695426b Merge branch 'cassandra-4.1' into trunk The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Merge branch 'cassandra-4.1' into trunk
This is an automated email from the ASF dual-hosted git repository. mck pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 2e1695426bf363113f5ace90b08ae5d1fade40b1 Merge: f0ad7eadbe f9e033f519 Author: Mick Semb Wever AuthorDate: Tue Dec 13 08:22:47 2022 +0100 Merge branch 'cassandra-4.1' into trunk * cassandra-4.1: Prepare debian changelog for 4.1.0 - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-4.1 updated (81c616826a -> f9e033f519)
This is an automated email from the ASF dual-hosted git repository. mck pushed a change to branch cassandra-4.1 in repository https://gitbox.apache.org/repos/asf/cassandra.git from 81c616826a Fix ContentionStrategy backoff and Clock.waitUntil add f9e033f519 Prepare debian changelog for 4.1.0 No new revisions were added by this update. Summary of changes: debian/changelog | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18063) WEBSITE - 4.1 Homepage update and blog post "Apache Cassandra 4.1: Stable, Cloud-Native, Strongly Consistent, and Scale"
[
https://issues.apache.org/jira/browse/CASSANDRA-18063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17646445#comment-17646445
]
Erick Ramirez commented on CASSANDRA-18063:
---
I've been notified by [~mck] that the announcement needs to be ready for
tomorrow 09:00 PST. I've updated the dates in the blog index + post to
{{{}December 13{}}}.
> WEBSITE - 4.1 Homepage update and blog post "Apache Cassandra 4.1: Stable,
> Cloud-Native, Strongly Consistent, and Scale"
>
>
> Key: CASSANDRA-18063
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18063
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Blog
>Reporter: Diogenese Topper
>Assignee: Erick Ramirez
>Priority: Normal
> Fix For: NA
>
> Attachments: c18063-01-homepage.png, c18063-02-blog-index.png,
> c18063-03-blog-post.png
>
>
> This ticket is to capture the work associated with publishing the November
> 2022 homepage update and blog on 4.1.
> If this blog cannot be published by the noted publish date on the blog,
> please contact me, suggest changes, or correct the date when possible in the
> pull request for the appropriate time that the blog will go live (on both the
> blog.adoc and the blog post's file).
--
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-15046) Add a "history" command to cqlsh. Perhaps "show history"?
[ https://issues.apache.org/jira/browse/CASSANDRA-15046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17646394#comment-17646394 ] Yundi Chen commented on CASSANDRA-15046: Hi [~e.dimitrova], Working on sending in the patch in the next few days! Thanks for checking in > Add a "history" command to cqlsh. Perhaps "show history"? > -- > > Key: CASSANDRA-15046 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15046 > Project: Cassandra > Issue Type: Improvement > Components: CQL/Interpreter >Reporter: Wes Peters >Assignee: Yundi Chen >Priority: Low > Labels: lhf > Fix For: 4.x > > Time Spent: 10m > Remaining Estimate: 0h > > I was trying to capture some create key space and create table commands from > a running cqlsh, and found there was no equivalent to the '\s' history > command in Postgres' psql shell. It's a great tool for figuring out what you > were doing yesterday. -- 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-18104) Major Performance degradation of Casandara 4.0.7 against Casandra 3.11.14
[ https://issues.apache.org/jira/browse/CASSANDRA-18104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17646384#comment-17646384 ] Sreedhar J commented on CASSANDRA-18104: !screenshot-1.png! Please see the attached screenshot. I did a bit of analysis on the output when you have TRACING ON. I warmed up my system by running the query 100 times. Then collected the output from 30 iterations of the query. I did this for both versions. I calculated the time between each 'activity' in the tracing to get a sense for which activities were taking longest. I then calculated the average, min, max time spent on each across all 30 iterations I compared them between 3.11.14 and 4.0.7 to see if I could spot a consistent place where Cassandra was spending more time on 4.0.7. The numbers vary greatly each time I run the query, but here's a table that shows the data: If you look at #10, you can see that the Average is 617 microseconds higher, the minimum value is 435 microseconds higher and the maximums are 4170 higher. > Major Performance degradation of Casandara 4.0.7 against Casandra 3.11.14 > > > Key: CASSANDRA-18104 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18104 > Project: Cassandra > Issue Type: Bug >Reporter: Sreedhar J >Priority: Urgent > Attachments: 3.11.14.txt, 4.0.7.txt, mailboxes_snapshot.zip, > query30.txt, screenshot-1.png > > > Our application uses Casandra 3.11.x and has lot of security vulnerabilities > which are addressed in 4.0.x. So we have upgraded the Casandra to 4.0.7 > and our performance tests have shown aorund 20% degradation compare to > 3.11.x > We are now able to reproduce the same performance degradation using the > standalone queries. Here are the steps. > 1. Expand Cassandra 3.11.14 tarball and 4.0.7 tarball to different folders > 2. Import the attached data from the snapshot (mailboxes_snapshot.zip) into > each Cassandra instance, see schema.cql for CQL for creating the required > table and indexes before import > 3. With CQLSH run the following query several times with TRACING ON and > PAGING OFF against both versions of Cassandra: select * from > mailbox.mailboxes where mbx_id= 6c57da2e-7ddd-4984-be62-105415e6b48a; > 4. Compare results > IWe ran the target query 30 times. Here's the average times to run the query: > 3.11.14 - 19400.77 > 4.0.7 - 34906.03 -- 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-18104) Major Performance degradation of Casandara 4.0.7 against Casandra 3.11.14
[ https://issues.apache.org/jira/browse/CASSANDRA-18104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sreedhar J updated CASSANDRA-18104: --- Attachment: screenshot-1.png > Major Performance degradation of Casandara 4.0.7 against Casandra 3.11.14 > > > Key: CASSANDRA-18104 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18104 > Project: Cassandra > Issue Type: Bug >Reporter: Sreedhar J >Priority: Urgent > Attachments: 3.11.14.txt, 4.0.7.txt, mailboxes_snapshot.zip, > query30.txt, screenshot-1.png > > > Our application uses Casandra 3.11.x and has lot of security vulnerabilities > which are addressed in 4.0.x. So we have upgraded the Casandra to 4.0.7 > and our performance tests have shown aorund 20% degradation compare to > 3.11.x > We are now able to reproduce the same performance degradation using the > standalone queries. Here are the steps. > 1. Expand Cassandra 3.11.14 tarball and 4.0.7 tarball to different folders > 2. Import the attached data from the snapshot (mailboxes_snapshot.zip) into > each Cassandra instance, see schema.cql for CQL for creating the required > table and indexes before import > 3. With CQLSH run the following query several times with TRACING ON and > PAGING OFF against both versions of Cassandra: select * from > mailbox.mailboxes where mbx_id= 6c57da2e-7ddd-4984-be62-105415e6b48a; > 4. Compare results > IWe ran the target query 30 times. Here's the average times to run the query: > 3.11.14 - 19400.77 > 4.0.7 - 34906.03 -- 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-18110) Streaming fails during multiple concurrent host replacements
[
https://issues.apache.org/jira/browse/CASSANDRA-18110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17646377#comment-17646377
]
Jon Meredith commented on CASSANDRA-18110:
--
No success reproducing this issue in a test environment still.
Given that all attempts have failed to reproduce and have completed
investigating our theories how this could happen without finding anything so
far, this should not block the release.
Downgrading severity to Normal and will update this ticket with any future
findings.
> Streaming fails during multiple concurrent host replacements
>
>
> Key: CASSANDRA-18110
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18110
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Bootstrap and Decommission
>Reporter: Jon Meredith
>Assignee: Jon Meredith
>Priority: Normal
> Fix For: 4.1
>
>
> Running four concurrent host replacements on a 4.1.0 development cluster has
> repeatably failed to complete bootstrap with all four hosts failing bootsrrap
> and staying in JOINING, logging the message.
> {code:java}
> ERROR 2022-12-07T21:15:48,860 [main]
> org.apache.cassandra.service.StorageService:2019 - Error while waiting on
> bootstrap to complete. Bootstrap will have to be restarted.
> {code}
> Bootstrap fails as the the FileStreamTasks on the streaming followers
> encounter an EOF while transmitting the files.
> {code:java}
> ERROR 2022-12-07T15:49:39,164 [NettyStreaming-Outbound-/1.2.3.4.7000:2]
> org.apache.cassandra.streaming.StreamSession:718 - [Stream
> #8d313690-7674-11ed-813f-95c261b64a82] Streaming error occurred on session
> with peer 1.2.3.4:7000 through 1.2.3.4:40292
> org.apache.cassandra.net.AsyncChannelOutputPlus$FlushException: The channel
> this output stream was writing to has been closed
>at
> org.apache.cassandra.net.AsyncChannelOutputPlus.propagateFailedFlush(AsyncChannelOutputPlus.java:200)
> ~[cassandra.jar]
>at
> org.apache.cassandra.net.AsyncChannelOutputPlus.waitUntilFlushed(AsyncChannelOutputPlus.java:158)
> ~[cassandra.jar]
>at
> org.apache.cassandra.net.AsyncChannelOutputPlus.waitForSpace(AsyncChannelOutputPlus.java:140)
> ~[cassandra.jar]
>at
> org.apache.cassandra.net.AsyncChannelOutputPlus.beginFlush(AsyncChannelOutputPlus.java:97)
> ~[cassandra.jar]
>at
> org.apache.cassandra.net.AsyncStreamingOutputPlus.lambda$writeToChannel$0(AsyncStreamingOutputPlus.java:124)
> ~[cassandra.jar]
>at
> org.apache.cassandra.db.streaming.CassandraCompressedStreamWriter.lambda$write$0(CassandraCompressedStreamWriter.java:89)
> ~[cassandra.jar]
>at
> org.apache.cassandra.net.AsyncStreamingOutputPlus.writeToChannel(AsyncStreamingOutputPlus.java:120)
> ~[cassandra.jar]
>at
> org.apache.cassandra.db.streaming.CassandraCompressedStreamWriter.write(CassandraCompressedStreamWriter.java:88)
> ~[cassandra.jar]
>at
> org.apache.cassandra.db.streaming.CassandraOutgoingFile.write(CassandraOutgoingFile.java:177)
> ~[cassandra.jar]
>at
> org.apache.cassandra.streaming.messages.OutgoingStreamMessage.serialize(OutgoingStreamMessage.java:87)
> ~[cassandra.jar]
>at
> org.apache.cassandra.streaming.messages.OutgoingStreamMessage$1.serialize(OutgoingStreamMessage.java:45)
> ~[cassandra.jar]
>at
> org.apache.cassandra.streaming.messages.OutgoingStreamMessage$1.serialize(OutgoingStreamMessage.java:34)
> ~[cassandra.jar]
>at
> org.apache.cassandra.streaming.messages.StreamMessage.serialize(StreamMessage.java:39)
> ~[cassandra.jar]
>at
> org.apache.cassandra.streaming.async.StreamingMultiplexedChannel$FileStreamTask.run(StreamingMultiplexedChannel.java:311)
> [cassandra.jar]
>at
> org.apache.cassandra.concurrent.FutureTask$1.call(FutureTask.java:96)
> [cassandra.jar]
>at org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:61)
> [cassandra.jar]
>at org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:71)
> [cassandra.jar]
>at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> [?:?]
>at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> [?:?]
>at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> [netty-all-4.1.58.Final.jar:4.1.58.Final]
>at java.lang.Thread.run(Thread.java:829) [?:?]
>Suppressed: java.nio.channels.ClosedChannelException
>at
> org.apache.cassandra.net.AsyncStreamingOutputPlus.doFlush(AsyncStreamingOutputPlus.java:82)
> ~[cassandra.jar]
>at
> org.apache.cassandra.net.AsyncChannelOutputPlus.flush(AsyncChannelOutputPlus.java:229)
>
[jira] [Updated] (CASSANDRA-18110) Streaming fails during multiple concurrent host replacements
[
https://issues.apache.org/jira/browse/CASSANDRA-18110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jon Meredith updated CASSANDRA-18110:
-
Severity: Normal (was: Critical)
> Streaming fails during multiple concurrent host replacements
>
>
> Key: CASSANDRA-18110
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18110
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Bootstrap and Decommission
>Reporter: Jon Meredith
>Assignee: Jon Meredith
>Priority: Normal
> Fix For: 4.1
>
>
> Running four concurrent host replacements on a 4.1.0 development cluster has
> repeatably failed to complete bootstrap with all four hosts failing bootsrrap
> and staying in JOINING, logging the message.
> {code:java}
> ERROR 2022-12-07T21:15:48,860 [main]
> org.apache.cassandra.service.StorageService:2019 - Error while waiting on
> bootstrap to complete. Bootstrap will have to be restarted.
> {code}
> Bootstrap fails as the the FileStreamTasks on the streaming followers
> encounter an EOF while transmitting the files.
> {code:java}
> ERROR 2022-12-07T15:49:39,164 [NettyStreaming-Outbound-/1.2.3.4.7000:2]
> org.apache.cassandra.streaming.StreamSession:718 - [Stream
> #8d313690-7674-11ed-813f-95c261b64a82] Streaming error occurred on session
> with peer 1.2.3.4:7000 through 1.2.3.4:40292
> org.apache.cassandra.net.AsyncChannelOutputPlus$FlushException: The channel
> this output stream was writing to has been closed
>at
> org.apache.cassandra.net.AsyncChannelOutputPlus.propagateFailedFlush(AsyncChannelOutputPlus.java:200)
> ~[cassandra.jar]
>at
> org.apache.cassandra.net.AsyncChannelOutputPlus.waitUntilFlushed(AsyncChannelOutputPlus.java:158)
> ~[cassandra.jar]
>at
> org.apache.cassandra.net.AsyncChannelOutputPlus.waitForSpace(AsyncChannelOutputPlus.java:140)
> ~[cassandra.jar]
>at
> org.apache.cassandra.net.AsyncChannelOutputPlus.beginFlush(AsyncChannelOutputPlus.java:97)
> ~[cassandra.jar]
>at
> org.apache.cassandra.net.AsyncStreamingOutputPlus.lambda$writeToChannel$0(AsyncStreamingOutputPlus.java:124)
> ~[cassandra.jar]
>at
> org.apache.cassandra.db.streaming.CassandraCompressedStreamWriter.lambda$write$0(CassandraCompressedStreamWriter.java:89)
> ~[cassandra.jar]
>at
> org.apache.cassandra.net.AsyncStreamingOutputPlus.writeToChannel(AsyncStreamingOutputPlus.java:120)
> ~[cassandra.jar]
>at
> org.apache.cassandra.db.streaming.CassandraCompressedStreamWriter.write(CassandraCompressedStreamWriter.java:88)
> ~[cassandra.jar]
>at
> org.apache.cassandra.db.streaming.CassandraOutgoingFile.write(CassandraOutgoingFile.java:177)
> ~[cassandra.jar]
>at
> org.apache.cassandra.streaming.messages.OutgoingStreamMessage.serialize(OutgoingStreamMessage.java:87)
> ~[cassandra.jar]
>at
> org.apache.cassandra.streaming.messages.OutgoingStreamMessage$1.serialize(OutgoingStreamMessage.java:45)
> ~[cassandra.jar]
>at
> org.apache.cassandra.streaming.messages.OutgoingStreamMessage$1.serialize(OutgoingStreamMessage.java:34)
> ~[cassandra.jar]
>at
> org.apache.cassandra.streaming.messages.StreamMessage.serialize(StreamMessage.java:39)
> ~[cassandra.jar]
>at
> org.apache.cassandra.streaming.async.StreamingMultiplexedChannel$FileStreamTask.run(StreamingMultiplexedChannel.java:311)
> [cassandra.jar]
>at
> org.apache.cassandra.concurrent.FutureTask$1.call(FutureTask.java:96)
> [cassandra.jar]
>at org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:61)
> [cassandra.jar]
>at org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:71)
> [cassandra.jar]
>at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> [?:?]
>at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> [?:?]
>at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> [netty-all-4.1.58.Final.jar:4.1.58.Final]
>at java.lang.Thread.run(Thread.java:829) [?:?]
>Suppressed: java.nio.channels.ClosedChannelException
>at
> org.apache.cassandra.net.AsyncStreamingOutputPlus.doFlush(AsyncStreamingOutputPlus.java:82)
> ~[cassandra.jar]
>at
> org.apache.cassandra.net.AsyncChannelOutputPlus.flush(AsyncChannelOutputPlus.java:229)
> ~[cassandra.jar]
>at
> org.apache.cassandra.net.AsyncChannelOutputPlus.close(AsyncChannelOutputPlus.java:248)
> ~[cassandra.jar]
>at
> org.apache.cassandra.streaming.async.NettyStreamingChannel$1.close(NettyStreamingChannel.java:141)
> ~[cassandra.jar]
>at
>
[cassandra] branch cep-15-accord updated (33f670bab6 -> 80a8dc69ef)
This is an automated email from the ASF dual-hosted git repository. dcapwell pushed a change to branch cep-15-accord in repository https://gitbox.apache.org/repos/asf/cassandra.git from 33f670bab6 CEP-15: Multi-Partition Transaction CQL Support (Alpha) add 5509a1bfb6 Ninja for CASSANDRA-17719: Adder/Substraction should return NULL if either the current or the user value are NULL add 6a1b857ef5 Ninja for CASSANDRA-17719: Add @Simulate(with = MONITORS) to MultiReadFuture to get simulator working add 80a8dc69ef Ninja for CASSANDRA-17719: When a reference sees a null, return Constants.NULL_VALUE rather than try to parse it No new revisions were added by this update. Summary of changes: src/java/org/apache/cassandra/cql3/Constants.java | 6 -- src/java/org/apache/cassandra/service/accord/txn/TxnRead.java | 3 +++ .../apache/cassandra/service/accord/txn/TxnReferenceOperation.java | 2 ++ .../org/apache/cassandra/service/accord/txn/TxnReferenceValue.java | 2 +- 4 files changed, 10 insertions(+), 3 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18099) Use checked casts when reading vints as ints
[ https://issues.apache.org/jira/browse/CASSANDRA-18099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17646363#comment-17646363 ] Caleb Rackliffe commented on CASSANDRA-18099: - +1 (assuming we resolve nits around documentation, import order, etc.) > Use checked casts when reading vints as ints > > > Key: CASSANDRA-18099 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18099 > Project: Cassandra > Issue Type: Improvement > Components: Messaging/Client, Messaging/Internode, Messaging/Thrift >Reporter: Ariel Weisberg >Assignee: Ariel Weisberg >Priority: Normal > > Add some safety and a new convenience method to make clear that getting an > int can be done using a checked method. No need to import a separate class. -- 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-17719) CEP-15: Multi-Partition Transaction CQL Support (Alpha)
[
https://issues.apache.org/jira/browse/CASSANDRA-17719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-17719:
Source Control Link:
https://github.com/apache/cassandra/commit/33f670bab67643b4ac0220e4be99c23b3104080e
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Committed to {{cep-15-accord}} branch.
> CEP-15: Multi-Partition Transaction CQL Support (Alpha)
> ---
>
> Key: CASSANDRA-17719
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17719
> Project: Cassandra
> Issue Type: New Feature
> Components: Accord, CQL/Syntax
>Reporter: Blake Eggleston
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: NA
>
> Time Spent: 12h 10m
> Remaining Estimate: 0h
>
> The dev list thread regarding CQL transaction support seems to have converged
> on a syntax.
>
> The thread is here:
> [https://lists.apache.org/thread/5sds3968mnnk42c24pvgwphg4qvo2xk0]
>
> The message proposing the syntax ultimately agreed on is here:
> [https://lists.apache.org/thread/y289tczngj68bqpoo7gkso3bzmtf86pl]
>
> I'll describe my understanding of the agreed syntax here for, but I'd
> suggest reading through the thread.
>
> The example query is this:
> {code:sql}
> BEGIN TRANSACTION
> LET car = (SELECT miles_driven, is_running FROM cars WHERE model=’pinto’);
> LET user = (SELECT miles_driven FROM users WHERE name=’Blake’);
> SELECT car.is_running, car.miles_driven;
> IF car.is_running THEN
> UPDATE users SET miles_driven = user.miles_driven + 30 WHERE name='blake';
> UPDATE cars SET miles_driven = car.miles_driven + 30 WHERE model='pinto';
> END IF
> COMMIT TRANSACTION
> {code}
> Sections are described below, and we want to require the statement enforces
> an order on the different types of clauses. First, assignments, then
> select(s), then conditional updates. This may be relaxed in the future, but
> is meant to prevent users from interleaving updates and assignments and
> expecting read your own write behavior that we don't want to support in v1.
> h3. Reference assignments
> {code:sql}
> LET car = (SELECT miles_driven, is_running FROM cars WHERE
> model=’pinto’){code}
>
> The first part is basically assigning the result of a SELECT statement to a
> named reference that can be used in updates/conditions and be returned to the
> user. Tuple names belong to a global scope and must not clash with other LET
> statements or update statements (more on that in the updates section). Also,
> the select statement must either be a point read, with all primary key
> columns defined, or explicitly set a limit of 1.
> h3. Selection
> Data to returned to client. Currently, we're only supporting a single select
> statement. Either a normal select statement, or one returning values assigned
> by LET statements as shown in the example. Ultimately we'll want to support
> multiple select statements and returning the results to the client. Although
> that will require a protocol change.
> h3. Updates
> Normal inserts/updates/deletes with the following extensions:
> * Inserts and updates can reference values assigned earlier in the statement
> * Updates can reference their own columns:
> {code:java}
> miles_driven = miles_driven + 30{code}
> - or -
> {code:java}
> miles_driven += 30{code}
> These will of course need to generate any required reads behind the scenes.
> There's no precedence of table vs reference names, so if a relevant column
> name and reference name conflict, the query needs to fail to parse.
> h3. If blocks
> {code:sql}
> IF THEN
> ;
> ;
> END IF
> {code}
>
> For v1, we only need to support a single condition in the format above. In
> the future, we'd like to support multiple branches with multiple conditions
> like:
>
> {code:sql}
> IF THEN
> ;
> ;
> ELSE IF THEN
> ;
> ELSE
> ;
> END IF
> {code}
>
> h3. Conditions
> Comparisons of value references to literals or other references. IS NULL / IS
> NOT NULL also needs to be supported. Multiple comparisons need to be
> supported, but v1 only needs to support AND'ing them together.
> {code:java}
> Supported operators: =, !=, >, >=, <, <=, IS NULL, IS NOT NULL
> = 5
> IS NOT NULL
> IF car IS NOT NULL AND car.miles_driven > 30
> IF car.miles_driven = user.miles_driven{code}
> (Note that {{IS[ NOT ]NULL}} can apply to both tuple references and
> individually dereferenced columns.)
> CONTAINS and CONTAINS KEY require indexed collections, and will not be
> supported in v1.
> h3. Implementation notes
> I have a proof of concept I'd created to demo the initially proposed syntax
> here: [https://github.com/bdeggleston/cassandra/tree/accord-cql-poc], It
> could be used as
[jira] [Updated] (CASSANDRA-17719) CEP-15: Multi-Partition Transaction CQL Support (Alpha)
[
https://issues.apache.org/jira/browse/CASSANDRA-17719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-17719:
Status: Ready to Commit (was: Review In Progress)
> CEP-15: Multi-Partition Transaction CQL Support (Alpha)
> ---
>
> Key: CASSANDRA-17719
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17719
> Project: Cassandra
> Issue Type: New Feature
> Components: Accord, CQL/Syntax
>Reporter: Blake Eggleston
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: NA
>
> Time Spent: 12h 10m
> Remaining Estimate: 0h
>
> The dev list thread regarding CQL transaction support seems to have converged
> on a syntax.
>
> The thread is here:
> [https://lists.apache.org/thread/5sds3968mnnk42c24pvgwphg4qvo2xk0]
>
> The message proposing the syntax ultimately agreed on is here:
> [https://lists.apache.org/thread/y289tczngj68bqpoo7gkso3bzmtf86pl]
>
> I'll describe my understanding of the agreed syntax here for, but I'd
> suggest reading through the thread.
>
> The example query is this:
> {code:sql}
> BEGIN TRANSACTION
> LET car = (SELECT miles_driven, is_running FROM cars WHERE model=’pinto’);
> LET user = (SELECT miles_driven FROM users WHERE name=’Blake’);
> SELECT car.is_running, car.miles_driven;
> IF car.is_running THEN
> UPDATE users SET miles_driven = user.miles_driven + 30 WHERE name='blake';
> UPDATE cars SET miles_driven = car.miles_driven + 30 WHERE model='pinto';
> END IF
> COMMIT TRANSACTION
> {code}
> Sections are described below, and we want to require the statement enforces
> an order on the different types of clauses. First, assignments, then
> select(s), then conditional updates. This may be relaxed in the future, but
> is meant to prevent users from interleaving updates and assignments and
> expecting read your own write behavior that we don't want to support in v1.
> h3. Reference assignments
> {code:sql}
> LET car = (SELECT miles_driven, is_running FROM cars WHERE
> model=’pinto’){code}
>
> The first part is basically assigning the result of a SELECT statement to a
> named reference that can be used in updates/conditions and be returned to the
> user. Tuple names belong to a global scope and must not clash with other LET
> statements or update statements (more on that in the updates section). Also,
> the select statement must either be a point read, with all primary key
> columns defined, or explicitly set a limit of 1.
> h3. Selection
> Data to returned to client. Currently, we're only supporting a single select
> statement. Either a normal select statement, or one returning values assigned
> by LET statements as shown in the example. Ultimately we'll want to support
> multiple select statements and returning the results to the client. Although
> that will require a protocol change.
> h3. Updates
> Normal inserts/updates/deletes with the following extensions:
> * Inserts and updates can reference values assigned earlier in the statement
> * Updates can reference their own columns:
> {code:java}
> miles_driven = miles_driven + 30{code}
> - or -
> {code:java}
> miles_driven += 30{code}
> These will of course need to generate any required reads behind the scenes.
> There's no precedence of table vs reference names, so if a relevant column
> name and reference name conflict, the query needs to fail to parse.
> h3. If blocks
> {code:sql}
> IF THEN
> ;
> ;
> END IF
> {code}
>
> For v1, we only need to support a single condition in the format above. In
> the future, we'd like to support multiple branches with multiple conditions
> like:
>
> {code:sql}
> IF THEN
> ;
> ;
> ELSE IF THEN
> ;
> ELSE
> ;
> END IF
> {code}
>
> h3. Conditions
> Comparisons of value references to literals or other references. IS NULL / IS
> NOT NULL also needs to be supported. Multiple comparisons need to be
> supported, but v1 only needs to support AND'ing them together.
> {code:java}
> Supported operators: =, !=, >, >=, <, <=, IS NULL, IS NOT NULL
> = 5
> IS NOT NULL
> IF car IS NOT NULL AND car.miles_driven > 30
> IF car.miles_driven = user.miles_driven{code}
> (Note that {{IS[ NOT ]NULL}} can apply to both tuple references and
> individually dereferenced columns.)
> CONTAINS and CONTAINS KEY require indexed collections, and will not be
> supported in v1.
> h3. Implementation notes
> I have a proof of concept I'd created to demo the initially proposed syntax
> here: [https://github.com/bdeggleston/cassandra/tree/accord-cql-poc], It
> could be used as a starting point, a source of ideas for approaches, or not
> used at all. The main thing to keep in mind is that value references prevent
> creating read commands and mutations
[jira] [Commented] (CASSANDRA-17221) Add Math functions
[
https://issues.apache.org/jira/browse/CASSANDRA-17221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17646320#comment-17646320
]
Ekaterina Dimitrova commented on CASSANDRA-17221:
-
For the record, seems to me that lazy consensus was reached on the mailing list
[here|https://lists.apache.org/thread/k3q4f2fdmr5j4vjx1drqct4075sv38xt]
Thank you all!
> Add Math functions
> ---
>
> Key: CASSANDRA-17221
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17221
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Syntax
>Reporter: Benjamin Lerer
>Assignee: Simon Chess
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Fix For: 4.2
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> We should add native Maths functions for the most common operations:
> * {{abs\(x)}} returns the absolute value of the x
> * {{exp\(x)}} returns the value of e (the base of natural logarithms) raised
> to the power of x
> * {{log\(x)}} returns the natural logarithm (base e) of x
> * {{log10\(x)}} returns the base-10 logarithm of x
> * {{round\(x)}} returns the closest integer to x
> +Additional information for newcomers:+
> The new functions should be put in a new class {{MathFcts}} similar to
> {{TimeFcts}}.
> The {{MathsFcts.all()}} method should be called in
> {{SystemKeyspace.functions}}
> The unit tests for the functions should be put in a {{MathFctsTest}} similar
> to {{TimeFctsTest}}
--
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-17178) CEP-10: Simulator Java11 Support
[
https://issues.apache.org/jira/browse/CASSANDRA-17178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17646319#comment-17646319
]
Ekaterina Dimitrova commented on CASSANDRA-17178:
-
+1 on the PR, thank you.
{quote}org.apache.cassandra.simulator.test.ShortPaxosSimulationTest was flakey
in J8 but not j11
{quote}
As long as it is flaky also without the patch and we follow up by opening a
ticket for the community to look at the flaky test, all good :)
Please get rid of the hunk messages pre-commit as I mentioned in Slack.
Regenerating the patches without any actual changes to them will get rid of
that list of ugly warnings when people run .generate.sh with the flags. Just
try to apply them to the files to see they do not change anything after the
regeneration. Thanks
Easy recipe(copy-paste) to do that:
{code:java}
#. apply old patches (with hunk messages)
patch -o config-2_1.yml.MIDRES config-2_1.yml config-2_1.yml.mid_res.patch
patch -o config-2_1.yml.HIGHRES config-2_1.yml config-2_1.yml.high_res.patch
#. generate new patches
diff -u config-2_1.yml config-2_1.yml.HIGHRES > config-2_1.yml.high_res.patch
diff -u config-2_1.yml config-2_1.yml.MIDRES > config-2_1.yml.mid_res.patch
#. verify that the new patches generate the same files and cleanup
./generate.sh -a
{code}
> CEP-10: Simulator Java11 Support
>
>
> Key: CASSANDRA-17178
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17178
> Project: Cassandra
> Issue Type: Task
> Components: Test/fuzz
>Reporter: Benedict Elliott Smith
>Assignee: David Capwell
>Priority: Normal
> Fix For: NA
>
>
> Java11 introduces new protection domains for package private methods, so that
> classes loaded with different class loaders may not access each others’
> package private methods, regardless of the package they are declared within.
> There are differences within the JDK also, and there may be byte weaving
> targets that need updating (ThreadLocalRandom was one that has been handled)
--
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-15458) CQL: Unable to escape single quote in a map attribute
[
https://issues.apache.org/jira/browse/CASSANDRA-15458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yaman Ziadeh reassigned CASSANDRA-15458:
Assignee: Yaman Ziadeh
> CQL: Unable to escape single quote in a map attribute
> ---
>
> Key: CASSANDRA-15458
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15458
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter, CQL/Semantics
>Reporter: Abhijeet Singh
>Assignee: Yaman Ziadeh
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Attachments: cass-screen.png
>
>
> h3. Overview
> For {{text}} attributes, CQL allows escaping single quote [using additional
> single
> quote|http://mail-archives.apache.org/mod_mbox/cassandra-user/201108.mbox/%3c20110803152250.294...@gmx.net%3E].
> But applying the same syntax for a {{map}} attribute does not
> work. Inconsistent behavior was observed between {{text}} datatype and
> {{map}} datatype.
> h3. CQL semantic proposal
> Cassandra (CQL) should apply same escaping semantics on {{text}} and
> text-within-map {{map}} datatypes.
> h3. Reproducing the bug:
> CREATE query:
> {code:java}
> CREATE TABLE university.test (id int, data map, PRIMARY KEY
> (id));{code}
> INSERT query:
> {code:java}
> insert into university.test (id, data) values(1, {1:'I''m newb'});{code}
> On running the aforementioned INSERT query, Cassandra inserts and returns
> {{\{1: 'I''m newb'}}} while the expected result is {{\{1: 'I'm newb'}}}
> h3. Technical details
> OS: CentOS 7
> Kernel: Linux 3.10.0-1062.9.1.el7.x86_64
> Cassandra version: 3.11.5
> Screenshot: [Output after SELECT query|https://i.stack.imgur.com/PLAan.png]
>
> +Additional information for newcomers:+
> The issue seems to come from the ANTLR Lexer logic for {{STRING_LITERAL}}. A
> unit test should also be added in {{SelectTest}}
--
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
[cassandra-builds] branch trunk updated: ninja: python 3.11 needs newer pip
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra-builds.git The following commit(s) were added to refs/heads/trunk by this push: new 4963b12 ninja: python 3.11 needs newer pip 4963b12 is described below commit 4963b12c7dc96a6e5a1bf276b3cb87c97bc43871 Author: Brandon Williams AuthorDate: Mon Dec 12 13:04:49 2022 -0600 ninja: python 3.11 needs newer pip --- docker/testing/ubuntu2004_j11.docker | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/docker/testing/ubuntu2004_j11.docker b/docker/testing/ubuntu2004_j11.docker index 45e5ec7..11a360d 100644 --- a/docker/testing/ubuntu2004_j11.docker +++ b/docker/testing/ubuntu2004_j11.docker @@ -50,7 +50,8 @@ RUN python2.7 -m pip install --upgrade pip RUN python3.6 -m pip install --upgrade pip RUN python3.7 -m pip install --upgrade pip RUN python3.8 -m pip install --upgrade pip -RUN python3.11 -m pip install --upgrade pip +# 3.11 needs newer pip +RUN curl -sS https://bootstrap.pypa.io/get-pip.py | python3.11 # solves warning: "jemalloc shared library could not be preloaded to speed up memory allocations" RUN export DEBIAN_FRONTEND=noninteractive && \ - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18099) Use checked casts when reading vints as ints
[ https://issues.apache.org/jira/browse/CASSANDRA-18099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Rackliffe updated CASSANDRA-18099: Reviewers: Caleb Rackliffe, David Capwell (was: David Capwell) > Use checked casts when reading vints as ints > > > Key: CASSANDRA-18099 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18099 > Project: Cassandra > Issue Type: Improvement > Components: Messaging/Client, Messaging/Internode, Messaging/Thrift >Reporter: Ariel Weisberg >Assignee: Ariel Weisberg >Priority: Normal > > Add some safety and a new convenience method to make clear that getting an > int can be done using a checked method. No need to import a separate class. -- 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-18058) In-memory index and query path
[ https://issues.apache.org/jira/browse/CASSANDRA-18058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17646267#comment-17646267 ] Caleb Rackliffe commented on CASSANDRA-18058: - [~adelapena] I'll start today or tomorrow, most likely. I've been wrapping up CASSANDRA-17719. > In-memory index and query path > -- > > Key: CASSANDRA-18058 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18058 > Project: Cassandra > Issue Type: New Feature > Components: Feature/SAI >Reporter: Mike Adamson >Assignee: Mike Adamson >Priority: Normal > Fix For: 5.x > > > An in-memory index using the in-memory trie structure introduced with > CASSANDRA-17240 along with a query path implementation to perform index > queries from the in-memory index. -- 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-18058) In-memory index and query path
[ https://issues.apache.org/jira/browse/CASSANDRA-18058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17646255#comment-17646255 ] Andres de la Peña commented on CASSANDRA-18058: --- I have left a few additional minor suggestions, but overall the changes look good to me. Do we have CI results? [~maedhroz] will you have time to review? > In-memory index and query path > -- > > Key: CASSANDRA-18058 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18058 > Project: Cassandra > Issue Type: New Feature > Components: Feature/SAI >Reporter: Mike Adamson >Assignee: Mike Adamson >Priority: Normal > Fix For: 5.x > > > An in-memory index using the in-memory trie structure introduced with > CASSANDRA-17240 along with a query path implementation to perform index > queries from the in-memory index. -- 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-18107) CEP-15: Multi-Partition Transaction CQL Support (Alpha -> v1)
[
https://issues.apache.org/jira/browse/CASSANDRA-18107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-18107:
Description:
With CASSANDRA-17719 complete, basic/alpha CQL support for Accord is now
available in the
[cep-15-accord|https://github.com/apache/cassandra/commits/cep-15-accord]
branch. There are, however, a number of features and enhancements that we would
still like to add before we make it available to users. Here is a summary of
those items, broadly categorized:
*Error Messages and UX*
- Fix the element/field names in result metadata to match the user query
- Better error messages
-- Append/subtracting to/from frozen list
-- attempts to use reference in WHERE clause
-- LET using a reserved word
*Domain Object Cleanup*
- Given {{Selector}} is serializable, attempt to reuse it in {{TxnReference}}
rather than hard coding data conversion cases
- Separate current current {{LET}} statement from {{SelectStatement}}, likely
as a new {{LetStatement}} that names a {{SelectStatement}}
- Explore unifying {{Operation}} and {{ReferenceOperation}}
- Include non-Row items of {{FilteredPartition}} in
{{TxnData#estimatedSizeOnHeap()}}
- Explore possibility of making {{Bound}} serializable and using it directly in
{{TxnCondition}}
- Change internal representation of {{TxnDataName}} to avoid {{String}} ->
{{ByteBuffer}} conversions
- Have {{TxnCondition}}/{{TxnUpdate}} support {{slice()}} to full take
advantage of partial state replication
- Update serialization logic to reflect CASSANDRA-18099
*Testing*
- Figure out the original intent of placeholder tests in
{{AccordIntegrationTest}} (ex. {{acceptInvalidationTest()}})
- Remove hack in {{AccordConfigurationService}} (when we have Transactional
Metadata)
- Verify concretely that we disable Guardrails.
- Audit the way we propagate timestamps through execution.
*Features*
- Full JSON support
- Final decision of whether we should support returning the result of an
{{IF}}/condition
- Constant terms on the RHS of LET
- Support for having a reference on both LHS and RHS of {{IF}} predicates
- Support for {{CONTAINS}}, {{CONTAINS KEY}}, and {{IN}} (important for CAS
parity)
- Nested UDT support
- Mixed conditional and unconditional updates (should this be post-v1?)
- Arithmetic operations on references in {{INSERT}}/{{UPDATE}} (ex. INSERT INTO
ks.tbl1 (k, c, v) VALUES (0, 0, a.v + 1)
*Tooling*
- Eliminate {{nodetool createepochunsafe}} once transactional metadata is
available.
*Metrics*
- Latency metrics for execution and failure/timeout counting (“Transaction” in
client metrics?)
*Documentation*
- CQL language documentation and bump the CQL language specification version
- JavaDoc for all new statement classes
- Integrate {{demo.txt}} into broader documentation somewhere or remove
*Questions*
- How should txn statement parsing/preparation handle TTLs specified in updates?
- At what level do we want to integrate tracing?
was:
With CASSANDRA-17719 complete, basic/alpha CQL support for Accord is now
available in the
[cep-15-accord|https://github.com/apache/cassandra/commits/cep-15-accord]
branch. There are, however, a number of features and enhancements that we would
still like to add before we make it available to users. Here is a summary of
those items, broadly categorized:
*Error Messages and UX*
- Fix the element/field names in result metadata to match the user query
- Better error messages
-- Append/subtracting to/from frozen list
-- attempts to use reference in WHERE clause
-- LET using a reserved word
*Domain Object Cleanup*
- Given {{Selector}} is serializable, attempt to reuse it in {{TxnReference}}
rather than hard coding data conversion cases
- Separate current current {{LET}} statement from {{SelectStatement}}, likely
as a new {{LetStatement}} that names a {{SelectStatement}}
- Explore unifying {{Operation}} and {{ReferenceOperation}}
- Include non-Row items of {{FilteredPartition}} in
{{TxnData#estimatedSizeOnHeap()}}
- Explore possibility of making {{Bound}} serializable and using it directly in
{{TxnCondition}}
- Change internal representation of {{TxnDataName}} to avoid {{String}} ->
{{ByteBuffer}} conversions
- Have {{TxnCondition}}/{{TxnUpdate}} support {{slice()}} to full take
advantage of partial state replication
*Testing*
- Figure out the original intent of placeholder tests in
{{AccordIntegrationTest}} (ex. {{acceptInvalidationTest()}})
- Remove hack in {{AccordConfigurationService}} (when we have Transactional
Metadata)
- Verify concretely that we disable Guardrails.
- Audit the way we propagate timestamps through execution.
*Features*
- Full JSON support
- Final decision of whether we should support returning the result of an
{{IF}}/condition
- Constant terms on the RHS of LET
- Support for having a reference on both LHS and RHS of {{IF}} predicates
- Support for {{CONTAINS}},
[jira] [Commented] (CASSANDRA-18108) Data loss after a system restart/upgrade (3.11.14)
[
https://issues.apache.org/jira/browse/CASSANDRA-18108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17646228#comment-17646228
]
Caleb Rackliffe commented on CASSANDRA-18108:
-
[~aleksey] Am I thinking about this incorrectly? Should renaming a key
component actually be safe?
> Data loss after a system restart/upgrade (3.11.14)
> --
>
> Key: CASSANDRA-18108
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18108
> Project: Cassandra
> Issue Type: Bug
>Reporter: Ke Han
>Priority: Normal
>
> When we upgrade Cassandra from 3.11.14 to 4.0.7, we found a data loss during
> the upgrade process. This bug can also be triggered if simply performing a
> system restart.
> h1. Steps to reproduce
> Start a 3.11.14 or 4.0.7 Cassandra node using default configurations. Execute
> the following cqlsh commands.
> {code:java}
> CREATE KEYSPACE ks WITH REPLICATION = { 'class' : 'SimpleStrategy',
> 'replication_factor' : 1 };
> CREATE TABLE IF NOT EXISTS ks.tb (c1 INT,c3 INT,c2 TEXT, PRIMARY KEY (c1 ))
> WITH speculative_retry = 'ALWAYS';
> INSERT INTO ks.tb (c1, c2) VALUES (2,'val');
> ALTER TABLE ks.tb DROP c2 ;
> ALTER TABLE ks.tb RENAME c1 TO c2; {code}
> Then execute a SELECT command, we get the correct data
> {code:java}
> cqlsh> SELECT * FROM ks.tb;
> c2 | c3
> +--
> 2 | null
> (1 rows){code}
> Flush and stop the Cassandra daemon.
> {code:java}
> bin/nodetool flush
> bin/nodetool stopdaemon{code}
> Then restart the node.
> {code:java}
> bin/cassandra{code}
> Start cqlsh, and execute the same SELECT command. The data in ks.tb is lost.
> {code:java}
> cqlsh> SELECT * FROM ks.tb;
> c2 | c3
> +
> (0 rows){code}
>
> During the node restart, we found an error log about initializing the table,
> but it didn't prevent the system from starting up.
> {code:java}
> INFO [main] 2022-12-09 21:37:54,234 ColumnFamilyStore.java:432 -
> Initializing ks.tb
> ERROR [SSTableBatchOpen:1] 2022-12-09 21:37:54,237 CassandraDaemon.java:244 -
> Exception in thread Thread[SSTableBatchOpen:1,5,main]
> java.lang.AssertionError: null
> at
> org.apache.cassandra.db.PartitionColumns$Builder.add(PartitionColumns.java:161)
> at
> org.apache.cassandra.db.SerializationHeader$Component.toHeader(SerializationHeader.java:340)
> at
> org.apache.cassandra.io.sstable.format.SSTableReader.open(SSTableReader.java:522)
> at
> org.apache.cassandra.io.sstable.format.SSTableReader.open(SSTableReader.java:385)
> at
> org.apache.cassandra.io.sstable.format.SSTableReader$3.run(SSTableReader.java:570)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:84)
> at java.lang.Thread.run(Thread.java:750) {code}
>
> This bug can also be triggered if we perform an upgrade from 3.11.14 to 4.0.7
> and execute the SELECT command in the new version. (*The token_num
> configuration in 4.0.7 is modified to 16 for upgrade compatibility purposes,
> all the other configurations are using default values)
--
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-18108) Data loss after a system restart/upgrade (3.11.14)
[
https://issues.apache.org/jira/browse/CASSANDRA-18108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17646226#comment-17646226
]
Ke Han commented on CASSANDRA-18108:
[~maedhroz] That makes sense. Thanks.
> Data loss after a system restart/upgrade (3.11.14)
> --
>
> Key: CASSANDRA-18108
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18108
> Project: Cassandra
> Issue Type: Bug
>Reporter: Ke Han
>Priority: Normal
>
> When we upgrade Cassandra from 3.11.14 to 4.0.7, we found a data loss during
> the upgrade process. This bug can also be triggered if simply performing a
> system restart.
> h1. Steps to reproduce
> Start a 3.11.14 or 4.0.7 Cassandra node using default configurations. Execute
> the following cqlsh commands.
> {code:java}
> CREATE KEYSPACE ks WITH REPLICATION = { 'class' : 'SimpleStrategy',
> 'replication_factor' : 1 };
> CREATE TABLE IF NOT EXISTS ks.tb (c1 INT,c3 INT,c2 TEXT, PRIMARY KEY (c1 ))
> WITH speculative_retry = 'ALWAYS';
> INSERT INTO ks.tb (c1, c2) VALUES (2,'val');
> ALTER TABLE ks.tb DROP c2 ;
> ALTER TABLE ks.tb RENAME c1 TO c2; {code}
> Then execute a SELECT command, we get the correct data
> {code:java}
> cqlsh> SELECT * FROM ks.tb;
> c2 | c3
> +--
> 2 | null
> (1 rows){code}
> Flush and stop the Cassandra daemon.
> {code:java}
> bin/nodetool flush
> bin/nodetool stopdaemon{code}
> Then restart the node.
> {code:java}
> bin/cassandra{code}
> Start cqlsh, and execute the same SELECT command. The data in ks.tb is lost.
> {code:java}
> cqlsh> SELECT * FROM ks.tb;
> c2 | c3
> +
> (0 rows){code}
>
> During the node restart, we found an error log about initializing the table,
> but it didn't prevent the system from starting up.
> {code:java}
> INFO [main] 2022-12-09 21:37:54,234 ColumnFamilyStore.java:432 -
> Initializing ks.tb
> ERROR [SSTableBatchOpen:1] 2022-12-09 21:37:54,237 CassandraDaemon.java:244 -
> Exception in thread Thread[SSTableBatchOpen:1,5,main]
> java.lang.AssertionError: null
> at
> org.apache.cassandra.db.PartitionColumns$Builder.add(PartitionColumns.java:161)
> at
> org.apache.cassandra.db.SerializationHeader$Component.toHeader(SerializationHeader.java:340)
> at
> org.apache.cassandra.io.sstable.format.SSTableReader.open(SSTableReader.java:522)
> at
> org.apache.cassandra.io.sstable.format.SSTableReader.open(SSTableReader.java:385)
> at
> org.apache.cassandra.io.sstable.format.SSTableReader$3.run(SSTableReader.java:570)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:84)
> at java.lang.Thread.run(Thread.java:750) {code}
>
> This bug can also be triggered if we perform an upgrade from 3.11.14 to 4.0.7
> and execute the SELECT command in the new version. (*The token_num
> configuration in 4.0.7 is modified to 16 for upgrade compatibility purposes,
> all the other configurations are using default values)
--
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-11537) Give clear error when certain nodetool commands are issued before server is ready
[
https://issues.apache.org/jira/browse/CASSANDRA-11537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
wnguyen25 reassigned CASSANDRA-11537:
-
Assignee: wnguyen25
> Give clear error when certain nodetool commands are issued before server is
> ready
> -
>
> Key: CASSANDRA-11537
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11537
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Observability, Local/Startup and Shutdown
>Reporter: Edward Capriolo
>Assignee: wnguyen25
>Priority: Low
> Labels: lhf
>
> As an ops person upgrading and servicing Cassandra servers, I require a more
> clear message when I issue a nodetool command that the server is not ready
> for it so that I am not confused.
> Technical description:
> If you deploy a new binary, restart, and issue nodetool
> scrub/compact/updatess etc you get unfriendly assertion. An exception would
> be easier to understand. Also if a user has turned assertions off it is
> unclear what might happen.
> {noformat}
> EC1: Throw exception to make it clear server is still in start up process.
> :~# nodetool upgradesstables
> error: null
> -- StackTrace --
> java.lang.AssertionError
> at org.apache.cassandra.db.Keyspace.open(Keyspace.java:97)
> at
> org.apache.cassandra.service.StorageService.getValidKeyspace(StorageService.java:2573)
> at
> org.apache.cassandra.service.StorageService.getValidColumnFamilies(StorageService.java:2661)
> at
> org.apache.cassandra.service.StorageService.upgradeSSTables(StorageService.java:2421)
> {noformat}
> EC1:
> Patch against 2.1 (branch)
> https://github.com/apache/cassandra/compare/trunk...edwardcapriolo:exception-on-startup?expand=1
--
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-18102) Add a virtual table to list snapshots
[
https://issues.apache.org/jira/browse/CASSANDRA-18102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17646186#comment-17646186
]
Paulo Motta commented on CASSANDRA-18102:
-
Hi [~maxwellguo] we will no longer work on this so feel free to take it. This
ticket can be done using the current {{listsnapshots}} implementation that
loads snapshots from disk.
I will work on moving snapshots to memory in CASSANDRA-18111. Once that is done
we can update the virtual table implementation to load snapshots from memory
instead.
> Add a virtual table to list snapshots
> -
>
> Key: CASSANDRA-18102
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18102
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Virtual Tables, Local/Snapshots
>Reporter: Paulo Motta
>Assignee: maxwellguo
>Priority: Normal
>
> It should be possible to query a node's snapshots via virtual tables.
> The table should expose the same fields/columns as the
> [TableSnapshot|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/service/snapshot/TableSnapshot.java]
> class.
> Something along these lines:
> {noformat}
> cqlsh> SELECT * FROM system_views.snapshots;
>
> tag | keyspace_name | table_name | table_id | is_ephemeral | created_at |
> expires_at | directories
> +---++---+--+---++
> 1670460346841 | system | compaction_info |
> 123e4567-e89b-12d3-a456-426614174000 | false | 2022-12-08T00:45:47.108Z |
> null |
> {'/var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/snapshots/1670460346841'}
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-18111) Cache snapshots in memory
Paulo Motta created CASSANDRA-18111:
---
Summary: Cache snapshots in memory
Key: CASSANDRA-18111
URL: https://issues.apache.org/jira/browse/CASSANDRA-18111
Project: Cassandra
Issue Type: Improvement
Reporter: Paulo Motta
Assignee: Paulo Motta
Everytime {{nodetool listsnapshots}} is called, all data directories are
scanned to find snapshots, what is inefficient.
For example, fetching the
{{org.apache.cassandra.metrics:type=ColumnFamily,name=SnapshotsSize}} metric
can take half a second (CASSANDRA-13338).
This improvement will also allow snapshots to be efficiently queried via
virtual tables (CASSANDRA-18102).
In order to do this, we should:
a) load all snapshots from disk during initialization
b) keep a collection of snapshots on {{SnapshotManager}}
c) update the snapshots collection anytime a new snapshot is taken or cleared
d) detect when a snapshot is manually removed from disk.
--
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-17869) Add JDK17 option to cassandra-builds (build-scripts and jenkins dsl) and on jenkins agents
[
https://issues.apache.org/jira/browse/CASSANDRA-17869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17646165#comment-17646165
]
Ekaterina Dimitrova commented on CASSANDRA-17869:
-
On another topic - I just looked at CCM and it will also require changes, I
have the preliminary changes for it too but I guess now we need to wait on
things to get more clear here and then revisit any changes in CASSANDRA-18106
> Add JDK17 option to cassandra-builds (build-scripts and jenkins dsl) and on
> jenkins agents
> --
>
> Key: CASSANDRA-17869
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17869
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
>
> Add JDK17 option to cassandra-builds build-scripts, they only currently
> support options {{8}} and {{1}}.
> Add JDK17 to the matrix axes in the jenkins dsl.
> Ensure JDK17 is installed on all the jenkins agents.
--
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-18094) Add python 3.11 to CI
[ https://issues.apache.org/jira/browse/CASSANDRA-18094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-18094: - Fix Version/s: 3.0.29 3.11.15 4.1 4.2 Source Control Link: https://github.com/apache/cassandra-builds/commit/ab24c413794c2c68e21d00df720e7a1c62321097 Resolution: Fixed Status: Resolved (was: Ready to Commit) Thanks, committed. I'll get the docker image pushed. > Add python 3.11 to CI > - > > Key: CASSANDRA-18094 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18094 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.0.29, 3.11.15, 4.1, 4.2 > > > Python 3.11 has a small divergence that necessitates a SaferScanner for that > version and those after it in CASSANDRA-18088, similar to what 3.8 did and we > solved with CASSANDRA-15573. We should add 3.11 to our docker images so we > can test with it. -- 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-17869) Add JDK17 option to cassandra-builds (build-scripts and jenkins dsl) and on jenkins agents
[
https://issues.apache.org/jira/browse/CASSANDRA-17869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17646158#comment-17646158
]
Ekaterina Dimitrova commented on CASSANDRA-17869:
-
{quote}It adds complexity to the existing scripts that I am hoping to avoid.
{quote}
I guess I misunderstood you initially, I am all in for not adding more
complexity if that will be the case.
Another question: updating build.xml and other scripts should be also handled
as part of this ticket I guess?
Or at least I have to open a ticket and rework what I already have I guess
*after* this ticket lands so we have the final decision on what we want. Until
then I should just use the current scripts I have in the WIP branch for testing
while cleaning issues around JDK17
> Add JDK17 option to cassandra-builds (build-scripts and jenkins dsl) and on
> jenkins agents
> --
>
> Key: CASSANDRA-17869
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17869
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
>
> Add JDK17 option to cassandra-builds build-scripts, they only currently
> support options {{8}} and {{1}}.
> Add JDK17 to the matrix axes in the jenkins dsl.
> Ensure JDK17 is installed on all the jenkins agents.
--
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-18094) Add python 3.11 to CI
[ https://issues.apache.org/jira/browse/CASSANDRA-18094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-18094: - Status: Ready to Commit (was: Review In Progress) > Add python 3.11 to CI > - > > Key: CASSANDRA-18094 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18094 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > > Python 3.11 has a small divergence that necessitates a SaferScanner for that > version and those after it in CASSANDRA-18088, similar to what 3.8 did and we > solved with CASSANDRA-15573. We should add 3.11 to our docker images so we > can test with it. -- 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
[cassandra-builds] branch trunk updated: Add python 3.11 to docker
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra-builds.git The following commit(s) were added to refs/heads/trunk by this push: new ab24c41 Add python 3.11 to docker ab24c41 is described below commit ab24c413794c2c68e21d00df720e7a1c62321097 Author: Brandon Williams AuthorDate: Tue Dec 6 11:05:28 2022 -0600 Add python 3.11 to docker Patch by brandonwilliams; reviewed by bereng for CASSANDRA-18094 --- docker/testing/ubuntu2004_j11.docker | 7 +++ 1 file changed, 7 insertions(+) diff --git a/docker/testing/ubuntu2004_j11.docker b/docker/testing/ubuntu2004_j11.docker index e572a68..45e5ec7 100644 --- a/docker/testing/ubuntu2004_j11.docker +++ b/docker/testing/ubuntu2004_j11.docker @@ -33,6 +33,7 @@ RUN export DEBIAN_FRONTEND=noninteractive && \ python3.6 python3.6-venv python3.6-dev \ python3.7 python3.7-venv python3.7-dev \ python3.8 python3.8-venv python3.8-dev \ +python3.11 python3.11-venv python3.11-dev \ net-tools libev4 libev-dev wget gcc libssl-dev libxml2 libxslt1-dev # install python2-pip @@ -44,10 +45,12 @@ RUN update-alternatives --install /usr/bin/python python /usr/bin/python2.7 1 RUN update-alternatives --install /usr/bin/python python /usr/bin/python3.6 2 RUN update-alternatives --install /usr/bin/python python /usr/bin/python3.7 3 RUN update-alternatives --install /usr/bin/python python /usr/bin/python3.8 4 +RUN update-alternatives --install /usr/bin/python python /usr/bin/python3.11 5 RUN python2.7 -m pip install --upgrade pip RUN python3.6 -m pip install --upgrade pip RUN python3.7 -m pip install --upgrade pip RUN python3.8 -m pip install --upgrade pip +RUN python3.11 -m pip install --upgrade pip # solves warning: "jemalloc shared library could not be preloaded to speed up memory allocations" RUN export DEBIAN_FRONTEND=noninteractive && \ @@ -137,6 +140,10 @@ RUN virtualenv --python=python3.8 env3.8 RUN chmod +x env3.8/bin/activate RUN /bin/bash -c "export CASS_DRIVER_NO_CYTHON=1 CASS_DRIVER_NO_EXTENSIONS=1 && source ~/env3.8/bin/activate && pip3 install --upgrade pip && pip3 install -r /opt/requirements.txt && pip3 freeze --user" +RUN virtualenv --python=python3.11 env3.11 +RUN chmod +x env3.11/bin/activate +RUN /bin/bash -c "export CASS_DRIVER_NO_CYTHON=1 CASS_DRIVER_NO_EXTENSIONS=1 && source ~/env3.11/bin/activate && pip3 install --upgrade pip && pip3 install -r /opt/requirements.txt && pip3 freeze --user" + # we need to make SSH less strict to prevent various dtests from failing when they attempt to # git clone a given commit/tag/etc # upgrading node1 to github:apache/18cdd391ec27d16daf775f928902f5a421c415e3 - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18075) Upgraded (C* 4.0.4) node stops communicating with older version (3.11.4) nodes during upgrade
[
https://issues.apache.org/jira/browse/CASSANDRA-18075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17646157#comment-17646157
]
Brandon Williams commented on CASSANDRA-18075:
--
CASSANDRA-17744 had different symptoms, and they went away on their own. I
don't see any dropped READ_REQ messages here, as in the title of the
stackexchange post. I don't believe either of them had a refused connection on
the storage port.
bq. Then I upgraded the same cluster from 3.11.14 to 4.0.7 (latest version).
Again the same issue.
By same issue what exactly does that mean? It may be worth examining those
logs as well.
I think any viable theory needs to be framed with the evidence that is present.
The connection being refused to the storage port is critical for communication
and not a red herring that can be ignored.
> Upgraded (C* 4.0.4) node stops communicating with older version (3.11.4)
> nodes during upgrade
> -
>
> Key: CASSANDRA-18075
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18075
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Encryption
>Reporter: Alaykumar Barochia
>Priority: Normal
> Attachments: In-place-upgrade.zip, cassandra-env.sh_3114,
> cassandra-env.sh_404, cassandra.yaml_10.110.44.207_explicitely_set_port,
> cassandra.yaml_10.110.49.242_explicitely_set_port, cassandra.yaml_3114,
> cassandra.yaml_404, system.log_10.110.44.207,
> system.log_10.110.44.207_after_explicitely_set_port,
> system.log_10.110.49.242_after_explicitely_set_port
>
>
> We are testing upgrade from Cassandra 3.11.4 to 4.0.4 on our test cluster
> which is SSL enabled and facing an issue.
> Our cluster size is 3x3.
> {noformat}
> Datacenter: abssl_dev_tap_ttc
> =
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- AddressLoad Tokens Owns (effective) Host ID
> Rack
> UN 10.109.6.153 94.27 KiB 16 100.0%
> 130e59d2-2a9a-4039-a42f-deb20afcf288 rack1
> UN 10.109.45.8104.43 KiB 16 100.0%
> 35274a2c-f915-4308-9981-d207a4e2108f rack1
> UN 10.109.66.149 104.23 KiB 16 100.0%
> ea0151bc-fb6c-425d-af42-75c10e52f941 rack1
> Datacenter: abssl_dev_tap_tte
> =
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- AddressLoad Tokens Owns (effective) Host ID
> Rack
> UN 10.110.4.110 104.44 KiB 16 100.0%
> fd4a9fa8-f2a9-494c-afb8-7cb8a08c7554 rack1
> UN 10.110.44.220 99.33 KiB 16 100.0%
> f1dc35c0-a1c2-45fe-9f65-b1cc3d7f6947 rack1
> UN 10.110.49.242 65.57 KiB 16 100.0%
> 72bc4ae5-876d-4d0a-91ac-6cf8b531b4dd rack1
> dbaasprod-ca-abssl-de-393671-v001-yqlvf:~# nodetool describecluster
> Cluster Information:
> Name: abssl_dev
> Snitch: org.apache.cassandra.locator.GossipingPropertyFileSnitch
> DynamicEndPointSnitch: enabled
> Partitioner: org.apache.cassandra.dht.Murmur3Partitioner
> Schema versions:
> f68fbc0c-c9d6-3709-8075-c5a0d74192f2: [10.110.4.110,
> 10.110.44.220, 10.109.6.153, 10.109.45.8, 10.109.66.149, 10.110.49.242]
> {noformat}
> During the upgrade, we re-run the pipeline in which we get new server (with
> different IP) that will have Cassandra 4.0.4 binary.
> Disk '/data' (contains data files, commitlogs etc.) will get detached from
> the old server and get attached to the new server.
> This process works fine on non-SSL cluster but when we perform this on SSL
> cluster, new node stops communicating with the rest of the nodes.
> In this example, after upgrade, node 10.110.4.110 got replaced with new
> server with new IP 10.110.44.207.
> *Output from 3.11.4 node:*
> {noformat}
> dbaasprod-ca-abssl-dc-437097-v001-7mump:~# hostname -i
> 10.109.6.153
> dbaasprod-ca-abssl-dc-437097-v001-7mump:~# java -version
> openjdk version "1.8.0_322"
> OpenJDK Runtime Environment (Temurin)(build 1.8.0_322-b06)
> OpenJDK 64-Bit Server VM (Temurin)(build 25.322-b06, mixed mode)
> dbaasprod-ca-abssl-dc-437097-v001-7mump:~# nodetool status
> Datacenter: abssl_dev_tap_ttc
> =
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- AddressLoad Tokens Owns (effective) Host ID
> Rack
> UN 10.109.6.153 135.24 KiB 16 100.0%
> 130e59d2-2a9a-4039-a42f-deb20afcf288 rack1
> UN 10.109.45.8135.35 KiB 16 100.0%
> 35274a2c-f915-4308-9981-d207a4e2108f rack1
> UN 10.109.66.149 135.25 KiB 16 100.0%
>
[jira] [Commented] (CASSANDRA-18104) Major Performance degradation of Casandara 4.0.7 against Casandra 3.11.14
[ https://issues.apache.org/jira/browse/CASSANDRA-18104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17646129#comment-17646129 ] Sreedhar J commented on CASSANDRA-18104: Thanks [~brandon.williams] for the updates. We still see slowness of 4.0.x compare to 3.11.x reran the test but with TRACING ON. summed up the microseconds reported as "Request Complete" for each run. 3.11.14: Sum of request complete source_elapsed converted to seconds: 0.551421 Results from "time" command: real0m6.709suser0m5.177ssys 0m0.157s 4.0.7: Sum of request complete source_elapsed converted to seconds: 0.869646 Results from "time" command: real0m6.914suser0m4.981ssys 0m0.128s So the tracing says all my queries took less than a second. But still higher on 4.0.7. using time is not the best way to measure this. time would include all of the python overhead in addition to the query time. > Major Performance degradation of Casandara 4.0.7 against Casandra 3.11.14 > > > Key: CASSANDRA-18104 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18104 > Project: Cassandra > Issue Type: Bug >Reporter: Sreedhar J >Priority: Urgent > Attachments: 3.11.14.txt, 4.0.7.txt, mailboxes_snapshot.zip, > query30.txt > > > Our application uses Casandra 3.11.x and has lot of security vulnerabilities > which are addressed in 4.0.x. So we have upgraded the Casandra to 4.0.7 > and our performance tests have shown aorund 20% degradation compare to > 3.11.x > We are now able to reproduce the same performance degradation using the > standalone queries. Here are the steps. > 1. Expand Cassandra 3.11.14 tarball and 4.0.7 tarball to different folders > 2. Import the attached data from the snapshot (mailboxes_snapshot.zip) into > each Cassandra instance, see schema.cql for CQL for creating the required > table and indexes before import > 3. With CQLSH run the following query several times with TRACING ON and > PAGING OFF against both versions of Cassandra: select * from > mailbox.mailboxes where mbx_id= 6c57da2e-7ddd-4984-be62-105415e6b48a; > 4. Compare results > IWe ran the target query 30 times. Here's the average times to run the query: > 3.11.14 - 19400.77 > 4.0.7 - 34906.03 -- 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-18094) Add python 3.11 to CI
[ https://issues.apache.org/jira/browse/CASSANDRA-18094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17646119#comment-17646119 ] Berenguer Blasi commented on CASSANDRA-18094: - Yes you're right, my bad. > Add python 3.11 to CI > - > > Key: CASSANDRA-18094 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18094 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > > Python 3.11 has a small divergence that necessitates a SaferScanner for that > version and those after it in CASSANDRA-18088, similar to what 3.8 did and we > solved with CASSANDRA-15573. We should add 3.11 to our docker images so we > can test with it. -- 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-18094) Add python 3.11 to CI
[ https://issues.apache.org/jira/browse/CASSANDRA-18094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17646113#comment-17646113 ] Brandon Williams commented on CASSANDRA-18094: -- I think we should commit the cassandra-builds docker changes on this one, then the rest can be done on 18088. Does that work for you? > Add python 3.11 to CI > - > > Key: CASSANDRA-18094 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18094 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > > Python 3.11 has a small divergence that necessitates a SaferScanner for that > version and those after it in CASSANDRA-18088, similar to what 3.8 did and we > solved with CASSANDRA-15573. We should add 3.11 to our docker images so we > can test with it. -- 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-18068) Allow to attach native masking functions to table columns
[
https://issues.apache.org/jira/browse/CASSANDRA-18068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-18068:
--
Change Category: Semantic
Complexity: Normal
Status: Open (was: Triage Needed)
> Allow to attach native masking functions to table columns
> -
>
> Key: CASSANDRA-18068
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18068
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Dynamic Data Masking
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
>
> Allow to attach the native masking functions added by CASSANDRA-17941 to
> table columns, as defined by
> [CEP-20|https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-20%3A+Dynamic+Data+Masking].
>
> {{CREATE TABLE}} statements would look like:
> {code}
> > CREATE TABLE patients (
> id timeuuid PRIMARY KEY,
> name text MASKED WITH partial(2, 1),
> birth date MASKED WITH default()
> );
> > INSERT INTO patients(id, name, birth) VALUES (now(), 'alice', '1982-12-21);
>
> > SELECT name, birth FROM patients;
>
> name| birth
> -+
> ale | 1900-01-01
> {code}
> {{ALTER TABLE}} statements would look like:
> {code}
> > ALTER TABLE patients ALTER name MASKED WITH partial(2, 1);
> > ALTER TABLE patients ALTER name WITHOUT MASK;
> {code}
> It won't be possible to use masked columns in the WHERE and IF clauses of
> SELECT and UPDATE statements.
--
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-18094) Add python 3.11 to CI
[ https://issues.apache.org/jira/browse/CASSANDRA-18094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17646109#comment-17646109 ] Berenguer Blasi commented on CASSANDRA-18094: - Ok then I'm +1 and I think we can close this one without committing, we'll just carry that commit over to the 18088 PRs :-) > Add python 3.11 to CI > - > > Key: CASSANDRA-18094 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18094 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > > Python 3.11 has a small divergence that necessitates a SaferScanner for that > version and those after it in CASSANDRA-18088, similar to what 3.8 did and we > solved with CASSANDRA-15573. We should add 3.11 to our docker images so we > can test with it. -- 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-12525) When adding new nodes to a cluster which has authentication enabled, we end up losing cassandra user's current crendentials and they get reverted back to default cas
[ https://issues.apache.org/jira/browse/CASSANDRA-12525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-12525: -- Reviewers: Stefan Miklosovic, Stefan Miklosovic (was: Stefan Miklosovic) Stefan Miklosovic, Stefan Miklosovic (was: Stefan Miklosovic) Status: Review In Progress (was: Patch Available) > When adding new nodes to a cluster which has authentication enabled, we end > up losing cassandra user's current crendentials and they get reverted back to > default cassandra/cassandra crendetials > - > > Key: CASSANDRA-12525 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12525 > Project: Cassandra > Issue Type: Bug > Components: Cluster/Schema, Local/Config >Reporter: Atin Sood >Assignee: German Eichberger >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x > > Time Spent: 2h 40m > Remaining Estimate: 0h > > Made the following observation: > When adding new nodes to an existing C* cluster with authentication enabled > we end up loosing password information about `cassandra` user. > Initial Setup > - Create a 5 node cluster with system_auth having RF=5 and > NetworkTopologyStrategy > - Enable PasswordAuthenticator on this cluster and update the password for > 'cassandra' user to say 'password' via the alter query > - Make sure you run nodetool repair on all the nodes > Test case > - Now go ahead and add 5 more nodes to this cluster. > - Run nodetool repair on all the 10 nodes now > - Decommission the original 5 nodes such that only the new 5 nodes are in the > cluster now > - Run cqlsh and try to connect to this cluster using old user name and > password, cassandra/password > I was unable to connect to the nodes with the original credentials and was > only able to connect using the default cassandra/cassandra credentials > From the conversation over IIRC > `beobal: sood: that definitely shouldn't happen. The new nodes should only > create the default superuser role if there are 0 roles currently defined > (including that default one)` -- 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-12525) When adding new nodes to a cluster which has authentication enabled, we end up losing cassandra user's current crendentials and they get reverted back to default cas
[ https://issues.apache.org/jira/browse/CASSANDRA-12525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-12525: -- Status: Changes Suggested (was: Review In Progress) > When adding new nodes to a cluster which has authentication enabled, we end > up losing cassandra user's current crendentials and they get reverted back to > default cassandra/cassandra crendetials > - > > Key: CASSANDRA-12525 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12525 > Project: Cassandra > Issue Type: Bug > Components: Cluster/Schema, Local/Config >Reporter: Atin Sood >Assignee: German Eichberger >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x > > Time Spent: 2h 40m > Remaining Estimate: 0h > > Made the following observation: > When adding new nodes to an existing C* cluster with authentication enabled > we end up loosing password information about `cassandra` user. > Initial Setup > - Create a 5 node cluster with system_auth having RF=5 and > NetworkTopologyStrategy > - Enable PasswordAuthenticator on this cluster and update the password for > 'cassandra' user to say 'password' via the alter query > - Make sure you run nodetool repair on all the nodes > Test case > - Now go ahead and add 5 more nodes to this cluster. > - Run nodetool repair on all the 10 nodes now > - Decommission the original 5 nodes such that only the new 5 nodes are in the > cluster now > - Run cqlsh and try to connect to this cluster using old user name and > password, cassandra/password > I was unable to connect to the nodes with the original credentials and was > only able to connect using the default cassandra/cassandra credentials > From the conversation over IIRC > `beobal: sood: that definitely shouldn't happen. The new nodes should only > create the default superuser role if there are 0 roles currently defined > (including that default one)` -- 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-18094) Add python 3.11 to CI
[ https://issues.apache.org/jira/browse/CASSANDRA-18094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17646096#comment-17646096 ] Brandon Williams commented on CASSANDRA-18094: -- It is and probably the best way to go, I just needed some coffee. > Add python 3.11 to CI > - > > Key: CASSANDRA-18094 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18094 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > > Python 3.11 has a small divergence that necessitates a SaferScanner for that > version and those after it in CASSANDRA-18088, similar to what 3.8 did and we > solved with CASSANDRA-15573. We should add 3.11 to our docker images so we > can test with it. -- 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-18094) Add python 3.11 to CI
[ https://issues.apache.org/jira/browse/CASSANDRA-18094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17646095#comment-17646095 ] Berenguer Blasi commented on CASSANDRA-18094: - Updating docker images, basing CASSANDRA-18088 off the branches of CASSANDRA-18094 and then committing is not an option? > Add python 3.11 to CI > - > > Key: CASSANDRA-18094 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18094 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > > Python 3.11 has a small divergence that necessitates a SaferScanner for that > version and those after it in CASSANDRA-18088, similar to what 3.8 did and we > solved with CASSANDRA-15573. We should add 3.11 to our docker images so we > can test with it. -- 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-18094) Add python 3.11 to CI
[ https://issues.apache.org/jira/browse/CASSANDRA-18094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17646054#comment-17646054 ] Brandon Williams commented on CASSANDRA-18094: -- If we don't want the py311 failures visible, then we'll have to commit CASSANDRA-18088, update docker and commit this, and then run CI for 18088 (and hopefully it works.) If we don't care about the py311 failures in the brief window between this and CASSANDRA-18088, we could update docker and commit this ticket, then run CI on 18088 and commit it. > Add python 3.11 to CI > - > > Key: CASSANDRA-18094 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18094 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > > Python 3.11 has a small divergence that necessitates a SaferScanner for that > version and those after it in CASSANDRA-18088, similar to what 3.8 did and we > solved with CASSANDRA-15573. We should add 3.11 to our docker images so we > can test with it. -- 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
[cassandra-website] branch dependabot/npm_and_yarn/site-ui/qs-6.5.3 created (now 2f7b70cb)
This is an automated email from the ASF dual-hosted git repository. github-bot pushed a change to branch dependabot/npm_and_yarn/site-ui/qs-6.5.3 in repository https://gitbox.apache.org/repos/asf/cassandra-website.git at 2f7b70cb Bump qs from 6.5.2 to 6.5.3 in /site-ui No new revisions were added by this update. - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18075) Upgraded (C* 4.0.4) node stops communicating with older version (3.11.4) nodes during upgrade
[
https://issues.apache.org/jira/browse/CASSANDRA-18075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17645989#comment-17645989
]
Alaykumar Barochia commented on CASSANDRA-18075:
[~brandon.williams] - I still feel the way Cassandra 4 handles the gossip is
different than Cassandra 3.
I ran one more test where I upgraded SSL cluster from 3.11.4 to 3.11.14 (IP
changes during the upgrade) and all went fine without any issue.
Then I upgraded the same cluster from 3.11.14 to 4.0.7 (latest version). Again
the same issue.
I found others also reported similar issues during the upgrade.
https://issues.apache.org/jira/browse/CASSANDRA-17744
https://dba.stackexchange.com/questions/319259/cassandra-4-0-dropping-message-of-type-read-req
(IP changes during upgrade)
If my infrastructure had an issue (firewall, port), I would have received the
same issue when I upgrade from 3.11.4 to 3.11.14.
It would be worth it if you try to reproduce at your end once.
> Upgraded (C* 4.0.4) node stops communicating with older version (3.11.4)
> nodes during upgrade
> -
>
> Key: CASSANDRA-18075
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18075
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Encryption
>Reporter: Alaykumar Barochia
>Priority: Normal
> Attachments: In-place-upgrade.zip, cassandra-env.sh_3114,
> cassandra-env.sh_404, cassandra.yaml_10.110.44.207_explicitely_set_port,
> cassandra.yaml_10.110.49.242_explicitely_set_port, cassandra.yaml_3114,
> cassandra.yaml_404, system.log_10.110.44.207,
> system.log_10.110.44.207_after_explicitely_set_port,
> system.log_10.110.49.242_after_explicitely_set_port
>
>
> We are testing upgrade from Cassandra 3.11.4 to 4.0.4 on our test cluster
> which is SSL enabled and facing an issue.
> Our cluster size is 3x3.
> {noformat}
> Datacenter: abssl_dev_tap_ttc
> =
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- AddressLoad Tokens Owns (effective) Host ID
> Rack
> UN 10.109.6.153 94.27 KiB 16 100.0%
> 130e59d2-2a9a-4039-a42f-deb20afcf288 rack1
> UN 10.109.45.8104.43 KiB 16 100.0%
> 35274a2c-f915-4308-9981-d207a4e2108f rack1
> UN 10.109.66.149 104.23 KiB 16 100.0%
> ea0151bc-fb6c-425d-af42-75c10e52f941 rack1
> Datacenter: abssl_dev_tap_tte
> =
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- AddressLoad Tokens Owns (effective) Host ID
> Rack
> UN 10.110.4.110 104.44 KiB 16 100.0%
> fd4a9fa8-f2a9-494c-afb8-7cb8a08c7554 rack1
> UN 10.110.44.220 99.33 KiB 16 100.0%
> f1dc35c0-a1c2-45fe-9f65-b1cc3d7f6947 rack1
> UN 10.110.49.242 65.57 KiB 16 100.0%
> 72bc4ae5-876d-4d0a-91ac-6cf8b531b4dd rack1
> dbaasprod-ca-abssl-de-393671-v001-yqlvf:~# nodetool describecluster
> Cluster Information:
> Name: abssl_dev
> Snitch: org.apache.cassandra.locator.GossipingPropertyFileSnitch
> DynamicEndPointSnitch: enabled
> Partitioner: org.apache.cassandra.dht.Murmur3Partitioner
> Schema versions:
> f68fbc0c-c9d6-3709-8075-c5a0d74192f2: [10.110.4.110,
> 10.110.44.220, 10.109.6.153, 10.109.45.8, 10.109.66.149, 10.110.49.242]
> {noformat}
> During the upgrade, we re-run the pipeline in which we get new server (with
> different IP) that will have Cassandra 4.0.4 binary.
> Disk '/data' (contains data files, commitlogs etc.) will get detached from
> the old server and get attached to the new server.
> This process works fine on non-SSL cluster but when we perform this on SSL
> cluster, new node stops communicating with the rest of the nodes.
> In this example, after upgrade, node 10.110.4.110 got replaced with new
> server with new IP 10.110.44.207.
> *Output from 3.11.4 node:*
> {noformat}
> dbaasprod-ca-abssl-dc-437097-v001-7mump:~# hostname -i
> 10.109.6.153
> dbaasprod-ca-abssl-dc-437097-v001-7mump:~# java -version
> openjdk version "1.8.0_322"
> OpenJDK Runtime Environment (Temurin)(build 1.8.0_322-b06)
> OpenJDK 64-Bit Server VM (Temurin)(build 25.322-b06, mixed mode)
> dbaasprod-ca-abssl-dc-437097-v001-7mump:~# nodetool status
> Datacenter: abssl_dev_tap_ttc
> =
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- AddressLoad Tokens Owns (effective) Host ID
> Rack
> UN 10.109.6.153 135.24 KiB 16 100.0%
> 130e59d2-2a9a-4039-a42f-deb20afcf288 rack1
> UN 10.109.45.8135.35 KiB 16 100.0%
