[jira] [Commented] (CASSANDRA-18124) Config parameter keystore_password should be nullable
[
https://issues.apache.org/jira/browse/CASSANDRA-18124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17648855#comment-17648855
]
Francisco Guerrero commented on CASSANDRA-18124:
[~e.dimitrova] I've encountered this issue recently, and might have a patch
around. I can submit a fix, as you mention we need to mark the param with
{{@Nullable}}
> Config parameter keystore_password should be nullable
> -
>
> Key: CASSANDRA-18124
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18124
> Project: Cassandra
> Issue Type: Bug
>Reporter: Tibor Repasi
>Priority: Normal
>
> Some SSL configuration may pass unencrypted private keys. PEMReader might
> accept that by assuming keyPassword to be null in that case (e.g.
> https://github.com/apache/cassandra/blob/f9e033f519c14596da4dc954875756a69aea4e78/src/java/org/apache/cassandra/security/PEMReader.java#L103).
> Current configuration reader does not accept keystore_password parameter to
> be set null or empty in the cassandra.yaml.
--
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 asf-staging updated (abd88d307 -> 962709c78)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git discard abd88d307 generate docs for b072ce0a new 962709c78 generate docs for b072ce0a This update added new revisions after undoing existing revisions. That is to say, some revisions that were in the old version of the branch are not in the new version. This situation occurs when a user --force pushes a change and generates a repository containing something like this: * -- * -- B -- O -- O -- O (abd88d307) \ N -- N -- N refs/heads/asf-staging (962709c78) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. 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: site-ui/build/ui-bundle.zip | Bin 4970898 -> 4970898 bytes 1 file changed, 0 insertions(+), 0 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (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:all-tabpanel ] Michael Semb Wever updated CASSANDRA-18063: --- Source Control Link: https://github.com/apache/cassandra-website/commit/dc9c4ad83f44eff2cf3b4325addb62714ec37fa7 Resolution: Fixed Status: Resolved (was: Ready to Commit) Committed as https://github.com/apache/cassandra-website/commit/dc9c4ad83f44eff2cf3b4325addb62714ec37fa7 > 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] [Updated] (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:all-tabpanel ] Michael Semb Wever updated CASSANDRA-18063: --- Status: Ready to Commit (was: Review In Progress) > 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] [Updated] (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:all-tabpanel ] Michael Semb Wever updated CASSANDRA-18063: --- Status: Review In Progress (was: Patch Available) > 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-16325) Update streaming metrics incrementally
[ https://issues.apache.org/jira/browse/CASSANDRA-16325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17648819#comment-17648819 ] Isaac Reath commented on CASSANDRA-16325: - Picking up where Dejan left off to add some tests. > Update streaming metrics incrementally > -- > > Key: CASSANDRA-16325 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16325 > Project: Cassandra > Issue Type: Improvement > Components: Observability/Metrics >Reporter: Paulo Motta >Assignee: Dejan Gvozdenac >Priority: Normal > Labels: lhf > > Currently the inbound and outbound streamed bytes metrics are incremented > after each file is streamed, what doesn't represent the current number of > bytes streamed since it can take a long time for a large file to be streamed. > We should update the metric incrementally as data is streamed. -- 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-16325) Update streaming metrics incrementally
[ https://issues.apache.org/jira/browse/CASSANDRA-16325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Isaac Reath reassigned CASSANDRA-16325: --- Assignee: Isaac Reath (was: Dejan Gvozdenac) > Update streaming metrics incrementally > -- > > Key: CASSANDRA-16325 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16325 > Project: Cassandra > Issue Type: Improvement > Components: Observability/Metrics >Reporter: Paulo Motta >Assignee: Isaac Reath >Priority: Normal > Labels: lhf > > Currently the inbound and outbound streamed bytes metrics are incremented > after each file is streamed, what doesn't represent the current number of > bytes streamed since it can take a long time for a large file to be streamed. > We should update the metric incrementally as data is streamed. -- 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-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
]
Michael Semb Wever updated CASSANDRA-18110:
---
Fix Version/s: 4.1.x
(was: 4.1)
> 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.x
>
>
> 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
>
[jira] [Updated] (CASSANDRA-18001) Add missing tests suites to CircleCI
[ https://issues.apache.org/jira/browse/CASSANDRA-18001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-18001: --- Fix Version/s: 4.1.x 4.x > Add missing tests suites to CircleCI > > > Key: CASSANDRA-18001 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18001 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Urgent > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1-rc1, 4.1, 4.1.x, 4.2, 4.x > > > Burn tests to all branches, large Python DTests (with/without vnodes), > cqlshlib not tested in all branches and with all jdks; Java distributed tests > not running with J8/J11 4.0+ -- 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
svn commit: r58780 - /release/cassandra/4.1-rc1/
Author: mck Date: Fri Dec 16 21:08:12 2022 New Revision: 58780 Log: Remove previous 4.1-rc1 release Removed: release/cassandra/4.1-rc1/ - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18121) Dtests need python 3.11 support
[ https://issues.apache.org/jira/browse/CASSANDRA-18121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17648791#comment-17648791 ] Brandon Williams edited comment on CASSANDRA-18121 at 12/16/22 8:52 PM: [Here|https://app.circleci.com/pipelines/github/driftx/cassandra/741/workflows/58d4801e-8cd9-48ce-82bf-e69c3d4e8d4f/jobs/8799/] is that run with everything combined. The only failures are the cqlsh_tests portion of the dtests, and they aren't failing due to python problems, but what appears to be availability problems, yet we know it has to be from the python change. Also when I run these locally, they pass. was (Author: brandon.williams): [Here|https://app.circleci.com/pipelines/github/driftx/cassandra/741/workflows/58d4801e-8cd9-48ce-82bf-e69c3d4e8d4f/jobs/8799/] is that run with everything combined. The only failures are the cqlsh_tests portion of the dtests, and they aren't failing due to python problem, but what appears to be availability problems, yet we know it has to be from the python change. Also when I run these locally, they pass. > Dtests need python 3.11 support > --- > > Key: CASSANDRA-18121 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18121 > Project: Cassandra > Issue Type: Improvement > Components: Test/dtest/python >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > > In order to have cqlsh support 3.11 the dtests also need to support 3.11 so > the cqlsh dtests can be run. -- 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-18121) Dtests need python 3.11 support
[ https://issues.apache.org/jira/browse/CASSANDRA-18121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17648791#comment-17648791 ] Brandon Williams commented on CASSANDRA-18121: -- [Here|https://app.circleci.com/pipelines/github/driftx/cassandra/741/workflows/58d4801e-8cd9-48ce-82bf-e69c3d4e8d4f/jobs/8799/] is that run with everything combined. The only failures are the cqlsh_tests portion of the dtests, and they aren't failing due to python problem, but what appears to be availability problems, yet we know it has to be from the python change. Also when I run these locally, they pass. > Dtests need python 3.11 support > --- > > Key: CASSANDRA-18121 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18121 > Project: Cassandra > Issue Type: Improvement > Components: Test/dtest/python >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > > In order to have cqlsh support 3.11 the dtests also need to support 3.11 so > the cqlsh dtests can be run. -- 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-18088) cqlsh - module 're' has no attribute 'sre_parse' - with Python 3.11
[
https://issues.apache.org/jira/browse/CASSANDRA-18088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17648788#comment-17648788
]
Brandon Williams commented on CASSANDRA-18088:
--
Thanks. CCM appears to be the one part of our python ecosystem this ticket
doesn't need to reach into. So far.
> cqlsh - module 're' has no attribute 'sre_parse' - with Python 3.11
> ---
>
> Key: CASSANDRA-18088
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18088
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: Aaron Ploetz
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 4.x
>
>
> User reported an error with cqlsh (Cassandra 4.0.7) on Stack Overflow:
> [https://stackoverflow.com/questions/74673247/cannot-able-to-run-cqlsh-due-to-python-attribute-error|https://stackoverflow.com/questions/74673247/cannot-able-to-run-cqlsh-due-to-python-attribute-error?noredirect=1#comment131807816_74673247]
>
> Found out that the user was using Python 3.11, and I was able to reproduce it
> with that.
> {{% python3.11 bin/cqlsh.py}}
> {{Traceback (most recent call last):}}
> {{ File "/Users/aaronploetz/local/apache-cassandra-4.0.7/bin/cqlsh.py", line
> 159, in }}
> {{ from cqlshlib import cql3handling, cqlhandling, pylexotron,
> sslhandling, cqlshhandling}}
> {{ File
> "/Users/aaronploetz/local/apache-cassandra-4.0.7/bin/../pylib/cqlshlib/cql3handling.py",
> line 19, in }}
> {{ from cqlshlib.cqlhandling import CqlParsingRuleSet, Hint}}
> {{ File
> "/Users/aaronploetz/local/apache-cassandra-4.0.7/bin/../pylib/cqlshlib/cqlhandling.py",
> line 23, in }}
> {{ from cqlshlib import pylexotron, util}}
> {{ File
> "/Users/aaronploetz/local/apache-cassandra-4.0.7/bin/../pylib/cqlshlib/pylexotron.py",
> line 342, in }}
> {{ class ParsingRuleSet:}}
> {{ File
> "/Users/aaronploetz/local/apache-cassandra-4.0.7/bin/../pylib/cqlshlib/pylexotron.py",
> line 343, in ParsingRuleSet}}
> {{ RuleSpecScanner = SaferScanner([}}
> {{ ^^}}
> {{ File
> "/Users/aaronploetz/local/apache-cassandra-4.0.7/bin/../pylib/cqlshlib/saferscanner.py",
> line 91, in _{_}init{_}_}}
> {{ s = re.sre_parse.State()}}
> {{ }}
> {{AttributeError: module 're' has no attribute 'sre_parse'}}
> Appears to be something specific (again) with Python's synchronizing regex
> engine (SRE). Works fine with Python 3.10, so there may have been a(nother)
> breaking change in that the re module with 3.11.
--
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-18121) Dtests need python 3.11 support
[ https://issues.apache.org/jira/browse/CASSANDRA-18121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17648783#comment-17648783 ] Brandon Williams commented on CASSANDRA-18121: -- Linking a branch that adds 3.11 support. I'll incorporate this into a CI run with CASSANDRA-18088 and CASSANDRA-18094. > Dtests need python 3.11 support > --- > > Key: CASSANDRA-18121 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18121 > Project: Cassandra > Issue Type: Improvement > Components: Test/dtest/python >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > > In order to have cqlsh support 3.11 the dtests also need to support 3.11 so > the cqlsh dtests can be run. -- 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-18088) cqlsh - module 're' has no attribute 'sre_parse' - with Python 3.11
[
https://issues.apache.org/jira/browse/CASSANDRA-18088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17648774#comment-17648774
]
Stefan Miklosovic commented on CASSANDRA-18088:
---
btw there is also CASSANDRA-17861
> cqlsh - module 're' has no attribute 'sre_parse' - with Python 3.11
> ---
>
> Key: CASSANDRA-18088
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18088
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: Aaron Ploetz
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 4.x
>
>
> User reported an error with cqlsh (Cassandra 4.0.7) on Stack Overflow:
> [https://stackoverflow.com/questions/74673247/cannot-able-to-run-cqlsh-due-to-python-attribute-error|https://stackoverflow.com/questions/74673247/cannot-able-to-run-cqlsh-due-to-python-attribute-error?noredirect=1#comment131807816_74673247]
>
> Found out that the user was using Python 3.11, and I was able to reproduce it
> with that.
> {{% python3.11 bin/cqlsh.py}}
> {{Traceback (most recent call last):}}
> {{ File "/Users/aaronploetz/local/apache-cassandra-4.0.7/bin/cqlsh.py", line
> 159, in }}
> {{ from cqlshlib import cql3handling, cqlhandling, pylexotron,
> sslhandling, cqlshhandling}}
> {{ File
> "/Users/aaronploetz/local/apache-cassandra-4.0.7/bin/../pylib/cqlshlib/cql3handling.py",
> line 19, in }}
> {{ from cqlshlib.cqlhandling import CqlParsingRuleSet, Hint}}
> {{ File
> "/Users/aaronploetz/local/apache-cassandra-4.0.7/bin/../pylib/cqlshlib/cqlhandling.py",
> line 23, in }}
> {{ from cqlshlib import pylexotron, util}}
> {{ File
> "/Users/aaronploetz/local/apache-cassandra-4.0.7/bin/../pylib/cqlshlib/pylexotron.py",
> line 342, in }}
> {{ class ParsingRuleSet:}}
> {{ File
> "/Users/aaronploetz/local/apache-cassandra-4.0.7/bin/../pylib/cqlshlib/pylexotron.py",
> line 343, in ParsingRuleSet}}
> {{ RuleSpecScanner = SaferScanner([}}
> {{ ^^}}
> {{ File
> "/Users/aaronploetz/local/apache-cassandra-4.0.7/bin/../pylib/cqlshlib/saferscanner.py",
> line 91, in _{_}init{_}_}}
> {{ s = re.sre_parse.State()}}
> {{ }}
> {{AttributeError: module 're' has no attribute 'sre_parse'}}
> Appears to be something specific (again) with Python's synchronizing regex
> engine (SRE). Works fine with Python 3.10, so there may have been a(nother)
> breaking change in that the re module with 3.11.
--
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] branch cassandra-4.1 updated: Increment versions to 4.1.1
This is an automated email from the ASF dual-hosted git repository. mck pushed a commit to branch cassandra-4.1 in repository https://gitbox.apache.org/repos/asf/cassandra.git The following commit(s) were added to refs/heads/cassandra-4.1 by this push: new af5029d643 Increment versions to 4.1.1 af5029d643 is described below commit af5029d643f459049b5d19f316471b3c4685f44a Author: Mick Semb Wever AuthorDate: Fri Dec 16 11:34:23 2022 -0800 Increment versions to 4.1.1 --- CHANGES.txt | 6 ++ build.xml| 2 +- debian/changelog | 6 ++ 3 files changed, 13 insertions(+), 1 deletion(-) diff --git a/CHANGES.txt b/CHANGES.txt index 06f21d34e3..2721964b2a 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -1,3 +1,9 @@ +4.1.1 +Merged from 4.0: +Merged from 3.11: +Merged from 3.0: + + 4.1.0 * Fix ContentionStrategy backoff and Clock.waitUntil (CASSANDRA-18086) Merged from 4.0: diff --git a/build.xml b/build.xml index 8c0e9804ae..74751c9b1d 100644 --- a/build.xml +++ b/build.xml @@ -33,7 +33,7 @@ - + https://gitbox.apache.org/repos/asf/cassandra.git"/> https://gitbox.apache.org/repos/asf/cassandra.git"/> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=tree"/> diff --git a/debian/changelog b/debian/changelog index e2e51d32a1..28ea8ba361 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,9 @@ +cassandra (4.1.1) UNRELEASED; urgency=medium + + * New release + + -- Mick Semb Wever Wed, 07 Dec 2022 21:53:33 +0100 + cassandra (4.1.0) unstable; urgency=medium * New release - 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 070362c883d6b2609966837645d320d2d442510f Merge: 94bcb4e5ec af5029d643 Author: Mick Semb Wever AuthorDate: Fri Dec 16 11:34:53 2022 -0800 Merge branch 'cassandra-4.1' into trunk * cassandra-4.1: Increment versions to 4.1.1 - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated (94bcb4e5ec -> 070362c883)
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 94bcb4e5ec Only reload compaction strategies if disk boundaries change new af5029d643 Increment versions to 4.1.1 new 070362c883 Merge branch 'cassandra-4.1' into trunk The 2 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
[jira] [Updated] (CASSANDRA-17723) Add support for big endian architecture (s390x)
[ https://issues.apache.org/jira/browse/CASSANDRA-17723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-17723: --- Reviewers: Michael Semb Wever > Add support for big endian architecture (s390x) > --- > > Key: CASSANDRA-17723 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17723 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Observability, Legacy/Testing >Reporter: Shahid Shaikh >Assignee: Shahid Shaikh >Priority: Normal > Fix For: 4.x > > Attachments: CASSANDRA-17723-4.0.patch > > > Noticed that some of the Cassandra tests are failing on big endian > architectures (s390x). Please find the attached code patch which corrects the > data handling for big endian architecture. It also corrects the byte ordering > when dealing with sun.misc.Unsafe methods. After the patch following tests > are passing for s390x which were failing earlier: > TTLTest > ScrubTest > LegacySSTableTest > SSTableExportSchemaLoadingTest > SSTableMetadataViewerTest > StandaloneUpgraderOnSStablesTest > StandaloneVerifierOnSSTablesTest > The code change ensures that Cassandra for little endian architectures remain > unaffected. > -- 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-18121) Dtests need python 3.11 support
[ https://issues.apache.org/jira/browse/CASSANDRA-18121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-18121: - Description: In order to have cqlsh support 3.11 the dtests also need to support 3.11 so the cqlsh dtests can be run. (was: In order to have cqlsh support 3.11 the dtest also need to support 3.11 so the cqlsh dtests can be run.) > Dtests need python 3.11 support > --- > > Key: CASSANDRA-18121 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18121 > Project: Cassandra > Issue Type: Improvement > Components: Test/dtest/python >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > > In order to have cqlsh support 3.11 the dtests also need to support 3.11 so > the cqlsh dtests can be run. -- 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-18088) cqlsh - module 're' has no attribute 'sre_parse' - with Python 3.11
[
https://issues.apache.org/jira/browse/CASSANDRA-18088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17648745#comment-17648745
]
Brandon Williams commented on CASSANDRA-18088:
--
And yet another wrinkle: the cqlshlib tests use nose, and nose is more or less
dead and doesn't support 3.11 either, so that has to be migrated to pytest.
> cqlsh - module 're' has no attribute 'sre_parse' - with Python 3.11
> ---
>
> Key: CASSANDRA-18088
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18088
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: Aaron Ploetz
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 4.x
>
>
> User reported an error with cqlsh (Cassandra 4.0.7) on Stack Overflow:
> [https://stackoverflow.com/questions/74673247/cannot-able-to-run-cqlsh-due-to-python-attribute-error|https://stackoverflow.com/questions/74673247/cannot-able-to-run-cqlsh-due-to-python-attribute-error?noredirect=1#comment131807816_74673247]
>
> Found out that the user was using Python 3.11, and I was able to reproduce it
> with that.
> {{% python3.11 bin/cqlsh.py}}
> {{Traceback (most recent call last):}}
> {{ File "/Users/aaronploetz/local/apache-cassandra-4.0.7/bin/cqlsh.py", line
> 159, in }}
> {{ from cqlshlib import cql3handling, cqlhandling, pylexotron,
> sslhandling, cqlshhandling}}
> {{ File
> "/Users/aaronploetz/local/apache-cassandra-4.0.7/bin/../pylib/cqlshlib/cql3handling.py",
> line 19, in }}
> {{ from cqlshlib.cqlhandling import CqlParsingRuleSet, Hint}}
> {{ File
> "/Users/aaronploetz/local/apache-cassandra-4.0.7/bin/../pylib/cqlshlib/cqlhandling.py",
> line 23, in }}
> {{ from cqlshlib import pylexotron, util}}
> {{ File
> "/Users/aaronploetz/local/apache-cassandra-4.0.7/bin/../pylib/cqlshlib/pylexotron.py",
> line 342, in }}
> {{ class ParsingRuleSet:}}
> {{ File
> "/Users/aaronploetz/local/apache-cassandra-4.0.7/bin/../pylib/cqlshlib/pylexotron.py",
> line 343, in ParsingRuleSet}}
> {{ RuleSpecScanner = SaferScanner([}}
> {{ ^^}}
> {{ File
> "/Users/aaronploetz/local/apache-cassandra-4.0.7/bin/../pylib/cqlshlib/saferscanner.py",
> line 91, in _{_}init{_}_}}
> {{ s = re.sre_parse.State()}}
> {{ }}
> {{AttributeError: module 're' has no attribute 'sre_parse'}}
> Appears to be something specific (again) with Python's synchronizing regex
> engine (SRE). Works fine with Python 3.10, so there may have been a(nother)
> breaking change in that the re module with 3.11.
--
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-17112) CEP-15: (C*) Strict Serializability verification
[ https://issues.apache.org/jira/browse/CASSANDRA-17112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17648744#comment-17648744 ] David Capwell commented on CASSANDRA-17112: --- have a patch up, still doing more testing and still debating how I want to deal with StrictSerializabilityVerifier (don't like 2 projects having the same or similar logic, but sharing requires more work that I don't know is worth it) > CEP-15: (C*) Strict Serializability verification > > > Key: CASSANDRA-17112 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17112 > Project: Cassandra > Issue Type: New Feature > Components: Accord >Reporter: Benedict Elliott Smith >Assignee: David Capwell >Priority: Normal > Fix For: NA > > -- 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-11994) Expose metrics via CQL interface
[ https://issues.apache.org/jira/browse/CASSANDRA-11994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov reassigned CASSANDRA-11994: --- Assignee: Maxim Muzafarov > Expose metrics via CQL interface > > > Key: CASSANDRA-11994 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11994 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Observability, Observability/Metrics >Reporter: Patrick McFadin >Assignee: Maxim Muzafarov >Priority: Normal > Labels: cql, operations > > This is an attempt to revive the concept introduced in CASSANDRA-3527. > Instead of specifically targeting JMX metrics, simplify by just exposing > metrics into CQL tables as a dynamic view. > Exposing these metrics will give operators vital insight without resorting to > anything more than what is installed with Apache Cassandra. > The scope of these tickets is only for reading metrics with a SELECT command. > The actual data model can be discussed in the comments below. > Some basic requirements I would propose: > - SELECT syntax should allow for single node or cluster wide statistics > - Aggregations should be supported (min, max, avg) > - Inside metric tables, future column additions should be automatically > created when new metrics are added to a family > - Large schema changes such as deletes should be postponed to a major > release -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-14361) Allow SimpleSeedProvider to resolve multiple IPs per DNS name
[ https://issues.apache.org/jira/browse/CASSANDRA-14361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17648721#comment-17648721 ] Stefan Miklosovic edited comment on CASSANDRA-14361 at 12/16/22 4:39 PM: - [~adelapena] What branches do we want this to be in? I think just trunk will be ok as this is basically a new feature? was (Author: smiklosovic): [~adelapena] What branches we this to be in? I think just trunk will be ok as this is basically a new feature? > Allow SimpleSeedProvider to resolve multiple IPs per DNS name > - > > Key: CASSANDRA-14361 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14361 > Project: Cassandra > Issue Type: Improvement > Components: Local/Config >Reporter: Ben Bromhead >Assignee: Stefan Miklosovic >Priority: Low > Fix For: 4.0.x > > Time Spent: 40m > Remaining Estimate: 0h > > Currently SimpleSeedProvider can accept a comma separated string of IPs or > hostnames as the set of Cassandra seeds. hostnames are resolved via > InetAddress.getByName, which will only return the first IP associated with an > A, or CNAME record. > By changing to InetAddress.getAllByName, existing behavior is preserved, but > now Cassandra can discover multiple IP address per record, allowing seed > discovery by DNS to be a little easier. > Some examples of improved workflows with this change include: > * specify the DNS name of a headless service in Kubernetes which will > resolve to all IP addresses of pods within that service. > * seed discovery for multi-region clusters via AWS route53, AzureDNS etc > * Other common DNS service discovery mechanisms. > The only behavior this is likely to impact would be where users are relying > on the fact that getByName only returns a single IP address. > I can't imagine any scenario where that is a sane choice. Even when that > choice has been made, it only impacts the first startup of Cassandra and > would not be on any critical path. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14361) Allow SimpleSeedProvider to resolve multiple IPs per DNS name
[ https://issues.apache.org/jira/browse/CASSANDRA-14361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17648721#comment-17648721 ] Stefan Miklosovic commented on CASSANDRA-14361: --- [~adelapena] What branches we this to be in? I think just trunk will be ok as this is basically a new feature? > Allow SimpleSeedProvider to resolve multiple IPs per DNS name > - > > Key: CASSANDRA-14361 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14361 > Project: Cassandra > Issue Type: Improvement > Components: Local/Config >Reporter: Ben Bromhead >Assignee: Stefan Miklosovic >Priority: Low > Fix For: 4.0.x > > Time Spent: 40m > Remaining Estimate: 0h > > Currently SimpleSeedProvider can accept a comma separated string of IPs or > hostnames as the set of Cassandra seeds. hostnames are resolved via > InetAddress.getByName, which will only return the first IP associated with an > A, or CNAME record. > By changing to InetAddress.getAllByName, existing behavior is preserved, but > now Cassandra can discover multiple IP address per record, allowing seed > discovery by DNS to be a little easier. > Some examples of improved workflows with this change include: > * specify the DNS name of a headless service in Kubernetes which will > resolve to all IP addresses of pods within that service. > * seed discovery for multi-region clusters via AWS route53, AzureDNS etc > * Other common DNS service discovery mechanisms. > The only behavior this is likely to impact would be where users are relying > on the fact that getByName only returns a single IP address. > I can't imagine any scenario where that is a sane choice. Even when that > choice has been made, it only impacts the first startup of Cassandra and > would not be on any critical path. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-14361) Allow SimpleSeedProvider to resolve multiple IPs per DNS name
[ https://issues.apache.org/jira/browse/CASSANDRA-14361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic reassigned CASSANDRA-14361: - Assignee: Stefan Miklosovic (was: Ben Bromhead) > Allow SimpleSeedProvider to resolve multiple IPs per DNS name > - > > Key: CASSANDRA-14361 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14361 > Project: Cassandra > Issue Type: Improvement > Components: Local/Config >Reporter: Ben Bromhead >Assignee: Stefan Miklosovic >Priority: Low > Fix For: 4.0.x > > Time Spent: 40m > Remaining Estimate: 0h > > Currently SimpleSeedProvider can accept a comma separated string of IPs or > hostnames as the set of Cassandra seeds. hostnames are resolved via > InetAddress.getByName, which will only return the first IP associated with an > A, or CNAME record. > By changing to InetAddress.getAllByName, existing behavior is preserved, but > now Cassandra can discover multiple IP address per record, allowing seed > discovery by DNS to be a little easier. > Some examples of improved workflows with this change include: > * specify the DNS name of a headless service in Kubernetes which will > resolve to all IP addresses of pods within that service. > * seed discovery for multi-region clusters via AWS route53, AzureDNS etc > * Other common DNS service discovery mechanisms. > The only behavior this is likely to impact would be where users are relying > on the fact that getByName only returns a single IP address. > I can't imagine any scenario where that is a sane choice. Even when that > choice has been made, it only impacts the first startup of Cassandra and > would not be on any critical path. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14361) Allow SimpleSeedProvider to resolve multiple IPs per DNS name
[ https://issues.apache.org/jira/browse/CASSANDRA-14361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-14361: -- Status: In Progress (was: Changes Suggested) > Allow SimpleSeedProvider to resolve multiple IPs per DNS name > - > > Key: CASSANDRA-14361 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14361 > Project: Cassandra > Issue Type: Improvement > Components: Local/Config >Reporter: Ben Bromhead >Assignee: Stefan Miklosovic >Priority: Low > Fix For: 4.0.x > > Time Spent: 40m > Remaining Estimate: 0h > > Currently SimpleSeedProvider can accept a comma separated string of IPs or > hostnames as the set of Cassandra seeds. hostnames are resolved via > InetAddress.getByName, which will only return the first IP associated with an > A, or CNAME record. > By changing to InetAddress.getAllByName, existing behavior is preserved, but > now Cassandra can discover multiple IP address per record, allowing seed > discovery by DNS to be a little easier. > Some examples of improved workflows with this change include: > * specify the DNS name of a headless service in Kubernetes which will > resolve to all IP addresses of pods within that service. > * seed discovery for multi-region clusters via AWS route53, AzureDNS etc > * Other common DNS service discovery mechanisms. > The only behavior this is likely to impact would be where users are relying > on the fact that getByName only returns a single IP address. > I can't imagine any scenario where that is a sane choice. Even when that > choice has been made, it only impacts the first startup of Cassandra and > would not be on any critical path. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-8928) Add downgradesstables
[ https://issues.apache.org/jira/browse/CASSANDRA-8928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] T Jake Luciani updated CASSANDRA-8928: -- Reviewers: T Jake Luciani > Add downgradesstables > - > > Key: CASSANDRA-8928 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8928 > Project: Cassandra > Issue Type: New Feature > Components: Legacy/Tools >Reporter: Jeremy Hanna >Assignee: Claude Warren >Priority: Low > Labels: remove-reopen > Fix For: 4.x > > > As mentioned in other places such as CASSANDRA-8047 and in the wild, > sometimes you need to go back. A downgrade sstables utility would be nice > for a lot of reasons and I don't know that supporting going back to the > previous major version format would be too much code since we already support > reading the previous version. -- 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-8928) Add downgradesstables
[ https://issues.apache.org/jira/browse/CASSANDRA-8928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] T Jake Luciani updated CASSANDRA-8928: -- Fix Version/s: 4.x > Add downgradesstables > - > > Key: CASSANDRA-8928 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8928 > Project: Cassandra > Issue Type: New Feature > Components: Legacy/Tools >Reporter: Jeremy Hanna >Assignee: Claude Warren >Priority: Low > Labels: remove-reopen > Fix For: 4.x > > > As mentioned in other places such as CASSANDRA-8047 and in the wild, > sometimes you need to go back. A downgrade sstables utility would be nice > for a lot of reasons and I don't know that supporting going back to the > previous major version format would be too much code since we already support > reading the previous version. -- 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-18123) Reuse of metadata collector can break key count calculation
[
https://issues.apache.org/jira/browse/CASSANDRA-18123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-18123:
-
Bug Category: Parent values: Degradation(12984)Level 1 values: Performance
Bug/Regression(12997)
Complexity: Normal
Discovered By: User Report
Fix Version/s: 3.0.x
3.11.x
4.0.x
4.1.x
4.x
Severity: Normal
Status: Open (was: Triage Needed)
> Reuse of metadata collector can break key count calculation
> ---
>
> Key: CASSANDRA-18123
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18123
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Compaction
>Reporter: Branimir Lambov
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x
>
>
> When flushing a memtable we currently pass a constructed
> {{MetadataCollector}} to the {{SSTableMultiWriter}} that is used for writing
> sstables. The latter may decide to split the data into multiple sstables
> (e.g. for separate disks or driven by compaction strategy) — if it does so,
> the cardinality estimation component in the reused {{MetadataCollector}} for
> each individual sstable contains the data for all of them.
> As a result, when such sstables are compacted the estimation for the number
> of keys in the resulting sstables, which is used to determine the size of the
> bloom filter for the compaction result, is heavily overestimated.
> This results in much bigger L1 bloom filters than they should be. One example
> (which came about during testing of the upcoming CEP-26, after insertion of
> 100GB data with 10% reads):
> (current)
> {code}
> Bloom filter false positives: 22627369
> Bloom filter false ratio: 0.02257
> Bloom filter space used: 1848247864
> Bloom filter off heap memory used: 2338964088
> {code}
> (fixed)
> {code}
> Bloom filter false positives: 24426545
> Bloom filter false ratio: 0.02429
> Bloom filter space used: 1118910096
> Bloom filter off heap memory used: 1532357432
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-8928) Add downgradesstables
[ https://issues.apache.org/jira/browse/CASSANDRA-8928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17648684#comment-17648684 ] T Jake Luciani edited comment on CASSANDRA-8928 at 12/16/22 3:33 PM: - [~claude] has written an initial [PR|https://github.com/apache/cassandra/pull/2045] that supports downgrading via an offline tool (like sstableupgrader) Following a similar approach described in [this comment|https://issues.apache.org/jira/browse/CASSANDRA-11877?focusedCommentId=15310504=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15310504]. It requires extending the same contract we have in place for major upgrades. We support reading from the last major sstable version and we support reading/writing to the previous MessagingService version. With this PR we add the ability to Write SSTables in the prior major format (though with a new format key which includes the major version it belongs to). This will allow someone who wants to revert major versions a simpler path. Just stop each node (w/ flush), run offline downgrader, then restart with previous version. This will require some new docs and also a sstable downgrade dtest as well. Would it be ok to re-assign this ticket to Claude? was (Author: tjake): [~claude] has written an initial [PR|https://github.com/apache/cassandra/pull/2045] that supports downgrading via an offline tool (like sstableupgrader) Following a similar approach described in this comment. It requires extending the same contract we have in place for major upgrades. We support reading from the last major sstable version and we support reading/writing to the previous MessagingService version. With this PR we add the ability to Write SSTables in the prior major format (though with a new format key which includes the major version it belongs to). This will allow someone who wants to revert major versions a simpler path. Just stop each node (w/ flush), run offline downgrader, then restart with previous version. This will require some new docs and also a sstable downgrade dtest as well. Would it be ok to re-assign this ticket to Claude? > Add downgradesstables > - > > Key: CASSANDRA-8928 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8928 > Project: Cassandra > Issue Type: New Feature > Components: Legacy/Tools >Reporter: Jeremy Hanna >Assignee: Claude Warren >Priority: Low > Labels: remove-reopen > > As mentioned in other places such as CASSANDRA-8047 and in the wild, > sometimes you need to go back. A downgrade sstables utility would be nice > for a lot of reasons and I don't know that supporting going back to the > previous major version format would be too much code since we already support > reading the previous version. -- 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-8928) Add downgradesstables
[ https://issues.apache.org/jira/browse/CASSANDRA-8928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] T Jake Luciani updated CASSANDRA-8928: -- Labels: remove-reopen (was: gsoc2016 mentor remove-reopen) > Add downgradesstables > - > > Key: CASSANDRA-8928 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8928 > Project: Cassandra > Issue Type: New Feature > Components: Legacy/Tools >Reporter: Jeremy Hanna >Assignee: Claude Warren >Priority: Low > Labels: remove-reopen > > As mentioned in other places such as CASSANDRA-8047 and in the wild, > sometimes you need to go back. A downgrade sstables utility would be nice > for a lot of reasons and I don't know that supporting going back to the > previous major version format would be too much code since we already support > reading the previous version. -- 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-8928) Add downgradesstables
[ https://issues.apache.org/jira/browse/CASSANDRA-8928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17648690#comment-17648690 ] Paulo Motta commented on CASSANDRA-8928: reassigned to [~claude] as I think previous assignee is inactive. > Add downgradesstables > - > > Key: CASSANDRA-8928 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8928 > Project: Cassandra > Issue Type: New Feature > Components: Legacy/Tools >Reporter: Jeremy Hanna >Assignee: Claude Warren >Priority: Low > Labels: gsoc2016, mentor, remove-reopen > > As mentioned in other places such as CASSANDRA-8047 and in the wild, > sometimes you need to go back. A downgrade sstables utility would be nice > for a lot of reasons and I don't know that supporting going back to the > previous major version format would be too much code since we already support > reading the previous version. -- 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-8928) Add downgradesstables
[ https://issues.apache.org/jira/browse/CASSANDRA-8928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paulo Motta reassigned CASSANDRA-8928: -- Assignee: Claude Warren (was: Kaide Mu) > Add downgradesstables > - > > Key: CASSANDRA-8928 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8928 > Project: Cassandra > Issue Type: New Feature > Components: Legacy/Tools >Reporter: Jeremy Hanna >Assignee: Claude Warren >Priority: Low > Labels: gsoc2016, mentor, remove-reopen > > As mentioned in other places such as CASSANDRA-8047 and in the wild, > sometimes you need to go back. A downgrade sstables utility would be nice > for a lot of reasons and I don't know that supporting going back to the > previous major version format would be too much code since we already support > reading the previous version. -- 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-14361) Allow SimpleSeedProvider to resolve multiple IPs per DNS name
[ https://issues.apache.org/jira/browse/CASSANDRA-14361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17648687#comment-17648687 ] Jonathan Koppenhofer commented on CASSANDRA-14361: -- Did this stop for a reason. Is there a plan to commit this? > Allow SimpleSeedProvider to resolve multiple IPs per DNS name > - > > Key: CASSANDRA-14361 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14361 > Project: Cassandra > Issue Type: Improvement > Components: Local/Config >Reporter: Ben Bromhead >Assignee: Ben Bromhead >Priority: Low > Fix For: 4.0.x > > Time Spent: 40m > Remaining Estimate: 0h > > Currently SimpleSeedProvider can accept a comma separated string of IPs or > hostnames as the set of Cassandra seeds. hostnames are resolved via > InetAddress.getByName, which will only return the first IP associated with an > A, or CNAME record. > By changing to InetAddress.getAllByName, existing behavior is preserved, but > now Cassandra can discover multiple IP address per record, allowing seed > discovery by DNS to be a little easier. > Some examples of improved workflows with this change include: > * specify the DNS name of a headless service in Kubernetes which will > resolve to all IP addresses of pods within that service. > * seed discovery for multi-region clusters via AWS route53, AzureDNS etc > * Other common DNS service discovery mechanisms. > The only behavior this is likely to impact would be where users are relying > on the fact that getByName only returns a single IP address. > I can't imagine any scenario where that is a sane choice. Even when that > choice has been made, it only impacts the first startup of Cassandra and > would not be on any critical path. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-8928) Add downgradesstables
[ https://issues.apache.org/jira/browse/CASSANDRA-8928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17648684#comment-17648684 ] T Jake Luciani commented on CASSANDRA-8928: --- [~claude] has written an initial [PR|https://github.com/apache/cassandra/pull/2045] that supports downgrading via an offline tool (like sstableupgrader) Following a similar approach described in this comment. It requires extending the same contract we have in place for major upgrades. We support reading from the last major sstable version and we support reading/writing to the previous MessagingService version. With this PR we add the ability to Write SSTables in the prior major format (though with a new format key which includes the major version it belongs to). This will allow someone who wants to revert major versions a simpler path. Just stop each node (w/ flush), run offline downgrader, then restart with previous version. This will require some new docs and also a sstable downgrade dtest as well. Would it be ok to re-assign this ticket to Claude? > Add downgradesstables > - > > Key: CASSANDRA-8928 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8928 > Project: Cassandra > Issue Type: New Feature > Components: Legacy/Tools >Reporter: Jeremy Hanna >Assignee: Kaide Mu >Priority: Low > Labels: gsoc2016, mentor, remove-reopen > > As mentioned in other places such as CASSANDRA-8047 and in the wild, > sometimes you need to go back. A downgrade sstables utility would be nice > for a lot of reasons and I don't know that supporting going back to the > previous major version format would be too much code since we already support > reading the previous version. -- 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-18124) Config parameter keystore_password should be nullable
[ https://issues.apache.org/jira/browse/CASSANDRA-18124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17648680#comment-17648680 ] Ekaterina Dimitrova commented on CASSANDRA-18124: - CC [~maulin.vasavada], [~stefan.miklosovic] and [~jonmeredith] If we want to allow the null value we need to mark the parameter with @Nullable in the codebase as the default value is not null > Config parameter keystore_password should be nullable > - > > Key: CASSANDRA-18124 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18124 > Project: Cassandra > Issue Type: Bug >Reporter: Tibor Repasi >Priority: Normal > > Some SSL configuration may pass unencrypted private keys. PEMReader might > accept that by assuming keyPassword to be null in that case (e.g. > https://github.com/apache/cassandra/blob/f9e033f519c14596da4dc954875756a69aea4e78/src/java/org/apache/cassandra/security/PEMReader.java#L103). > Current configuration reader does not accept keystore_password parameter to > be set null or empty in the cassandra.yaml. -- 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-18124) Config parameter keystore_password should be nullable
[ https://issues.apache.org/jira/browse/CASSANDRA-18124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Repasi updated CASSANDRA-18124: - Description: Some SSL configuration may pass unencrypted private keys. PEMReader might accept that by assuming keyPassword to be null in that case (e.g. https://github.com/apache/cassandra/blob/f9e033f519c14596da4dc954875756a69aea4e78/src/java/org/apache/cassandra/security/PEMReader.java#L103). Current configuration reader does not accept keystore_password parameter to be set null or empty in the cassandra.yaml. was:Some SSL configuration may pass unencrypted private keys. PEMReader might accept that by assuming keyPassword to be null in that case (e.g. https://github.com/apache/cassandra/blob/f9e033f519c14596da4dc954875756a69aea4e78/src/java/org/apache/cassandra/security/PEMReader.java#L103). > Config parameter keystore_password should be nullable > - > > Key: CASSANDRA-18124 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18124 > Project: Cassandra > Issue Type: Bug >Reporter: Tibor Repasi >Priority: Normal > > Some SSL configuration may pass unencrypted private keys. PEMReader might > accept that by assuming keyPassword to be null in that case (e.g. > https://github.com/apache/cassandra/blob/f9e033f519c14596da4dc954875756a69aea4e78/src/java/org/apache/cassandra/security/PEMReader.java#L103). > Current configuration reader does not accept keystore_password parameter to > be set null or empty in the cassandra.yaml. -- 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-18124) Config parameter keystore_password should be nullable
Tibor Repasi created CASSANDRA-18124: Summary: Config parameter keystore_password should be nullable Key: CASSANDRA-18124 URL: https://issues.apache.org/jira/browse/CASSANDRA-18124 Project: Cassandra Issue Type: Bug Reporter: Tibor Repasi Some SSL configuration may pass unencrypted private keys. PEMReader might accept that by assuming keyPassword to be null in that case (e.g. https://github.com/apache/cassandra/blob/f9e033f519c14596da4dc954875756a69aea4e78/src/java/org/apache/cassandra/security/PEMReader.java#L103). -- 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-17503) Request to port the DSE rebuild options to Cassandra
[ https://issues.apache.org/jira/browse/CASSANDRA-17503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17648672#comment-17648672 ] Jonathan Koppenhofer commented on CASSANDRA-17503: -- +1 on this. > Request to port the DSE rebuild options to Cassandra > > > Key: CASSANDRA-17503 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17503 > Project: Cassandra > Issue Type: New Feature >Reporter: Paul Ayers >Priority: High > Fix For: 4.x > > > Testing rebuild in C* 4.0.1, I ran into a scenario where 'nodetool rebuild' > was ran without any options in a new DC and the system.available_ranges_v2 > table was populated such that every subsequent run of 'nodetool rebuild > ' streamed no data. > The problem was that the first run looked at only the new DC so no data was > streamed, then the next run that provided the correct source DC still > resulted in no streamed data. > Once the system.available_ranges_v2 table was truncated, rebuild worked as > expected. > The request here is to include the same code that allows the following > options to be used in DSE so one could easily resolve this by using '-m > reset' in a similar scenario: > -m, --mode mode > * normal - conventional behavior, streams only ranges that are not already > locally available > * refetch - resets locally available ranges, streams all ranges but leaves > current data untouched > * reset - resets the locally available ranges, removes all locally present > data (like a TRUNCATE), streams all ranges > * reset-no-snapshot - (like reset) resets the locally available ranges, > removes all locally present data (like a TRUNCATE), streams all ranges but > prevents a snapshot even if auto_snapshot is enabled > Protecting against updating the available_ranges table if a local DC was > chosen might also be a good idea. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18061) Add compaction type output result for nodetool compactionhistory
[ https://issues.apache.org/jira/browse/CASSANDRA-18061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17648654#comment-17648654 ] Stefan Miklosovic edited comment on CASSANDRA-18061 at 12/16/22 2:32 PM: - [~maxwellguo] I have fixed more things in this commit (1). Please include that commit into your branch. Some tests are failing in CompactionHistoryTest because you do not check the result of `anyMatch` in compactionHistoryResultVerify method. When I check that it returns true, it fails. Please fix these tests. Thank you. (1) https://github.com/instaclustr/cassandra/commit/e4f5c2adfa89c5431a05bf8836975c87eb70023c was (Author: smiklosovic): [~maxwellguo] I have fixed more things in this commit (1). Please include that commit into your branch. Some tests are failing in CompactionHistoryTest because you do not check the result of `anyMatch` in compactionHistoryResultVerify method. When I check that it returns true, it fails. Please fix these tests. Thank you. (1) https://github.com/instaclustr/cassandra/commit/f71afd10a3d6a3e21b427165252b66d9be23ae50 > Add compaction type output result for nodetool compactionhistory > > > Key: CASSANDRA-18061 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18061 > Project: Cassandra > Issue Type: Improvement > Components: Local/Compaction, Tool/nodetool >Reporter: maxwellguo >Assignee: maxwellguo >Priority: Low > Fix For: 4.x > > Time Spent: 2h > Remaining Estimate: 0h > > If we want to see whether we have made a compaction and what kind of > compaction we have done for this node, we may go to see the > compaction_history system table for some deftails or use nodetool > compactionhistory command , But I found that the table do not specify the > compaction type so does the compactionhistory command too, like index build , > compaction type, clean or scrub for this node. So I think may be it is need > to add a type of compaction column to specify the compaction tpe for > system.compaction_history and so we can get the type of compaction through > system.compaction_history table or nodetool compactionhistory to see whether > we have made a major compact for this node .:) -- 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-18061) Add compaction type output result for nodetool compactionhistory
[ https://issues.apache.org/jira/browse/CASSANDRA-18061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17648654#comment-17648654 ] Stefan Miklosovic commented on CASSANDRA-18061: --- [~maxwellguo] I have fixed more things in this commit (1). Please include that commit into your branch. Some tests are failing in CompactionHistoryTest because you do not check the result of `anyMatch` in compactionHistoryResultVerify method. When I check that it returns true, it fails. Please fix these tests. Thank you. (1) https://github.com/instaclustr/cassandra/commit/f71afd10a3d6a3e21b427165252b66d9be23ae50 > Add compaction type output result for nodetool compactionhistory > > > Key: CASSANDRA-18061 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18061 > Project: Cassandra > Issue Type: Improvement > Components: Local/Compaction, Tool/nodetool >Reporter: maxwellguo >Assignee: maxwellguo >Priority: Low > Fix For: 4.x > > Time Spent: 2h > Remaining Estimate: 0h > > If we want to see whether we have made a compaction and what kind of > compaction we have done for this node, we may go to see the > compaction_history system table for some deftails or use nodetool > compactionhistory command , But I found that the table do not specify the > compaction type so does the compactionhistory command too, like index build , > compaction type, clean or scrub for this node. So I think may be it is need > to add a type of compaction column to specify the compaction tpe for > system.compaction_history and so we can get the type of compaction through > system.compaction_history table or nodetool compactionhistory to see whether > we have made a major compact for this node .:) -- 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-18123) Reuse of metadata collector can break key count calculation
[
https://issues.apache.org/jira/browse/CASSANDRA-18123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Branimir Lambov updated CASSANDRA-18123:
Since Version: 3.0.0
> Reuse of metadata collector can break key count calculation
> ---
>
> Key: CASSANDRA-18123
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18123
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Compaction
>Reporter: Branimir Lambov
>Priority: Normal
>
> When flushing a memtable we currently pass a constructed
> {{MetadataCollector}} to the {{SSTableMultiWriter}} that is used for writing
> sstables. The latter may decide to split the data into multiple sstables
> (e.g. for separate disks or driven by compaction strategy) — if it does so,
> the cardinality estimation component in the reused {{MetadataCollector}} for
> each individual sstable contains the data for all of them.
> As a result, when such sstables are compacted the estimation for the number
> of keys in the resulting sstables, which is used to determine the size of the
> bloom filter for the compaction result, is heavily overestimated.
> This results in much bigger L1 bloom filters than they should be. One example
> (which came about during testing of the upcoming CEP-26, after insertion of
> 100GB data with 10% reads):
> (current)
> {code}
> Bloom filter false positives: 22627369
> Bloom filter false ratio: 0.02257
> Bloom filter space used: 1848247864
> Bloom filter off heap memory used: 2338964088
> {code}
> (fixed)
> {code}
> Bloom filter false positives: 24426545
> Bloom filter false ratio: 0.02429
> Bloom filter space used: 1118910096
> Bloom filter off heap memory used: 1532357432
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-18123) Reuse of metadata collector can break key count calculation
Branimir Lambov created CASSANDRA-18123:
---
Summary: Reuse of metadata collector can break key count
calculation
Key: CASSANDRA-18123
URL: https://issues.apache.org/jira/browse/CASSANDRA-18123
Project: Cassandra
Issue Type: Bug
Components: Local/Compaction
Reporter: Branimir Lambov
When flushing a memtable we currently pass a constructed {{MetadataCollector}}
to the {{SSTableMultiWriter}} that is used for writing sstables. The latter may
decide to split the data into multiple sstables (e.g. for separate disks or
driven by compaction strategy) — if it does so, the cardinality estimation
component in the reused {{MetadataCollector}} for each individual sstable
contains the data for all of them.
As a result, when such sstables are compacted the estimation for the number of
keys in the resulting sstables, which is used to determine the size of the
bloom filter for the compaction result, is heavily overestimated.
This results in much bigger L1 bloom filters than they should be. One example
(which came about during testing of the upcoming CEP-26, after insertion of
100GB data with 10% reads):
(current)
{code}
Bloom filter false positives: 22627369
Bloom filter false ratio: 0.02257
Bloom filter space used: 1848247864
Bloom filter off heap memory used: 2338964088
{code}
(fixed)
{code}
Bloom filter false positives: 24426545
Bloom filter false ratio: 0.02429
Bloom filter space used: 1118910096
Bloom filter off heap memory used: 1532357432
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17797) All system properties and environment variables should be accessed via the new CassandraRelevantProperties and CassandraRelevantEnv classes
[ https://issues.apache.org/jira/browse/CASSANDRA-17797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17648597#comment-17648597 ] Maxim Muzafarov commented on CASSANDRA-17797: - [~e.dimitrova], [~smiklosovic] I'm not familiar with the Butler tool, however, I think I figured out how it works. Despite that, I've failed to find any documentation pages (on Google, or Apache Wiki) and sources. Do you have any links to share? Here is the link to the comparsion: [https://butler.cassandra.apache.org/?#/ci/upstream/compare/Cassandra-trunk/cassandra-17797] I've checked tests labelled with `rgrsn` locally and it seems those test fails are not related to my changes. I think despite the fact that the test flask they may start to fall with another error/stack trace - does the Butler cover this case? Nevertheless, I've checked them too for an errors related to system properties. This failing tests I've also re-run locally: [https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2103/testReport/] Sorry, if I've missed something. I didn't have and experience with this tool yet. > All system properties and environment variables should be accessed via the > new CassandraRelevantProperties and CassandraRelevantEnv classes > --- > > Key: CASSANDRA-17797 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17797 > Project: Cassandra > Issue Type: Improvement > Components: Local/Config >Reporter: Ekaterina Dimitrova >Assignee: Maxim Muzafarov >Priority: Low > Fix For: 4.x > > Time Spent: 10m > Remaining Estimate: 0h > > Follow up ticket for CASSANDRA-15876 - > "Always access system properties and environment variables via the new > CassandraRelevantProperties and CassandraRelevantEnv classes" > As part of that ticket we moved to the two new classes only > properties/variables that were currently listed in System Properties Virtual > Table. > We have to move to those classes the rest of the properties around the code > and start using those classes to access all of them. > +Additional information for newcomers:+ > You might want to start by getting acquainted with > CassandraRelevantProperties and CassandraRelevantEnv classes. Also, you might > want to check what changes were done and how the first batch was transferred > to this new framework as part of > [CASSANDRA-15876|https://github.com/apache/cassandra/commit/7694c1d191531ac152db55e83bc0db6864a5441e] > We are interested into the properties accessed currently through > getProperties around the code. > As part of CASSANDRA-15876 relevant unit tests were added > (CassandraRelevantPropertiesTest). To verify the new patch we need to ensure > that all tests Cassandra pass and also to think about potential update of the > mentioned test 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] [Comment Edited] (CASSANDRA-18088) cqlsh - module 're' has no attribute 'sre_parse' - with Python 3.11
[
https://issues.apache.org/jira/browse/CASSANDRA-18088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17648588#comment-17648588
]
Brandon Williams edited comment on CASSANDRA-18088 at 12/16/22 12:05 PM:
-
Unfortunately, no, we need A: make the dtests work under 3.11.
was (Author: brandon.williams):
Unfortunately, no,we need A: make the dtests work under 3.11.
> cqlsh - module 're' has no attribute 'sre_parse' - with Python 3.11
> ---
>
> Key: CASSANDRA-18088
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18088
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: Aaron Ploetz
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 4.x
>
>
> User reported an error with cqlsh (Cassandra 4.0.7) on Stack Overflow:
> [https://stackoverflow.com/questions/74673247/cannot-able-to-run-cqlsh-due-to-python-attribute-error|https://stackoverflow.com/questions/74673247/cannot-able-to-run-cqlsh-due-to-python-attribute-error?noredirect=1#comment131807816_74673247]
>
> Found out that the user was using Python 3.11, and I was able to reproduce it
> with that.
> {{% python3.11 bin/cqlsh.py}}
> {{Traceback (most recent call last):}}
> {{ File "/Users/aaronploetz/local/apache-cassandra-4.0.7/bin/cqlsh.py", line
> 159, in }}
> {{ from cqlshlib import cql3handling, cqlhandling, pylexotron,
> sslhandling, cqlshhandling}}
> {{ File
> "/Users/aaronploetz/local/apache-cassandra-4.0.7/bin/../pylib/cqlshlib/cql3handling.py",
> line 19, in }}
> {{ from cqlshlib.cqlhandling import CqlParsingRuleSet, Hint}}
> {{ File
> "/Users/aaronploetz/local/apache-cassandra-4.0.7/bin/../pylib/cqlshlib/cqlhandling.py",
> line 23, in }}
> {{ from cqlshlib import pylexotron, util}}
> {{ File
> "/Users/aaronploetz/local/apache-cassandra-4.0.7/bin/../pylib/cqlshlib/pylexotron.py",
> line 342, in }}
> {{ class ParsingRuleSet:}}
> {{ File
> "/Users/aaronploetz/local/apache-cassandra-4.0.7/bin/../pylib/cqlshlib/pylexotron.py",
> line 343, in ParsingRuleSet}}
> {{ RuleSpecScanner = SaferScanner([}}
> {{ ^^}}
> {{ File
> "/Users/aaronploetz/local/apache-cassandra-4.0.7/bin/../pylib/cqlshlib/saferscanner.py",
> line 91, in _{_}init{_}_}}
> {{ s = re.sre_parse.State()}}
> {{ }}
> {{AttributeError: module 're' has no attribute 'sre_parse'}}
> Appears to be something specific (again) with Python's synchronizing regex
> engine (SRE). Works fine with Python 3.10, so there may have been a(nother)
> breaking change in that the re module with 3.11.
--
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-16555) Add out-of-the-box snitch for Ec2 IMDSv2
[ https://issues.apache.org/jira/browse/CASSANDRA-16555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17648594#comment-17648594 ] Brandon Williams commented on CASSANDRA-16555: -- I think it's better to not risk any regressions in the existing snitch. Choosing which one to use is minimal, one-time overhead. > Add out-of-the-box snitch for Ec2 IMDSv2 > > > Key: CASSANDRA-16555 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16555 > Project: Cassandra > Issue Type: New Feature > Components: Consistency/Coordination >Reporter: Paul Rütter (BlueConic) >Assignee: fulco taen >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x > > Time Spent: 1.5h > Remaining Estimate: 0h > > In order to patch a vulnerability, Amazon came up with a new version of their > metadata service. > It's no longer unrestricted but now requires a token (in a header), in order > to access the metadata service. > See > [https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html] > for more information. > Cassandra currently doesn't offer an out-of-the-box snitch class to support > this. > See > [https://cassandra.apache.org/doc/latest/operating/snitch.html#snitch-classes] > This issue asks to add support for this as a separate snitch class. > We'll probably do a PR for this, as we are in the process of developing 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-18088) cqlsh - module 're' has no attribute 'sre_parse' - with Python 3.11
[
https://issues.apache.org/jira/browse/CASSANDRA-18088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17648588#comment-17648588
]
Brandon Williams commented on CASSANDRA-18088:
--
Unfortunately, no,we need A: make the dtests work under 3.11.
> cqlsh - module 're' has no attribute 'sre_parse' - with Python 3.11
> ---
>
> Key: CASSANDRA-18088
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18088
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: Aaron Ploetz
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 4.x
>
>
> User reported an error with cqlsh (Cassandra 4.0.7) on Stack Overflow:
> [https://stackoverflow.com/questions/74673247/cannot-able-to-run-cqlsh-due-to-python-attribute-error|https://stackoverflow.com/questions/74673247/cannot-able-to-run-cqlsh-due-to-python-attribute-error?noredirect=1#comment131807816_74673247]
>
> Found out that the user was using Python 3.11, and I was able to reproduce it
> with that.
> {{% python3.11 bin/cqlsh.py}}
> {{Traceback (most recent call last):}}
> {{ File "/Users/aaronploetz/local/apache-cassandra-4.0.7/bin/cqlsh.py", line
> 159, in }}
> {{ from cqlshlib import cql3handling, cqlhandling, pylexotron,
> sslhandling, cqlshhandling}}
> {{ File
> "/Users/aaronploetz/local/apache-cassandra-4.0.7/bin/../pylib/cqlshlib/cql3handling.py",
> line 19, in }}
> {{ from cqlshlib.cqlhandling import CqlParsingRuleSet, Hint}}
> {{ File
> "/Users/aaronploetz/local/apache-cassandra-4.0.7/bin/../pylib/cqlshlib/cqlhandling.py",
> line 23, in }}
> {{ from cqlshlib import pylexotron, util}}
> {{ File
> "/Users/aaronploetz/local/apache-cassandra-4.0.7/bin/../pylib/cqlshlib/pylexotron.py",
> line 342, in }}
> {{ class ParsingRuleSet:}}
> {{ File
> "/Users/aaronploetz/local/apache-cassandra-4.0.7/bin/../pylib/cqlshlib/pylexotron.py",
> line 343, in ParsingRuleSet}}
> {{ RuleSpecScanner = SaferScanner([}}
> {{ ^^}}
> {{ File
> "/Users/aaronploetz/local/apache-cassandra-4.0.7/bin/../pylib/cqlshlib/saferscanner.py",
> line 91, in _{_}init{_}_}}
> {{ s = re.sre_parse.State()}}
> {{ }}
> {{AttributeError: module 're' has no attribute 'sre_parse'}}
> Appears to be something specific (again) with Python's synchronizing regex
> engine (SRE). Works fine with Python 3.10, so there may have been a(nother)
> breaking change in that the re module with 3.11.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16555) Add out-of-the-box snitch for Ec2 IMDSv2
[
https://issues.apache.org/jira/browse/CASSANDRA-16555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17648566#comment-17648566
]
Thomas Steinmaurer edited comment on CASSANDRA-16555 at 12/16/22 10:55 AM:
---
I wonder if the dedicated/separate snitch implementation is the best way to
move forward, if I may challenge that :).
Perhaps would it make more sense to extend the existing {{Ec2Snitch}}
implementation to make it configurable for being used to IMDSv2 or perhaps even
smarter in a way, that it first automatically detects what is available on the
EC2 instance and then simply uses that behind the scene?
was (Author: tsteinmaurer):
I wonder if the dedicated/separate is the best way to move forward, if I may
challenge that :).
Perhaps would it make more sense to extend the existing \{{Ec2Snitch}}
implementation to make it configurable for being used to IMDSv2 or perhaps even
smarter in a way, that it first automatically detects what is available on the
EC2 instance and then simply uses that behind the scene?
> Add out-of-the-box snitch for Ec2 IMDSv2
>
>
> Key: CASSANDRA-16555
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16555
> Project: Cassandra
> Issue Type: New Feature
> Components: Consistency/Coordination
>Reporter: Paul Rütter (BlueConic)
>Assignee: fulco taen
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> In order to patch a vulnerability, Amazon came up with a new version of their
> metadata service.
> It's no longer unrestricted but now requires a token (in a header), in order
> to access the metadata service.
> See
> [https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html]
> for more information.
> Cassandra currently doesn't offer an out-of-the-box snitch class to support
> this.
> See
> [https://cassandra.apache.org/doc/latest/operating/snitch.html#snitch-classes]
> This issue asks to add support for this as a separate snitch class.
> We'll probably do a PR for this, as we are in the process of developing 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-16555) Add out-of-the-box snitch for Ec2 IMDSv2
[
https://issues.apache.org/jira/browse/CASSANDRA-16555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17648566#comment-17648566
]
Thomas Steinmaurer commented on CASSANDRA-16555:
I wonder if the dedicated/separate is the best way to move forward, if I may
challenge that :).
Perhaps would it make more sense to extend the existing \{{Ec2Snitch}}
implementation to make it configurable for being used to IMDSv2 or perhaps even
smarter in a way, that it first automatically detects what is available on the
EC2 instance and then simply uses that behind the scene?
> Add out-of-the-box snitch for Ec2 IMDSv2
>
>
> Key: CASSANDRA-16555
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16555
> Project: Cassandra
> Issue Type: New Feature
> Components: Consistency/Coordination
>Reporter: Paul Rütter (BlueConic)
>Assignee: fulco taen
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> In order to patch a vulnerability, Amazon came up with a new version of their
> metadata service.
> It's no longer unrestricted but now requires a token (in a header), in order
> to access the metadata service.
> See
> [https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html]
> for more information.
> Cassandra currently doesn't offer an out-of-the-box snitch class to support
> this.
> See
> [https://cassandra.apache.org/doc/latest/operating/snitch.html#snitch-classes]
> This issue asks to add support for this as a separate snitch class.
> We'll probably do a PR for this, as we are in the process of developing 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-18061) Add compaction type output result for nodetool compactionhistory
[ https://issues.apache.org/jira/browse/CASSANDRA-18061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17648432#comment-17648432 ] maxwellguo commented on CASSANDRA-18061: [~smiklosovic]Thank you for your commets, I have modify the code and leave a commet reply on the PR. :D > Add compaction type output result for nodetool compactionhistory > > > Key: CASSANDRA-18061 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18061 > Project: Cassandra > Issue Type: Improvement > Components: Local/Compaction, Tool/nodetool >Reporter: maxwellguo >Assignee: maxwellguo >Priority: Low > Fix For: 4.x > > Time Spent: 1h 40m > Remaining Estimate: 0h > > If we want to see whether we have made a compaction and what kind of > compaction we have done for this node, we may go to see the > compaction_history system table for some deftails or use nodetool > compactionhistory command , But I found that the table do not specify the > compaction type so does the compactionhistory command too, like index build , > compaction type, clean or scrub for this node. So I think may be it is need > to add a type of compaction column to specify the compaction tpe for > system.compaction_history and so we can get the type of compaction through > system.compaction_history table or nodetool compactionhistory to see whether > we have made a major compact for this node .:) -- 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-18061) Add compaction type output result for nodetool compactionhistory
[ https://issues.apache.org/jira/browse/CASSANDRA-18061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-18061: -- Status: Review In Progress (was: Patch Available) > Add compaction type output result for nodetool compactionhistory > > > Key: CASSANDRA-18061 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18061 > Project: Cassandra > Issue Type: Improvement > Components: Local/Compaction, Tool/nodetool >Reporter: maxwellguo >Assignee: maxwellguo >Priority: Low > Fix For: 4.x > > Time Spent: 1h 10m > Remaining Estimate: 0h > > If we want to see whether we have made a compaction and what kind of > compaction we have done for this node, we may go to see the > compaction_history system table for some deftails or use nodetool > compactionhistory command , But I found that the table do not specify the > compaction type so does the compactionhistory command too, like index build , > compaction type, clean or scrub for this node. So I think may be it is need > to add a type of compaction column to specify the compaction tpe for > system.compaction_history and so we can get the type of compaction through > system.compaction_history table or nodetool compactionhistory to see whether > we have made a major compact for this node .:) -- 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-18061) Add compaction type output result for nodetool compactionhistory
[ https://issues.apache.org/jira/browse/CASSANDRA-18061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-18061: -- Status: Changes Suggested (was: Review In Progress) > Add compaction type output result for nodetool compactionhistory > > > Key: CASSANDRA-18061 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18061 > Project: Cassandra > Issue Type: Improvement > Components: Local/Compaction, Tool/nodetool >Reporter: maxwellguo >Assignee: maxwellguo >Priority: Low > Fix For: 4.x > > Time Spent: 1h 10m > Remaining Estimate: 0h > > If we want to see whether we have made a compaction and what kind of > compaction we have done for this node, we may go to see the > compaction_history system table for some deftails or use nodetool > compactionhistory command , But I found that the table do not specify the > compaction type so does the compactionhistory command too, like index build , > compaction type, clean or scrub for this node. So I think may be it is need > to add a type of compaction column to specify the compaction tpe for > system.compaction_history and so we can get the type of compaction through > system.compaction_history table or nodetool compactionhistory to see whether > we have made a major compact for this node .:) -- 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-18061) Add compaction type output result for nodetool compactionhistory
[ https://issues.apache.org/jira/browse/CASSANDRA-18061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17648419#comment-17648419 ] Stefan Miklosovic commented on CASSANDRA-18061: --- [~maxwellguo] I put more commets to PR. Please check. Thank you. > Add compaction type output result for nodetool compactionhistory > > > Key: CASSANDRA-18061 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18061 > Project: Cassandra > Issue Type: Improvement > Components: Local/Compaction, Tool/nodetool >Reporter: maxwellguo >Assignee: maxwellguo >Priority: Low > Fix For: 4.x > > Time Spent: 1h 10m > Remaining Estimate: 0h > > If we want to see whether we have made a compaction and what kind of > compaction we have done for this node, we may go to see the > compaction_history system table for some deftails or use nodetool > compactionhistory command , But I found that the table do not specify the > compaction type so does the compactionhistory command too, like index build , > compaction type, clean or scrub for this node. So I think may be it is need > to add a type of compaction column to specify the compaction tpe for > system.compaction_history and so we can get the type of compaction through > system.compaction_history table or nodetool compactionhistory to see whether > we have made a major compact for this node .:) -- 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
