[cassandra-website] branch asf-staging updated (f614cbbf -> 7aa0a507)
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 f614cbbf generate docs for c84757a0
add eb5e2e7b BLOG - Announcing Monthly Town Halls
new 7aa0a507 generate docs for eb5e2e7b
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 (f614cbbf)
\
N -- N -- N refs/heads/asf-staging (7aa0a507)
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:
content/_/blog.html| 24 +++
...ncing-Monthly-Apache-Cassandra-Town-Halls.html} | 75 -
content/search-index.js| 2 +-
site-content/source/modules/ROOT/pages/blog.adoc | 24 +++
...uncing-Monthly-Apache-Cassandra-Town-Halls.adoc | 34 ++
site-ui/build/ui-bundle.zip| Bin 4796900 -> 4796900
bytes
6 files changed, 111 insertions(+), 48 deletions(-)
copy content/_/blog/{World-Party-2022.html =>
Announcing-Monthly-Apache-Cassandra-Town-Halls.html} (77%)
create mode 100644
site-content/source/modules/ROOT/pages/blog/Announcing-Monthly-Apache-Cassandra-Town-Halls.adoc
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18452) BLOG - Announcing Monthly Apache Cassandra Town Halls
[
https://issues.apache.org/jira/browse/CASSANDRA-18452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17714432#comment-17714432
]
Erick Ramirez commented on CASSANDRA-18452:
---
The website content is getting built in staging:
||Branch||PR||Commit||Build||
|{{trunk}}|[#216|https://github.com/apache/cassandra-website/pull/216]|[eb5e2e7
|https://github.com/apache/cassandra-website/commit/eb5e2e7b4b9ad28550e5ae03be2a4da8e8d9426b]|[#1099|https://ci-cassandra.apache.org/job/cassandra-website/1099/]|
> BLOG - Announcing Monthly Apache Cassandra Town Halls
> -
>
> Key: CASSANDRA-18452
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18452
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Blog
>Reporter: Diogenese Topper
>Assignee: Diogenese Topper
>Priority: Normal
> Fix For: NA
>
> Attachments: CASSANDRA-18452.patch+v2.txt, c18452-01-blog-index.png,
> c18452-02-blog-post.png
>
>
> This ticket is to capture the work associated with publishing the April 2023
> blog "Announcing Monthly Apache Cassandra Town Halls"
> If this blog cannot be published by the *April 14, 2022 publish date*, 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-18452) BLOG - Announcing Monthly Apache Cassandra Town Halls
[
https://issues.apache.org/jira/browse/CASSANDRA-18452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Ramirez updated CASSANDRA-18452:
--
Fix Version/s: NA
Source Control Link:
https://github.com/apache/cassandra-website/commit/eb5e2e7b4b9ad28550e5ae03be2a4da8e8d9426b
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Committed:
||Branch||PR||Commit||
|{{trunk}}|[#216|https://github.com/apache/cassandra-website/pull/216]|[eb5e2e7|https://github.com/apache/cassandra-website/commit/eb5e2e7b4b9ad28550e5ae03be2a4da8e8d9426b]|
> BLOG - Announcing Monthly Apache Cassandra Town Halls
> -
>
> Key: CASSANDRA-18452
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18452
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Blog
>Reporter: Diogenese Topper
>Assignee: Diogenese Topper
>Priority: Normal
> Fix For: NA
>
> Attachments: CASSANDRA-18452.patch+v2.txt, c18452-01-blog-index.png,
> c18452-02-blog-post.png
>
>
> This ticket is to capture the work associated with publishing the April 2023
> blog "Announcing Monthly Apache Cassandra Town Halls"
> If this blog cannot be published by the *April 14, 2022 publish date*, 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
[cassandra-website] branch trunk updated: BLOG - Announcing Monthly Town Halls
This is an automated email from the ASF dual-hosted git repository. erickramirezau pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra-website.git The following commit(s) were added to refs/heads/trunk by this push: new eb5e2e7b BLOG - Announcing Monthly Town Halls eb5e2e7b is described below commit eb5e2e7b4b9ad28550e5ae03be2a4da8e8d9426b Author: Diogenese Topper AuthorDate: Fri Apr 14 16:46:35 2023 -0700 BLOG - Announcing Monthly Town Halls Patch by Diogenese Topper; reviewed by Erick Ramirez for CASSANDRA-18452 --- site-content/source/modules/ROOT/pages/blog.adoc | 24 +++ ...uncing-Monthly-Apache-Cassandra-Town-Halls.adoc | 34 ++ 2 files changed, 58 insertions(+) diff --git a/site-content/source/modules/ROOT/pages/blog.adoc b/site-content/source/modules/ROOT/pages/blog.adoc index ee32401a..af9598ae 100644 --- a/site-content/source/modules/ROOT/pages/blog.adoc +++ b/site-content/source/modules/ROOT/pages/blog.adoc @@ -8,6 +8,30 @@ NOTES FOR CONTENT CREATORS - Replace post tile, date, description and link to you post. +//start card +[openblock,card shadow relative test] + +[openblock,card-header] +-- +[discrete] +=== Announcing Monthly Town Halls +[discrete] + April 19, 2023 +-- +[openblock,card-content] +-- +Join us for the kickoff of our new monthly live, virtual Town Hall meetings. + +[openblock,card-btn card-btn--blog] + +[.btn.btn--alt] +xref:blog/Announcing-Monthly-Apache-Cassandra-Town-Halls.adoc[Read More] + + +-- + +//end card + //start card [openblock,card shadow relative test] diff --git a/site-content/source/modules/ROOT/pages/blog/Announcing-Monthly-Apache-Cassandra-Town-Halls.adoc b/site-content/source/modules/ROOT/pages/blog/Announcing-Monthly-Apache-Cassandra-Town-Halls.adoc new file mode 100644 index ..563576e1 --- /dev/null +++ b/site-content/source/modules/ROOT/pages/blog/Announcing-Monthly-Apache-Cassandra-Town-Halls.adoc @@ -0,0 +1,34 @@ += Announcing Monthly Town Halls +:page-layout: single-post +:page-role: blog-post +:page-post-date: April 19, 2023 +:page-post-author: The Apache Cassandra Community +:description: Announcement of monthly virtual town halls. +:keywords: + +As the Apache Cassandra® community grows, it is important that we have dedicated forums to gather, share, and learn. With this in mind, we are kicking off monthly live, virtual Town Hall meetings starting this month. **Our very first Town Hall is on April 26 at 9am PT, and https://www.meetup.com/cassandra-global/events/292858262/[you can register here^]**. We’ll also be hosting an “Ask Me Anything” (AMA) on https://discord.com/invite/Ut8YctQWac[Planet Cassandra Discord^] following the event. + +### What to expect from Cassandra Town Halls + +Our goal with Town Halls is to provide a forum for users of Cassandra to come together - whether you’re brand new or have been using it for years. During the meetings you can share what you’ve learned on your Cassandra journey and hear valuable lessons from your peers. You can expect project and release updates from community leaders, as well as info about what’s coming for Cassandra, and guidance on how you can participate. + +Going forward, meetings are scheduled to be live-streamed on Zoom the **fourth Thursday of the month at 8am PT**. However, we want to find a time that works for most, so https://calendly.com/d/z2m-jps-68c/may-cassandra-town-hall-virtual-meeting[please take this poll^] to let us know what works best for you. We’ll do our best to adjust accordingly. We’ll also make recordings immediately available on https://www.youtube.com/@PlanetCassandra/streams[the Planet Cassandra YouTube channel^]. + +### Agenda for our first Town Hall + +For our inaugural event, we are excited that https://www.linkedin.com/in/rustyrazorblade/[Jon Haddad^] will share what Netflix has learned along their Cassandra journey. Project Management Committee lead, https://www.linkedin.com/in/josh-mckenzie-59b38b14/[Josh MacKenzie^] will also give a project update. There will be space to meet each other and ask questions. + +### Join the post-Town Hall Discord AMA + +Immediately after our Town Hall (April 26 at 10am PT), join our hosts and the community on the Planet Cassandra Discord for an AMA. This AMA is an extension of the Town Hall, offering more time and space for you to learn and engage. We’ll be there live until 11am PT, but rest assured, if you’re not there live, we’ll be checking back frequently to answer questions async throughout the day. + +### How to Join the Meeting + +Ready to attend? Copy the invite from the public https://calendar.google.com/calendar/u/0?cid=a2w5cHVoZ2s3cXRkdXFhdHRlOHRmZDVtcHNAZ3JvdXAuY2FsZW5kYXIuZ29vZ2xlLmNvbQ[Cassandra Community Meeting Calendar^]. + +Hope to see you there! And as always, don’t be shy about sharing feedback on Town Halls. We wa
[jira] [Comment Edited] (CASSANDRA-18452) BLOG - Announcing Monthly Apache Cassandra Town Halls
[
https://issues.apache.org/jira/browse/CASSANDRA-18452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17714427#comment-17714427
]
Erick Ramirez edited comment on CASSANDRA-18452 at 4/20/23 6:31 AM:
I've completed the review and made the necessary changes in commit {{f0cf0af}}
(see [^CASSANDRA-18452.patch+v2.txt]). This ticket is READY TO COMMIT.
!c18452-01-blog-index.png|width=300!
!c18452-02-blog-post.png|width=300!
was (Author: JIRAUSER285101):
I've made the necessary changes in commit {{f0cf0af}} (see
[^CASSANDRA-18452.patch+v2.txt]). This ticket is READY TO COMMIT.
> BLOG - Announcing Monthly Apache Cassandra Town Halls
> -
>
> Key: CASSANDRA-18452
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18452
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Blog
>Reporter: Diogenese Topper
>Assignee: Diogenese Topper
>Priority: Normal
> Attachments: CASSANDRA-18452.patch+v2.txt, c18452-01-blog-index.png,
> c18452-02-blog-post.png
>
>
> This ticket is to capture the work associated with publishing the April 2023
> blog "Announcing Monthly Apache Cassandra Town Halls"
> If this blog cannot be published by the *April 14, 2022 publish date*, 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-18452) BLOG - Announcing Monthly Apache Cassandra Town Halls
[
https://issues.apache.org/jira/browse/CASSANDRA-18452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Ramirez updated CASSANDRA-18452:
--
Status: Ready to Commit (was: Changes Suggested)
I've made the necessary changes in commit {{f0cf0af}} (see
[^CASSANDRA-18452.patch+v2.txt]). This ticket is READY TO COMMIT.
> BLOG - Announcing Monthly Apache Cassandra Town Halls
> -
>
> Key: CASSANDRA-18452
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18452
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Blog
>Reporter: Diogenese Topper
>Assignee: Diogenese Topper
>Priority: Normal
> Attachments: CASSANDRA-18452.patch+v2.txt, c18452-01-blog-index.png,
> c18452-02-blog-post.png
>
>
> This ticket is to capture the work associated with publishing the April 2023
> blog "Announcing Monthly Apache Cassandra Town Halls"
> If this blog cannot be published by the *April 14, 2022 publish date*, 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-18452) BLOG - Announcing Monthly Apache Cassandra Town Halls
[ https://issues.apache.org/jira/browse/CASSANDRA-18452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Ramirez updated CASSANDRA-18452: -- Attachment: CASSANDRA-18452.patch+v2.txt > BLOG - Announcing Monthly Apache Cassandra Town Halls > - > > Key: CASSANDRA-18452 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18452 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Diogenese Topper >Assignee: Diogenese Topper >Priority: Normal > Attachments: CASSANDRA-18452.patch+v2.txt, c18452-01-blog-index.png, > c18452-02-blog-post.png > > > This ticket is to capture the work associated with publishing the April 2023 > blog "Announcing Monthly Apache Cassandra Town Halls" > If this blog cannot be published by the *April 14, 2022 publish date*, 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-18452) BLOG - Announcing Monthly Apache Cassandra Town Halls
[
https://issues.apache.org/jira/browse/CASSANDRA-18452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Ramirez updated CASSANDRA-18452:
--
Status: Changes Suggested (was: Review In Progress)
Suggested changes:
* Shorten the title so it renders better on the page
* Update publish date to {{April 19}}
* Add link to YouTube channel in the third paragraph
* Add links to Jon's + Josh's LinkedIn
* Update AMA end time to {{11am}}
* Replace Slack link with bit.ly since it doesn't render on the page due to
the tilde ({{~}}) character
> BLOG - Announcing Monthly Apache Cassandra Town Halls
> -
>
> Key: CASSANDRA-18452
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18452
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Blog
>Reporter: Diogenese Topper
>Assignee: Diogenese Topper
>Priority: Normal
> Attachments: c18452-01-blog-index.png, c18452-02-blog-post.png
>
>
> This ticket is to capture the work associated with publishing the April 2023
> blog "Announcing Monthly Apache Cassandra Town Halls"
> If this blog cannot be published by the *April 14, 2022 publish date*, 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-18452) BLOG - Announcing Monthly Apache Cassandra Town Halls
[ https://issues.apache.org/jira/browse/CASSANDRA-18452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Ramirez updated CASSANDRA-18452: -- Attachment: c18452-02-blog-post.png c18452-01-blog-index.png > BLOG - Announcing Monthly Apache Cassandra Town Halls > - > > Key: CASSANDRA-18452 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18452 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Diogenese Topper >Assignee: Diogenese Topper >Priority: Normal > Attachments: c18452-01-blog-index.png, c18452-02-blog-post.png > > > This ticket is to capture the work associated with publishing the April 2023 > blog "Announcing Monthly Apache Cassandra Town Halls" > If this blog cannot be published by the *April 14, 2022 publish date*, 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-18018) List command output not correct for super user, after grant command
[
https://issues.apache.org/jira/browse/CASSANDRA-18018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17714419#comment-17714419
]
Maxim Chanturiay commented on CASSANDRA-18018:
--
[~samt] thanks for pointing out the problematic cases!
I will look them over and fix.
In general, I believe that user should experience the `LIST PERMISSIONS` output
without any need for additional thought. The output should be precise enough
for them to not think over if permissions were bypassed or granted.
Do we need to figure all of the possible edge cases now? Probably this is not
worth the effort, as we're not talking about a code break or unexpected
management of data. The fix is nice to have, not critical. Worst case scenario
- an additional bug will be opened :)
> List command output not correct for super user, after grant command
> ---
>
> Key: CASSANDRA-18018
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18018
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Authorization
>Reporter: Shailaja Koppu
>Assignee: Maxim Chanturiay
>Priority: Normal
> Labels: lhf
> Fix For: 4.1.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Running local Cassandra with below config:
> {noformat}
> authenticator: PasswordAuthenticator
> authorizer: CassandraAuthorizer
> role_manager: CassandraRoleManager
> network_authorizer: CassandraNetworkAuthorizer{noformat}
> Created a super user and then ran *Grant select* command on a keyspace.
> {noformat}
> shaadmin1@cqlsh> CREATE USER 'shaadmin1c1' WITH PASSWORD 'shaadmin1c1'
> SUPERUSER;
> shaadmin1@cqlsh:system_auth> grant select on testk1.t1 to shaadmin1c1;
> shaadmin1@cqlsh:system_auth> alter role shaadmin1c1 with access to all
> datacenters;
> {noformat}
>
> After this, list permissions command showing only select permission for that
> role on the resource.
> {noformat}
> shaadmin1c1@cqlsh> list all permissions of shaadmin1c1;
> role | username | resource | permission
> +---
> shaadmin1c1 | shaadmin1c1 | | SELECT
> {noformat}
>
> Row in role_permissions table:
> {noformat}
> role | resource | permissions
> --
> shaadmin1c1 | data/testk1/t1 | {'SELECT'}{noformat}
> But insert command by that role on the resource is successful because role is
> a super user
> {noformat}
> shaadmin1c1@cqlsh> insert into testk1.t1 (c1, c2) values ('a', 1);
> shaadmin1c1@cqlsh> select * from testk1.t1 ;
> c1 | c2
> ---+---
> a | 1
> (1 rows)
> {noformat}
>
> The problem is, output of list permissions command, which indicates only
> select permission on the resource, is misleading. I think list command need
> to be fixed to show all permissions super user has on the resource. Also
> grant command for a super user can be either a no-op or throw error, because
> the role already have requested permissions.
>
> Documentation also misleading:
> {quote}True automatically grants AUTHORIZE, CREATE and DROP permission on ALL
> ROLES.
> Superusers can only manage roles by default. To manage other resources,
> {color:#ff}you must grant the permission set to that resource. **
> {color}For example, to allow access management for all keyspaces: {{{}GRANT
> ALL PERMISSIONS ON ALL KEYSPACES TO }}\{{{}{*}role_name{*}{}}}.
> {quote}
>
>
>
--
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-18452) BLOG - Announcing Monthly Apache Cassandra Town Halls
[ https://issues.apache.org/jira/browse/CASSANDRA-18452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Ramirez updated CASSANDRA-18452: -- Reviewers: Erick Ramirez Status: Review In Progress (was: Patch Available) > BLOG - Announcing Monthly Apache Cassandra Town Halls > - > > Key: CASSANDRA-18452 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18452 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Diogenese Topper >Assignee: Diogenese Topper >Priority: Normal > > This ticket is to capture the work associated with publishing the April 2023 > blog "Announcing Monthly Apache Cassandra Town Halls" > If this blog cannot be published by the *April 14, 2022 publish date*, 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-18452) BLOG - Announcing Monthly Apache Cassandra Town Halls
[ https://issues.apache.org/jira/browse/CASSANDRA-18452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Ramirez updated CASSANDRA-18452: -- Summary: BLOG - Announcing Monthly Apache Cassandra Town Halls (was: WEBSITE - April 2023 blog "Announcing Monthly Apache Cassandra Town Halls") > BLOG - Announcing Monthly Apache Cassandra Town Halls > - > > Key: CASSANDRA-18452 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18452 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Diogenese Topper >Assignee: Diogenese Topper >Priority: Normal > > This ticket is to capture the work associated with publishing the April 2023 > blog "Announcing Monthly Apache Cassandra Town Halls" > If this blog cannot be published by the *April 14, 2022 publish date*, 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] [Assigned] (CASSANDRA-18452) WEBSITE - April 2023 blog "Announcing Monthly Apache Cassandra Town Halls"
[ https://issues.apache.org/jira/browse/CASSANDRA-18452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Ramirez reassigned CASSANDRA-18452: - Assignee: Diogenese Topper > WEBSITE - April 2023 blog "Announcing Monthly Apache Cassandra Town Halls" > -- > > Key: CASSANDRA-18452 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18452 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Diogenese Topper >Assignee: Diogenese Topper >Priority: Normal > > This ticket is to capture the work associated with publishing the April 2023 > blog "Announcing Monthly Apache Cassandra Town Halls" > If this blog cannot be published by the *April 14, 2022 publish date*, 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-18466) Paxos only repair is treated as an incremental repair
[
https://issues.apache.org/jira/browse/CASSANDRA-18466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17714388#comment-17714388
]
maxwellguo commented on CASSANDRA-18466:
nodetool repair will doing incremental repair by default if --full is not set.
> Paxos only repair is treated as an incremental repair
> -
>
> Key: CASSANDRA-18466
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18466
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Repair
>Reporter: Andrew
>Priority: Normal
> Fix For: 4.1.x, 5.x
>
>
> Paxos only repair tries to continue or is treated as an incremental repair.
> This happened on 4.1.0 and 4.1.1 when trying to run repair in preparation for
> enabling paxos_state_purging. The repair was in preparation mode triggered
> multiple anti-compactions on the nodes. Running the command with --full
> behaves in the expected way, ie. only the paxos data is repaired and it's
> finished within a few seconds.
> {code:java}
> nodetool repair --paxos-only // This does not behave as expected, does it
> complete quickly and seems to be waiting on anticompactions
> {code}
> {code:java}
> nodetool repair --full --paxos-only // Completes within a few seconds as
> expected
> {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-18329) Upgrade jamm
[ https://issues.apache.org/jira/browse/CASSANDRA-18329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17714372#comment-17714372 ] Ekaterina Dimitrova commented on CASSANDRA-18329: - Thank you[~jbellis]! I didn’t know about this one. Appreciate you shared it! I took a very quick look and it seems to me it cannot be a direct replacement? It seems jamm is handling more than it. We are working on having Jamm ready for JDK17 and applying fixes for previous JDK versions. It should be back on track with new release soon. CC[~blerer] We also need it fixed for 4.0 and 4.1 where we anyway would not be allowed to make full replacement of libraries in a released version. > Upgrade jamm > > > Key: CASSANDRA-18329 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18329 > Project: Cassandra > Issue Type: Task > Components: Jamm >Reporter: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.0.x, 4.1.x, 5.x > > > Jamm is currently under maintenance that will solve JDK11 issues and enable > it to work with post JDK11+ versions up to JDK17. > This ticket will serve as a placeholder for upgrading Jamm in Cassandra when > the new Jamm release is out. -- 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-18467) Update generate-idea-files for J17
[ https://issues.apache.org/jira/browse/CASSANDRA-18467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17714293#comment-17714293 ] Michael Semb Wever commented on CASSANDRA-18467: Can we list what folk want/need from a jdk17 intellij profile please. Running tests, and attaching to them, is easy to do without such a profile. This will help validate the need, and/or what dev recipes/tips should be better documented. > Update generate-idea-files for J17 > -- > > Key: CASSANDRA-18467 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18467 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Ekaterina Dimitrova >Priority: Low > Fix For: 5.x > > > There was a discussion in CASSANDRA-18258 how to update generate-idea-files. > The final agreement was to create one target to cover both Java 11 and Java > 17. > It will be good to figure out CASSANDRA-18263 and reshuffle arguments and > tasks based on what we decide to use as gc in testing for both Java 11 and > Java 17. -- 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-18260) Add details to Error message: Not enough space for compaction
[
https://issues.apache.org/jira/browse/CASSANDRA-18260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henrik Ingo updated CASSANDRA-18260:
Mentor: Michael Semb Wever
Status: Review In Progress (was: Changes Suggested)
> Add details to Error message: Not enough space for compaction
> --
>
> Key: CASSANDRA-18260
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18260
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Compaction, Observability/Logging
>Reporter: Brad Schoening
>Assignee: Henrik Ingo
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.x
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> When compaction fails, the log message should list a) the free space
> available on disk at that point in time and b) perhaps the number and/or size
> of the source sstables being compacted.
> Free space can change from one moment to the next, so when the below
> compaction failed because it needed 161GB, upon checking the server a few
> minutes later, it had 184GB free. Similarly, the error message mentions it
> was writing out one SSTable on this STCS table, but its not clear if it was
> combining X -> 1 tables, or something else.
> {noformat}
> [INFO ] [CompactionExecutor:77758] cluster_id=87 ip_address=127.1.1.1
> CompactionTask.java:241 - Compacted (8a1cffe0-abb5-11ed-b3fc-8d2ac2c52f0d) 1
> sstables to [...] to level=0. 86.997GiB to 86.997GiB (~99% of original) in
> 1,508,155ms. Read Throughput = 59.069MiB/s, Write Throughput = 59.069MiB/s,
> Row Throughput = ~20,283/s. 21,375 total partitions merged to 21,375.
> Partition merge counts were \{1:21375, }
> [ERROR] [CompactionExecutor:4] cluster_id=87 ip_address=127.1.1.1
> CassandraDaemon.java:581 - Exception in thread
> Thread[CompactionExecutor:4,1,main]
> java.lang.RuntimeException: Not enough space for compaction, estimated
> sstables = 1, expected write size = 161228934093
> at
> org.apache.cassandra.db.compaction.CompactionTask.buildCompactionCandidatesForAvailableDiskSpace(CompactionTask.java:386)
> at
> org.apache.cassandra.db.compaction.CompactionTask.runMayThrow(CompactionTask.java:126)
> at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> at
> org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:77)
> at
> org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:100)
> at
> org.apache.cassandra.db.compaction.CompactionManager$7.execute(CompactionManager.java:613)
> at
> org.apache.cassandra.db.compaction.CompactionManager$2.call(CompactionManager.java:377)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:834)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18468) Evaluate fuzzer that found 18108 and others
[ https://issues.apache.org/jira/browse/CASSANDRA-18468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17714256#comment-17714256 ] Abe Ratnofsky commented on CASSANDRA-18468: --- [~zagol] I'm especially interested in the grammar-guided fuzzer. Can you share more information about that here? Or, if there's a repo you can share, I'd be interested to take a look. > Evaluate fuzzer that found 18108 and others > --- > > Key: CASSANDRA-18468 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18468 > Project: Cassandra > Issue Type: Improvement > Components: Test/fuzz >Reporter: Abe Ratnofsky >Priority: Normal > > [~yongle] and [~kehan5800] have a fuzzer that has found several Cassandra > bugs, including CASSANDRA-18108 and others. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18108) Data loss after a system restart/upgrade (3.11.14)
[
https://issues.apache.org/jira/browse/CASSANDRA-18108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17714255#comment-17714255
]
Abe Ratnofsky commented on CASSANDRA-18108:
---
[~zagol] Thanks for providing more info on your fuzzer. Could we move that to a
new ticket to avoid distracting from this particular issue:
https://issues.apache.org/jira/browse/CASSANDRA-18468
> Data loss after a system restart/upgrade (3.11.14)
> --
>
> Key: CASSANDRA-18108
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18108
> Project: Cassandra
> Issue Type: Bug
>Reporter: Ke Han
>Priority: Normal
>
> When we upgrade Cassandra from 3.11.14 to 4.0.7, we found a data loss during
> the upgrade process. This bug can also be triggered if simply performing a
> system restart.
> h1. Steps to reproduce
> Start a 3.11.14 or 4.0.7 Cassandra node using default configurations. Execute
> the following cqlsh commands.
> {code:java}
> CREATE KEYSPACE ks WITH REPLICATION = { 'class' : 'SimpleStrategy',
> 'replication_factor' : 1 };
> CREATE TABLE IF NOT EXISTS ks.tb (c1 INT,c3 INT,c2 TEXT, PRIMARY KEY (c1 ))
> WITH speculative_retry = 'ALWAYS';
> INSERT INTO ks.tb (c1, c2) VALUES (2,'val');
> ALTER TABLE ks.tb DROP c2 ;
> ALTER TABLE ks.tb RENAME c1 TO c2; {code}
> Then execute a SELECT command, we get the correct data
> {code:java}
> cqlsh> SELECT * FROM ks.tb;
> c2 | c3
> +--
> 2 | null
> (1 rows){code}
> Flush and stop the Cassandra daemon.
> {code:java}
> bin/nodetool flush
> bin/nodetool stopdaemon{code}
> Then restart the node.
> {code:java}
> bin/cassandra{code}
> Start cqlsh, and execute the same SELECT command. The data in ks.tb is lost.
> {code:java}
> cqlsh> SELECT * FROM ks.tb;
> c2 | c3
> +
> (0 rows){code}
>
> During the node restart, we found an error log about initializing the table,
> but it didn't prevent the system from starting up.
> {code:java}
> INFO [main] 2022-12-09 21:37:54,234 ColumnFamilyStore.java:432 -
> Initializing ks.tb
> ERROR [SSTableBatchOpen:1] 2022-12-09 21:37:54,237 CassandraDaemon.java:244 -
> Exception in thread Thread[SSTableBatchOpen:1,5,main]
> java.lang.AssertionError: null
> at
> org.apache.cassandra.db.PartitionColumns$Builder.add(PartitionColumns.java:161)
> at
> org.apache.cassandra.db.SerializationHeader$Component.toHeader(SerializationHeader.java:340)
> at
> org.apache.cassandra.io.sstable.format.SSTableReader.open(SSTableReader.java:522)
> at
> org.apache.cassandra.io.sstable.format.SSTableReader.open(SSTableReader.java:385)
> at
> org.apache.cassandra.io.sstable.format.SSTableReader$3.run(SSTableReader.java:570)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:84)
> at java.lang.Thread.run(Thread.java:750) {code}
>
> This bug can also be triggered if we perform an upgrade from 3.11.14 to 4.0.7
> and execute the SELECT command in the new version. (*The token_num
> configuration in 4.0.7 is modified to 16 for upgrade compatibility purposes,
> all the other configurations are using default values)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-18468) Evaluate fuzzer that found 18108 and others
Abe Ratnofsky created CASSANDRA-18468: - Summary: Evaluate fuzzer that found 18108 and others Key: CASSANDRA-18468 URL: https://issues.apache.org/jira/browse/CASSANDRA-18468 Project: Cassandra Issue Type: Improvement Components: Test/fuzz Reporter: Abe Ratnofsky [~yongle] and [~kehan5800] have a fuzzer that has found several Cassandra bugs, including CASSANDRA-18108 and others. -- 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-18467) Update generate-idea-files for J17
[ https://issues.apache.org/jira/browse/CASSANDRA-18467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-18467: Epic Link: CASSANDRA-16895 > Update generate-idea-files for J17 > -- > > Key: CASSANDRA-18467 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18467 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Ekaterina Dimitrova >Priority: Low > Fix For: 5.x > > > There was a discussion in CASSANDRA-18258 how to update generate-idea-files. > The final agreement was to create one target to cover both Java 11 and Java > 17. > It will be good to figure out CASSANDRA-18263 and reshuffle arguments and > tasks based on what we decide to use as gc in testing for both Java 11 and > Java 17. -- 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-18467) Update generate-idea-files for J17
[ https://issues.apache.org/jira/browse/CASSANDRA-18467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-18467: Change Category: Quality Assurance Complexity: Low Hanging Fruit Component/s: Build Priority: Low (was: Normal) Status: Open (was: Triage Needed) > Update generate-idea-files for J17 > -- > > Key: CASSANDRA-18467 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18467 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Ekaterina Dimitrova >Priority: Low > > There was a discussion in CASSANDRA-18258 how to update generate-idea-files. > The final agreement was to create one target to cover both Java 11 and Java > 17. > It will be good to figure out CASSANDRA-18263 and reshuffle arguments and > tasks based on what we decide to use as gc in testing for both Java 11 and > Java 17. -- 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-18467) Update generate-idea-files for J17
Ekaterina Dimitrova created CASSANDRA-18467: --- Summary: Update generate-idea-files for J17 Key: CASSANDRA-18467 URL: https://issues.apache.org/jira/browse/CASSANDRA-18467 Project: Cassandra Issue Type: Task Reporter: Ekaterina Dimitrova There was a discussion in CASSANDRA-18258 how to update generate-idea-files. The final agreement was to create one target to cover both Java 11 and Java 17. It will be good to figure out CASSANDRA-18263 and reshuffle arguments and tasks based on what we decide to use as gc in testing for both Java 11 and Java 17. -- 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-18467) Update generate-idea-files for J17
[ https://issues.apache.org/jira/browse/CASSANDRA-18467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-18467: Fix Version/s: 5.x > Update generate-idea-files for J17 > -- > > Key: CASSANDRA-18467 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18467 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Ekaterina Dimitrova >Priority: Low > Fix For: 5.x > > > There was a discussion in CASSANDRA-18258 how to update generate-idea-files. > The final agreement was to create one target to cover both Java 11 and Java > 17. > It will be good to figure out CASSANDRA-18263 and reshuffle arguments and > tasks based on what we decide to use as gc in testing for both Java 11 and > Java 17. -- 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&focusedCommentId=17714247#comment-17714247
]
Maxim Muzafarov commented on CASSANDRA-17797:
-
I am posting the same comments here because they are valuable to the issue
itself, and because the community has agreed that all such discussions need to
be within JIRA. The original comment is here:
[https://github.com/apache/cassandra/pull/2046#discussion_r1157582059]
Folks, I'd like to continue with this as I've found some inconsistencies in the
source code regarding the use of defaults. I'd like to discuss with you some
thoughts about the {{CassandraRelevantProperties}} default values. My concern
here is that the current API for getting the value of system properties doesn't
give us a reliable and explicit way to get the same results each time we access
a property, so removing "redundant" defaults may cause more problems than
adding them explicitly.
h3. Current state
Let's take a look at a few examples and inconsistencies:
# Inconsistency between {{getBoolean()}} and
{{{}getInt(){}}}/{{{}getLong(){}}} methods:
* in case {{getBoolean()}} without defaults value the {{false}} value
returned, no exception is thrown;
* in case {{getInt()}} or {{getLong()}} with default value the exception is
thrown ({{{}NullPointerException{}}} :-( see
[testInteger_null()|https://github.com/apache/cassandra/blob/trunk/test/unit/org/apache/cassandra/config/CassandraRelevantPropertiesTest.java#L133]
test);
# Inconsistency between {{getBoolean()}} and {{getString()}} for the same
property (assume a system property with type boolean is used):
* {{getBoolean()}} will return a non-null value if the default value is
{{{}null{}}};
* {{getString()}} for the same property will return a {{null}} value;
# If the default value is {{null}} the {{NullPointerException}} is thrown:
The {{getBoolean()}} method implicitly returns the {{false}} value and depends
on the boolean converter implementation itself (so a developer has to delve
into the code to find the _real_ return value). However, the {{public long
getLong()}} will throw {{NullPointerException}}
h3. Expected state
So, I think the API should be the following (default value {{null}} is allowed)
and we have to fix it:
# {{boolean disableSTCSInL0 = DISABLE_STCS_IN_L0.getBoolean(false);}} (runtime
option)
* If the property is set, the corresponding system property value is used;
* If the property is NOT set, the default value from brackets is used;
_OR_
# {{DISABLE_STCS_IN_L0("cassandra.disable_stcs_in_l0", "false")}} (compile
time option)
* If the property is set, the corresponding system property value is used;
* If the property is NOT set, the default value from the constant is used;
_OR_
# {{boolean disableSTCSInL0 = DISABLE_STCS_IN_L0.getBoolean()}} (property is
expected to be set)
* If the property is set, the corresponding system property value is used;
* If the property is NOT set, and there is NO default value we MUST throw an
exception.
WDYT?
> 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: 5.x
>
> Time Spent: 32h 40m
> 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 p
[jira] [Commented] (CASSANDRA-18105) TRUNCATED data come back after a restart or upgrade
[
https://issues.apache.org/jira/browse/CASSANDRA-18105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17714244#comment-17714244
]
Caleb Rackliffe commented on CASSANDRA-18105:
-
Good find. I think this confirms that SAI wouldn't have been affected.
Let me know if you need a reviewer.
> TRUNCATED data come back after a restart or upgrade
> ---
>
> Key: CASSANDRA-18105
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18105
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/2i Index
>Reporter: Ke Han
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 2.2.x, 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.x
>
>
> When we use the TRUNCATE command to delete all data in the table, the deleted
> data come back after a node restart or upgrade. This problem happens at the
> latest releases (2.2.19, 3.0.28, or 4.0.7)
> h1. Steps to reproduce
> h2. To reproduce it at release (3.0.28 or 4.0.7)
> Start up a single Cassandra node. Using the default configuration and execute
> the following cqlsh commands.
> {code:java}
> CREATE KEYSPACE IF NOT EXISTS ks WITH REPLICATION = { 'class' :
> 'SimpleStrategy', 'replication_factor' : 1 };
> CREATE TABLE ks.tb (c3 TEXT,c4 TEXT,c2 INT,c1 TEXT, PRIMARY KEY (c1, c2, c3
> ));
> INSERT INTO ks.tb (c3, c1, c2) VALUES ('val1','val2',1);
> CREATE INDEX IF NOT EXISTS tb ON ks.tb ( c3);
> TRUNCATE TABLE ks.tb;
> DROP INDEX IF EXISTS ks.tb; {code}
> Execute a read command
> {code:java}
> cqlsh> SELECT c2 FROM ks.tb;
> c2
>
> (0 rows) {code}
> Then, we flush the node and kill the Cassandra daemon by
> {code:java}
> bin/nodetool flush
> pgrep -f cassandra | xargs kill -9 {code}
> We restart the node. When the node has started, perform the same read, and
> the deleted data comes back again.
> {code:java}
> cqlsh> SELECT c2 FROM ks.tb;
> c2
>
> 1
> (1 rows) {code}
> h2. To reproduce it at release (2.2.19)
> We don't need to kill the Cassandra daemon. Use bin/nodetool stopdaemon is
> enough. The other steps are the same as reproducing it at 4.0.7 or 3.0.28.
> {code:java}
> bin/nodetool -h :::127.0.0.1 flush
> bin/nodetool -h :::127.0.0.1 stopdaemon{code}
>
> I have put the full log to reproduce it for release 4.0.7 and 2.2.19 in the
> comments.
--
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-18464) Enable Direct I/O For CommitLog Files
[ https://issues.apache.org/jira/browse/CASSANDRA-18464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh McKenzie reassigned CASSANDRA-18464: - Assignee: Amit Pawar > Enable Direct I/O For CommitLog Files > - > > Key: CASSANDRA-18464 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18464 > Project: Cassandra > Issue Type: New Feature > Components: Local/Commit Log >Reporter: Josh McKenzie >Assignee: Amit Pawar >Priority: Normal > Fix For: 6.x > > Attachments: UseDirectIOFeatureForCommitLogFiles.patch > > > Relocating from [dev@ email > thread.|https://lists.apache.org/thread/j6ny17q2rhkp7jxvwxm69dd6v1dozjrg] > > I shared my investigation about Commitlog I/O issue on large core count > system in my previous email dated July-22 and link to the thread is given > below. > [https://lists.apache.org/thread/xc5ocog2qz2v2gnj4xlw5hbthfqytx2n] > Basically, two solutions looked possible to improve the CommitLog I/O. > # Multi-threaded syncing > # Using Direct-IO through JNA > I worked on 2nd option considering the following benefit compared to the > first one > # Direct I/O read/write throughput is very high compared to non-Direct I/O. > Learnt through FIO benchmarking. > # Reduces kernel file cache uses which in-turn reduces kernel I/O activity > for Commitlog files only. > # Overall CPU usage reduced for flush activity. JVisualvm shows CPU usage < > 30% for Commitlog syncer thread with Direct I/O feature > # Direct I/O implementation is easier compared to multi-threaded > As per the community suggestion, less in code complex is good to have. Direct > I/O enablement looked promising but there was one issue. > Java version 8 does not have native support to enable Direct I/O. So, JNA > library usage is must. The same implementation should also work across other > versions of Java (like 11 and beyond). > I have completed Direct I/O implementation and summary of the attached patch > changes are given below. > # This implementation is not using Java file channels and file is opened > through JNA to use Direct I/O feature. > # New Segment are defined named “DirectIOSegment” for Direct I/O and > “NonDirectIOSegment” for non-direct I/O (NonDirectIOSegment is test purpose > only). > # JNA write call is used to flush the changes. > # New helper functions are defined in NativeLibrary.java and platform > specific file. Currently tested on Linux only. > # Patch allows user to configure optimum block size and alignment if > default values are not OK for CommitLog disk. > # Following configuration options are provided in Cassandra.yaml file > a. use_jna_for_commitlog_io : to use jna feature > b. use_direct_io_for_commitlog : to use Direct I/O feature. > c. direct_io_minimum_block_alignment: 512 (default) > d. nvme_disk_block_size: 32MiB (default and can be changed as per the > required size) > Test matrix is complex so CommitLog related testcases and TPCx-IOT benchmark > was tested. It works with both Java 8 and 11 versions. Compressed and > Encrypted based segments are not supported yet and it can be enabled later > based on the Community feedback. > Following improvement are seen with Direct I/O enablement. > # 32 cores >= ~15% > # 64 cores >= ~80% > Also, another observation would like to share here. Reading Commitlog files > with Direct I/O might help in reducing node bring-up time after the node > crash. > Tested with commit ID: 91f6a9aca8d3c22a03e68aa901a0b154d960ab07 > The attached patch enables Direct I/O feature for Commitlog files. Please > check and share your feedback. -- 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-18464) Enable Direct I/O For CommitLog Files
[ https://issues.apache.org/jira/browse/CASSANDRA-18464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17714205#comment-17714205 ] Caleb Rackliffe commented on CASSANDRA-18464: - bq. it's fine to use if needed Agreed...just saying it looks like it is not if J11 is our floor. > Enable Direct I/O For CommitLog Files > - > > Key: CASSANDRA-18464 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18464 > Project: Cassandra > Issue Type: New Feature > Components: Local/Commit Log >Reporter: Josh McKenzie >Priority: Normal > Fix For: 6.x > > Attachments: UseDirectIOFeatureForCommitLogFiles.patch > > > Relocating from [dev@ email > thread.|https://lists.apache.org/thread/j6ny17q2rhkp7jxvwxm69dd6v1dozjrg] > > I shared my investigation about Commitlog I/O issue on large core count > system in my previous email dated July-22 and link to the thread is given > below. > [https://lists.apache.org/thread/xc5ocog2qz2v2gnj4xlw5hbthfqytx2n] > Basically, two solutions looked possible to improve the CommitLog I/O. > # Multi-threaded syncing > # Using Direct-IO through JNA > I worked on 2nd option considering the following benefit compared to the > first one > # Direct I/O read/write throughput is very high compared to non-Direct I/O. > Learnt through FIO benchmarking. > # Reduces kernel file cache uses which in-turn reduces kernel I/O activity > for Commitlog files only. > # Overall CPU usage reduced for flush activity. JVisualvm shows CPU usage < > 30% for Commitlog syncer thread with Direct I/O feature > # Direct I/O implementation is easier compared to multi-threaded > As per the community suggestion, less in code complex is good to have. Direct > I/O enablement looked promising but there was one issue. > Java version 8 does not have native support to enable Direct I/O. So, JNA > library usage is must. The same implementation should also work across other > versions of Java (like 11 and beyond). > I have completed Direct I/O implementation and summary of the attached patch > changes are given below. > # This implementation is not using Java file channels and file is opened > through JNA to use Direct I/O feature. > # New Segment are defined named “DirectIOSegment” for Direct I/O and > “NonDirectIOSegment” for non-direct I/O (NonDirectIOSegment is test purpose > only). > # JNA write call is used to flush the changes. > # New helper functions are defined in NativeLibrary.java and platform > specific file. Currently tested on Linux only. > # Patch allows user to configure optimum block size and alignment if > default values are not OK for CommitLog disk. > # Following configuration options are provided in Cassandra.yaml file > a. use_jna_for_commitlog_io : to use jna feature > b. use_direct_io_for_commitlog : to use Direct I/O feature. > c. direct_io_minimum_block_alignment: 512 (default) > d. nvme_disk_block_size: 32MiB (default and can be changed as per the > required size) > Test matrix is complex so CommitLog related testcases and TPCx-IOT benchmark > was tested. It works with both Java 8 and 11 versions. Compressed and > Encrypted based segments are not supported yet and it can be enabled later > based on the Community feedback. > Following improvement are seen with Direct I/O enablement. > # 32 cores >= ~15% > # 64 cores >= ~80% > Also, another observation would like to share here. Reading Commitlog files > with Direct I/O might help in reducing node bring-up time after the node > crash. > Tested with commit ID: 91f6a9aca8d3c22a03e68aa901a0b154d960ab07 > The attached patch enables Direct I/O feature for Commitlog files. Please > check and share your feedback. -- 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-18441) Improvements to SSTable format configuration
[
https://issues.apache.org/jira/browse/CASSANDRA-18441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17714204#comment-17714204
]
Caleb Rackliffe commented on CASSANDRA-18441:
-
Looks like a reasonable plan to me.
As far as the YAML format goes, I guess the only thing my proposal might not
handle cleanly is third-party formats. I'm not really sure how important that
is though, to be honest. If someone invents a new format, they can either add
its name/config into the YAML in a fork or wherever they run it, or contribute
it to the project. Even if they don't do that, as long as their custom format
hooks up to the {{ServiceLoader}} framework, they should be able to define it
as the primary format strictly via the system property w/o any YAML changes in
the first place.
(In either case, anything defined in either system properties or YAML around
this is just an overlay after {{ServiceLoader}} finds all the available
formats. ex. You need to know the available formats before you validate the
choice of primary/default.)
> Improvements to SSTable format configuration
>
>
> Key: CASSANDRA-18441
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18441
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/SSTable
>Reporter: Branimir Lambov
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 5.x
>
>
> CEP-17 and CASSANDRA-17056 abstracted some interfaces for SSTable format
> implementations and defined a method of plugging in specific configurations.
> This method is brittle and asks users to specify format identifiers whose
> configuration does not provide value but can be the source of conflicts and
> problems. On the other hand it makes important choices non-obvious, as the
> selection of format to write is given by the order of configured interfaces.
> An improved specification mechanism needs to be put in place before Cassandra
> 5 is released.
--
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-18464) Enable Direct I/O For CommitLog Files
[ https://issues.apache.org/jira/browse/CASSANDRA-18464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17714197#comment-17714197 ] Brandon Williams commented on CASSANDRA-18464: -- I think this is all moot since we will remove j8, however JNA isn't going anywhere and we are the first project they list as a user, so I think it's fine to use if needed. > Enable Direct I/O For CommitLog Files > - > > Key: CASSANDRA-18464 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18464 > Project: Cassandra > Issue Type: New Feature > Components: Local/Commit Log >Reporter: Josh McKenzie >Priority: Normal > Fix For: 6.x > > Attachments: UseDirectIOFeatureForCommitLogFiles.patch > > > Relocating from [dev@ email > thread.|https://lists.apache.org/thread/j6ny17q2rhkp7jxvwxm69dd6v1dozjrg] > > I shared my investigation about Commitlog I/O issue on large core count > system in my previous email dated July-22 and link to the thread is given > below. > [https://lists.apache.org/thread/xc5ocog2qz2v2gnj4xlw5hbthfqytx2n] > Basically, two solutions looked possible to improve the CommitLog I/O. > # Multi-threaded syncing > # Using Direct-IO through JNA > I worked on 2nd option considering the following benefit compared to the > first one > # Direct I/O read/write throughput is very high compared to non-Direct I/O. > Learnt through FIO benchmarking. > # Reduces kernel file cache uses which in-turn reduces kernel I/O activity > for Commitlog files only. > # Overall CPU usage reduced for flush activity. JVisualvm shows CPU usage < > 30% for Commitlog syncer thread with Direct I/O feature > # Direct I/O implementation is easier compared to multi-threaded > As per the community suggestion, less in code complex is good to have. Direct > I/O enablement looked promising but there was one issue. > Java version 8 does not have native support to enable Direct I/O. So, JNA > library usage is must. The same implementation should also work across other > versions of Java (like 11 and beyond). > I have completed Direct I/O implementation and summary of the attached patch > changes are given below. > # This implementation is not using Java file channels and file is opened > through JNA to use Direct I/O feature. > # New Segment are defined named “DirectIOSegment” for Direct I/O and > “NonDirectIOSegment” for non-direct I/O (NonDirectIOSegment is test purpose > only). > # JNA write call is used to flush the changes. > # New helper functions are defined in NativeLibrary.java and platform > specific file. Currently tested on Linux only. > # Patch allows user to configure optimum block size and alignment if > default values are not OK for CommitLog disk. > # Following configuration options are provided in Cassandra.yaml file > a. use_jna_for_commitlog_io : to use jna feature > b. use_direct_io_for_commitlog : to use Direct I/O feature. > c. direct_io_minimum_block_alignment: 512 (default) > d. nvme_disk_block_size: 32MiB (default and can be changed as per the > required size) > Test matrix is complex so CommitLog related testcases and TPCx-IOT benchmark > was tested. It works with both Java 8 and 11 versions. Compressed and > Encrypted based segments are not supported yet and it can be enabled later > based on the Community feedback. > Following improvement are seen with Direct I/O enablement. > # 32 cores >= ~15% > # 64 cores >= ~80% > Also, another observation would like to share here. Reading Commitlog files > with Direct I/O might help in reducing node bring-up time after the node > crash. > Tested with commit ID: 91f6a9aca8d3c22a03e68aa901a0b154d960ab07 > The attached patch enables Direct I/O feature for Commitlog files. Please > check and share your feedback. -- 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-18464) Enable Direct I/O For CommitLog Files
[ https://issues.apache.org/jira/browse/CASSANDRA-18464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17714196#comment-17714196 ] Caleb Rackliffe commented on CASSANDRA-18464: - bq. Java version 8 does not have native support to enable Direct I/O. So, JNA library usage is must. The same implementation should also work across other versions of Java (like 11 and beyond). This ^ is the reason I ask. Feels like native support would be the way to go over JNA if possible. > Enable Direct I/O For CommitLog Files > - > > Key: CASSANDRA-18464 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18464 > Project: Cassandra > Issue Type: New Feature > Components: Local/Commit Log >Reporter: Josh McKenzie >Priority: Normal > Fix For: 6.x > > Attachments: UseDirectIOFeatureForCommitLogFiles.patch > > > Relocating from [dev@ email > thread.|https://lists.apache.org/thread/j6ny17q2rhkp7jxvwxm69dd6v1dozjrg] > > I shared my investigation about Commitlog I/O issue on large core count > system in my previous email dated July-22 and link to the thread is given > below. > [https://lists.apache.org/thread/xc5ocog2qz2v2gnj4xlw5hbthfqytx2n] > Basically, two solutions looked possible to improve the CommitLog I/O. > # Multi-threaded syncing > # Using Direct-IO through JNA > I worked on 2nd option considering the following benefit compared to the > first one > # Direct I/O read/write throughput is very high compared to non-Direct I/O. > Learnt through FIO benchmarking. > # Reduces kernel file cache uses which in-turn reduces kernel I/O activity > for Commitlog files only. > # Overall CPU usage reduced for flush activity. JVisualvm shows CPU usage < > 30% for Commitlog syncer thread with Direct I/O feature > # Direct I/O implementation is easier compared to multi-threaded > As per the community suggestion, less in code complex is good to have. Direct > I/O enablement looked promising but there was one issue. > Java version 8 does not have native support to enable Direct I/O. So, JNA > library usage is must. The same implementation should also work across other > versions of Java (like 11 and beyond). > I have completed Direct I/O implementation and summary of the attached patch > changes are given below. > # This implementation is not using Java file channels and file is opened > through JNA to use Direct I/O feature. > # New Segment are defined named “DirectIOSegment” for Direct I/O and > “NonDirectIOSegment” for non-direct I/O (NonDirectIOSegment is test purpose > only). > # JNA write call is used to flush the changes. > # New helper functions are defined in NativeLibrary.java and platform > specific file. Currently tested on Linux only. > # Patch allows user to configure optimum block size and alignment if > default values are not OK for CommitLog disk. > # Following configuration options are provided in Cassandra.yaml file > a. use_jna_for_commitlog_io : to use jna feature > b. use_direct_io_for_commitlog : to use Direct I/O feature. > c. direct_io_minimum_block_alignment: 512 (default) > d. nvme_disk_block_size: 32MiB (default and can be changed as per the > required size) > Test matrix is complex so CommitLog related testcases and TPCx-IOT benchmark > was tested. It works with both Java 8 and 11 versions. Compressed and > Encrypted based segments are not supported yet and it can be enabled later > based on the Community feedback. > Following improvement are seen with Direct I/O enablement. > # 32 cores >= ~15% > # 64 cores >= ~80% > Also, another observation would like to share here. Reading Commitlog files > with Direct I/O might help in reducing node bring-up time after the node > crash. > Tested with commit ID: 91f6a9aca8d3c22a03e68aa901a0b154d960ab07 > The attached patch enables Direct I/O feature for Commitlog files. Please > check and share your feedback. -- 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-18105) TRUNCATED data come back after a restart or upgrade
[
https://issues.apache.org/jira/browse/CASSANDRA-18105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17714175#comment-17714175
]
Stefan Miklosovic edited comment on CASSANDRA-18105 at 4/19/23 3:43 PM:
Together with great help of [~samt] we found the problem. Basically, upon
dropping of an index, it will eventually call (1) but the problem is that id of
index is same as id of the base table. So it will remove the record from the
truncate_at map in system.local for the base table. So TRUNCATE will put that
record there but next DROP of index will remove it from there.
If you notice, index has same id as base table because of this (2)
It was said to me that there is some reason behind the sharing of the id
between base table and the index but we should probably revisit this decision.
I am personally not sure why it is done like that.
The fix consists of simple check to not remove the trucated_at entry when table
metadata is of an index:
{code:java}
if (!metadata.get().isIndex())
SystemKeyspace.removeTruncationRecord(metadata.id);
{code}
It is also worth to mention that this is not happening without restarting the
node because upon restart, the commit log is replayed and it will look into
this table to see if a table was truncated so it will not replay the mutations.
However, since there is no such record in that truncated_at map for that table
anymore as DROP INDEX removed it, it will just replay it all so data will
resurrect.
(1)
[https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/ColumnFamilyStore.java#L695]
(2)
[https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/index/internal/CassandraIndex.java#L739]
was (Author: smiklosovic):
Together with great help of [~samt] we found the problem. Basically, upon
dropping of an index, it will eventually call (1) but the problem is that id of
index is same as id of the base table. So it will remove the record from the
truncate_at map in system.local for the base table. So TRUNCATE will put that
record there but next DROP of index will remove it from there.
If you notice, index has same id as base table because of this (2)
It was said to me that there is some reason behind the sharing of the id
between base table and the index but we should probably revisit this decision.
I am personally not sure why it is done like that.
The fix consists of simple check to not remove the trucated_at entry when table
metadata is of an index:
{code:java}
if (!metadata.get().isIndex())
SystemKeyspace.removeTruncationRecord(metadata.id);
{code}
It is also worth to mention that this is not happening without restarting the
node because upon restart, the commit log is replayed and it will look into
this table to see where if it was truncated so it will not replay the. However,
since there is no such record in that map for that table anymore as DROP INDEX
removed it, it will just replay it all so data will resurrect.
(1)
[https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/ColumnFamilyStore.java#L695]
(2)
[https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/index/internal/CassandraIndex.java#L739]
> TRUNCATED data come back after a restart or upgrade
> ---
>
> Key: CASSANDRA-18105
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18105
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/2i Index
>Reporter: Ke Han
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 2.2.x, 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.x
>
>
> When we use the TRUNCATE command to delete all data in the table, the deleted
> data come back after a node restart or upgrade. This problem happens at the
> latest releases (2.2.19, 3.0.28, or 4.0.7)
> h1. Steps to reproduce
> h2. To reproduce it at release (3.0.28 or 4.0.7)
> Start up a single Cassandra node. Using the default configuration and execute
> the following cqlsh commands.
> {code:java}
> CREATE KEYSPACE IF NOT EXISTS ks WITH REPLICATION = { 'class' :
> 'SimpleStrategy', 'replication_factor' : 1 };
> CREATE TABLE ks.tb (c3 TEXT,c4 TEXT,c2 INT,c1 TEXT, PRIMARY KEY (c1, c2, c3
> ));
> INSERT INTO ks.tb (c3, c1, c2) VALUES ('val1','val2',1);
> CREATE INDEX IF NOT EXISTS tb ON ks.tb ( c3);
> TRUNCATE TABLE ks.tb;
> DROP INDEX IF EXISTS ks.tb; {code}
> Execute a read command
> {code:java}
> cqlsh> SELECT c2 FROM ks.tb;
> c2
>
> (0 rows) {code}
> Then, we flush the node and kill the Cassandra daemon by
> {code:java}
> bin/nodetool flush
> pgrep -f cassandra | xargs kill -9 {code}
> We restart the node. When the node has started, perform the same read, and
> the deleted data c
[jira] [Updated] (CASSANDRA-18466) Paxos only repair is treated as an incremental repair
[
https://issues.apache.org/jira/browse/CASSANDRA-18466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-18466:
-
Bug Category: Parent values: Correctness(12982)
Complexity: Normal
Component/s: Consistency/Repair
Discovered By: User Report
Fix Version/s: 4.1.x
5.x
Severity: Normal
Status: Open (was: Triage Needed)
> Paxos only repair is treated as an incremental repair
> -
>
> Key: CASSANDRA-18466
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18466
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Repair
>Reporter: Andrew
>Priority: Normal
> Fix For: 4.1.x, 5.x
>
>
> Paxos only repair tries to continue or is treated as an incremental repair.
> This happened on 4.1.0 and 4.1.1 when trying to run repair in preparation for
> enabling paxos_state_purging. The repair was in preparation mode triggered
> multiple anti-compactions on the nodes. Running the command with --full
> behaves in the expected way, ie. only the paxos data is repaired and it's
> finished within a few seconds.
> {code:java}
> nodetool repair --paxos-only // This does not behave as expected, does it
> complete quickly and seems to be waiting on anticompactions
> {code}
> {code:java}
> nodetool repair --full --paxos-only // Completes within a few seconds as
> expected
> {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-18105) TRUNCATED data come back after a restart or upgrade
[
https://issues.apache.org/jira/browse/CASSANDRA-18105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17714175#comment-17714175
]
Stefan Miklosovic edited comment on CASSANDRA-18105 at 4/19/23 3:40 PM:
Together with great help of [~samt] we found the problem. Basically, upon
dropping of an index, it will eventually call (1) but the problem is that id of
index is same as id of the base table. So it will remove the record from the
truncate_at map in system.local for the base table. So TRUNCATE will put that
record there but next DROP of index will remove it from there.
If you notice, index has same id as base table because of this (2)
It was said to me that there is some reason behind the sharing of the id
between base table and the index but we should probably revisit this decision.
I am personally not sure why it is done like that.
The fix consists of simple check to not remove the trucated_at entry when table
metadata is of an index:
{code:java}
if (!metadata.get().isIndex())
SystemKeyspace.removeTruncationRecord(metadata.id);
{code}
It is also worth to mention that this is not happening without restarting the
node because upon restart, the commit log is replayed and it will look into
this table to see where if it was truncated so it will not replay the. However,
since there is no such record in that map for that table anymore as DROP INDEX
removed it, it will just replay it all so data will resurrect.
(1)
[https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/ColumnFamilyStore.java#L695]
(2)
[https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/index/internal/CassandraIndex.java#L739]
was (Author: smiklosovic):
Together with great help of [~samt] we found the problem. Basically, upon
dropping of an index, it will eventually call (1) but the problem is that id of
index is same as id of the base table. So it will remove the record from the
truncate_at map in system.local for the base table. So TRUNCATE will put that
record there but next DROP of index will remove it from there.
If you notice, index has same id as base table because of this (2)
It was said to me that there is some reason behind the sharing of the id
between base table and the index but we should probably revisit this decision.
I am personally not sure why it is done like that.
The fix consists of simple check to not remove the trucated_at entry when table
metadata is of an index:
{code:java}
if (!metadata.get().isIndex())
SystemKeyspace.removeTruncationRecord(metadata.id);
{code}
It is also worth to mention that this is not happening without restarting the
node because upon restart, the commit log is replayed and it will look into
this table to see where it was truncated so it will not replay the mutations
beyond that point. However, since there is no such record in that map for that
table anymore as DROP INDEX removed it, it will just replay it all so data will
resurrect.
(1)
[https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/ColumnFamilyStore.java#L695]
(2)
[https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/index/internal/CassandraIndex.java#L739]
> TRUNCATED data come back after a restart or upgrade
> ---
>
> Key: CASSANDRA-18105
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18105
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/2i Index
>Reporter: Ke Han
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 2.2.x, 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.x
>
>
> When we use the TRUNCATE command to delete all data in the table, the deleted
> data come back after a node restart or upgrade. This problem happens at the
> latest releases (2.2.19, 3.0.28, or 4.0.7)
> h1. Steps to reproduce
> h2. To reproduce it at release (3.0.28 or 4.0.7)
> Start up a single Cassandra node. Using the default configuration and execute
> the following cqlsh commands.
> {code:java}
> CREATE KEYSPACE IF NOT EXISTS ks WITH REPLICATION = { 'class' :
> 'SimpleStrategy', 'replication_factor' : 1 };
> CREATE TABLE ks.tb (c3 TEXT,c4 TEXT,c2 INT,c1 TEXT, PRIMARY KEY (c1, c2, c3
> ));
> INSERT INTO ks.tb (c3, c1, c2) VALUES ('val1','val2',1);
> CREATE INDEX IF NOT EXISTS tb ON ks.tb ( c3);
> TRUNCATE TABLE ks.tb;
> DROP INDEX IF EXISTS ks.tb; {code}
> Execute a read command
> {code:java}
> cqlsh> SELECT c2 FROM ks.tb;
> c2
>
> (0 rows) {code}
> Then, we flush the node and kill the Cassandra daemon by
> {code:java}
> bin/nodetool flush
> pgrep -f cassandra | xargs kill -9 {code}
> We restart the node. When the node has started, perform the same read, and
> the deleted dat
[jira] [Comment Edited] (CASSANDRA-18105) TRUNCATED data come back after a restart or upgrade
[
https://issues.apache.org/jira/browse/CASSANDRA-18105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17714175#comment-17714175
]
Stefan Miklosovic edited comment on CASSANDRA-18105 at 4/19/23 3:38 PM:
Together with great help of [~samt] we found the problem. Basically, upon
dropping of an index, it will eventually call (1) but the problem is that id of
index is same as id of the base table. So it will remove the record from the
truncate_at map in system.local for the base table. So TRUNCATE will put that
record there but next DROP of index will remove it from there.
If you notice, index has same id as base table because of this (2)
It was said to me that there is some reason behind the sharing of the id
between base table and the index but we should probably revisit this decision.
I am personally not sure why it is done like that.
The fix consists of simple check to not remove the trucated_at entry when table
metadata is of an index:
{code:java}
if (!metadata.get().isIndex())
SystemKeyspace.removeTruncationRecord(metadata.id);
{code}
It is also worth to mention that this is not happening without restarting the
node because upon restart, the commit log is replayed and it will look into
this table to see where it was truncated so it will not replay the mutations
beyond that point. However, since there is no such record in that map for that
table anymore as DROP INDEX removed it, it will just replay it all so data will
resurrect.
(1)
[https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/ColumnFamilyStore.java#L695]
(2)
[https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/index/internal/CassandraIndex.java#L739]
was (Author: smiklosovic):
Together with great help of [~samt] we found the problem. Basically, upon
dropping of an index, it will eventually call (1) but the problem is that id of
index is same as id of the base table. So it will remove the record from the
truncate_at map in system.local for the base table. So TRUNCATE will put that
record there but next DROP of index will remove it from there.
If you notice, index has same id as base table because of this (2)
It was said to me that there is some reason behind the sharing of the id
between base table and the index but we should probably revisit this decision.
I am personally not sure why it is done like that.
The fix consists of simple check to not remove the trucated_at entry when table
metadata is of an index:
{code:java}
if (!metadata.get().isIndex())
SystemKeyspace.removeTruncationRecord(metadata.id);
{code}
(1)
[https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/ColumnFamilyStore.java#L695]
(2)
[https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/index/internal/CassandraIndex.java#L739]
> TRUNCATED data come back after a restart or upgrade
> ---
>
> Key: CASSANDRA-18105
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18105
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/2i Index
>Reporter: Ke Han
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 2.2.x, 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.x
>
>
> When we use the TRUNCATE command to delete all data in the table, the deleted
> data come back after a node restart or upgrade. This problem happens at the
> latest releases (2.2.19, 3.0.28, or 4.0.7)
> h1. Steps to reproduce
> h2. To reproduce it at release (3.0.28 or 4.0.7)
> Start up a single Cassandra node. Using the default configuration and execute
> the following cqlsh commands.
> {code:java}
> CREATE KEYSPACE IF NOT EXISTS ks WITH REPLICATION = { 'class' :
> 'SimpleStrategy', 'replication_factor' : 1 };
> CREATE TABLE ks.tb (c3 TEXT,c4 TEXT,c2 INT,c1 TEXT, PRIMARY KEY (c1, c2, c3
> ));
> INSERT INTO ks.tb (c3, c1, c2) VALUES ('val1','val2',1);
> CREATE INDEX IF NOT EXISTS tb ON ks.tb ( c3);
> TRUNCATE TABLE ks.tb;
> DROP INDEX IF EXISTS ks.tb; {code}
> Execute a read command
> {code:java}
> cqlsh> SELECT c2 FROM ks.tb;
> c2
>
> (0 rows) {code}
> Then, we flush the node and kill the Cassandra daemon by
> {code:java}
> bin/nodetool flush
> pgrep -f cassandra | xargs kill -9 {code}
> We restart the node. When the node has started, perform the same read, and
> the deleted data comes back again.
> {code:java}
> cqlsh> SELECT c2 FROM ks.tb;
> c2
>
> 1
> (1 rows) {code}
> h2. To reproduce it at release (2.2.19)
> We don't need to kill the Cassandra daemon. Use bin/nodetool stopdaemon is
> enough. The other steps are the same as reproducing it at 4.0.7 or 3.0.28.
> {code:java}
> bin/nodetool -h :::127.0.0.1 flush
> bin/nodetool -h :::127.0.
[jira] [Comment Edited] (CASSANDRA-18105) TRUNCATED data come back after a restart or upgrade
[
https://issues.apache.org/jira/browse/CASSANDRA-18105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17714175#comment-17714175
]
Stefan Miklosovic edited comment on CASSANDRA-18105 at 4/19/23 3:32 PM:
Together with great help of [~samt] we found the problem. Basically, upon
dropping of an index, it will eventually call (1) but the problem is that id of
index is same as id of the base table. So it will remove the record from the
truncate_at map in system.local for the base table. So TRUNCATE will put that
record there but next DROP of index will remove it from there.
If you notice, index has same id as base table because of this (2)
It was said to me that there is some reason behind the sharing of the id
between base table and the index but we should probably revisit this decision.
I am personally not sure why it is done like that.
The fix consists of simple check to not remove the trucated_at entry when table
metadata is of an index:
{code:java}
if (!metadata.get().isIndex())
SystemKeyspace.removeTruncationRecord(metadata.id);
{code}
(1)
[https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/ColumnFamilyStore.java#L695]
(2)
[https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/index/internal/CassandraIndex.java#L739]
was (Author: smiklosovic):
Together with great help of [~samt] we found the problem. Basically, upon
dropping of an index, it will eventually call (1) but the problem is that id is
id of the base table, not of the index. So it will remove the record from the
truncate_at map in system.local for the base table. So TRUNCATE will put that
record there but next DROP of index will remove it from there.
If you notice, index has same id as base table because of this.
It was said to me that there is some reason behind the sharing of the id
between base table and the index but we should probably revisit this decision.
I am personally not sure why it is done like that.
The fix consists of simple check to not remove the trucated_at entry when table
metadata is of an index:
{code}
if (!metadata.get().isIndex())
SystemKeyspace.removeTruncationRecord(metadata.id);
{code}
(1)
[https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/ColumnFamilyStore.java#L695]
(2)
[https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/index/internal/CassandraIndex.java#L739]
> TRUNCATED data come back after a restart or upgrade
> ---
>
> Key: CASSANDRA-18105
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18105
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/2i Index
>Reporter: Ke Han
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 2.2.x, 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.x
>
>
> When we use the TRUNCATE command to delete all data in the table, the deleted
> data come back after a node restart or upgrade. This problem happens at the
> latest releases (2.2.19, 3.0.28, or 4.0.7)
> h1. Steps to reproduce
> h2. To reproduce it at release (3.0.28 or 4.0.7)
> Start up a single Cassandra node. Using the default configuration and execute
> the following cqlsh commands.
> {code:java}
> CREATE KEYSPACE IF NOT EXISTS ks WITH REPLICATION = { 'class' :
> 'SimpleStrategy', 'replication_factor' : 1 };
> CREATE TABLE ks.tb (c3 TEXT,c4 TEXT,c2 INT,c1 TEXT, PRIMARY KEY (c1, c2, c3
> ));
> INSERT INTO ks.tb (c3, c1, c2) VALUES ('val1','val2',1);
> CREATE INDEX IF NOT EXISTS tb ON ks.tb ( c3);
> TRUNCATE TABLE ks.tb;
> DROP INDEX IF EXISTS ks.tb; {code}
> Execute a read command
> {code:java}
> cqlsh> SELECT c2 FROM ks.tb;
> c2
>
> (0 rows) {code}
> Then, we flush the node and kill the Cassandra daemon by
> {code:java}
> bin/nodetool flush
> pgrep -f cassandra | xargs kill -9 {code}
> We restart the node. When the node has started, perform the same read, and
> the deleted data comes back again.
> {code:java}
> cqlsh> SELECT c2 FROM ks.tb;
> c2
>
> 1
> (1 rows) {code}
> h2. To reproduce it at release (2.2.19)
> We don't need to kill the Cassandra daemon. Use bin/nodetool stopdaemon is
> enough. The other steps are the same as reproducing it at 4.0.7 or 3.0.28.
> {code:java}
> bin/nodetool -h :::127.0.0.1 flush
> bin/nodetool -h :::127.0.0.1 stopdaemon{code}
>
> I have put the full log to reproduce it for release 4.0.7 and 2.2.19 in the
> comments.
--
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-18105) TRUNCATED data come back after a restart or upgrade
[
https://issues.apache.org/jira/browse/CASSANDRA-18105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17714175#comment-17714175
]
Stefan Miklosovic commented on CASSANDRA-18105:
---
Together with great help of [~samt] we found the problem. Basically, upon
dropping of an index, it will eventually call (1) but the problem is that id is
id of the base table, not of the index. So it will remove the record from the
truncate_at map in system.local for the base table. So TRUNCATE will put that
record there but next DROP of index will remove it from there.
If you notice, index has same id as base table because of this.
It was said to me that there is some reason behind the sharing of the id
between base table and the index but we should probably revisit this decision.
I am personally not sure why it is done like that.
The fix consists of simple check to not remove the trucated_at entry when table
metadata is of an index:
{code}
if (!metadata.get().isIndex())
SystemKeyspace.removeTruncationRecord(metadata.id);
{code}
(1)
[https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/ColumnFamilyStore.java#L695]
(2)
[https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/index/internal/CassandraIndex.java#L739]
> TRUNCATED data come back after a restart or upgrade
> ---
>
> Key: CASSANDRA-18105
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18105
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/2i Index
>Reporter: Ke Han
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 2.2.x, 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.x
>
>
> When we use the TRUNCATE command to delete all data in the table, the deleted
> data come back after a node restart or upgrade. This problem happens at the
> latest releases (2.2.19, 3.0.28, or 4.0.7)
> h1. Steps to reproduce
> h2. To reproduce it at release (3.0.28 or 4.0.7)
> Start up a single Cassandra node. Using the default configuration and execute
> the following cqlsh commands.
> {code:java}
> CREATE KEYSPACE IF NOT EXISTS ks WITH REPLICATION = { 'class' :
> 'SimpleStrategy', 'replication_factor' : 1 };
> CREATE TABLE ks.tb (c3 TEXT,c4 TEXT,c2 INT,c1 TEXT, PRIMARY KEY (c1, c2, c3
> ));
> INSERT INTO ks.tb (c3, c1, c2) VALUES ('val1','val2',1);
> CREATE INDEX IF NOT EXISTS tb ON ks.tb ( c3);
> TRUNCATE TABLE ks.tb;
> DROP INDEX IF EXISTS ks.tb; {code}
> Execute a read command
> {code:java}
> cqlsh> SELECT c2 FROM ks.tb;
> c2
>
> (0 rows) {code}
> Then, we flush the node and kill the Cassandra daemon by
> {code:java}
> bin/nodetool flush
> pgrep -f cassandra | xargs kill -9 {code}
> We restart the node. When the node has started, perform the same read, and
> the deleted data comes back again.
> {code:java}
> cqlsh> SELECT c2 FROM ks.tb;
> c2
>
> 1
> (1 rows) {code}
> h2. To reproduce it at release (2.2.19)
> We don't need to kill the Cassandra daemon. Use bin/nodetool stopdaemon is
> enough. The other steps are the same as reproducing it at 4.0.7 or 3.0.28.
> {code:java}
> bin/nodetool -h :::127.0.0.1 flush
> bin/nodetool -h :::127.0.0.1 stopdaemon{code}
>
> I have put the full log to reproduce it for release 4.0.7 and 2.2.19 in the
> comments.
--
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-18260) Add details to Error message: Not enough space for compaction
[
https://issues.apache.org/jira/browse/CASSANDRA-18260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17714151#comment-17714151
]
Henrik Ingo commented on CASSANDRA-18260:
-
Okay, here are the 4.1 and 4.0 "backports". I tries to make the log messages as
similar as possible, but since the code actually does something different
compared to trunk, the message text reflects that.
[https://github.com/apache/cassandra/pull/2285]
[https://github.com/apache/cassandra/pull/2284]
The above two are pretty identical, just a simple 1 line change was needed. The
difference from these two to the trunk PR is huge. I spent a couple hours
pondering whether some other approach would be more correct (for trunk) but in
the end they're just different. But here we have them now.
Maybe my main criticism against these is the growing number of lines asserting
log output. If anything changes in the surrounding code, you have like 20+
assertions to update as well.
> Add details to Error message: Not enough space for compaction
> --
>
> Key: CASSANDRA-18260
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18260
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Compaction, Observability/Logging
>Reporter: Brad Schoening
>Assignee: Henrik Ingo
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.x
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> When compaction fails, the log message should list a) the free space
> available on disk at that point in time and b) perhaps the number and/or size
> of the source sstables being compacted.
> Free space can change from one moment to the next, so when the below
> compaction failed because it needed 161GB, upon checking the server a few
> minutes later, it had 184GB free. Similarly, the error message mentions it
> was writing out one SSTable on this STCS table, but its not clear if it was
> combining X -> 1 tables, or something else.
> {noformat}
> [INFO ] [CompactionExecutor:77758] cluster_id=87 ip_address=127.1.1.1
> CompactionTask.java:241 - Compacted (8a1cffe0-abb5-11ed-b3fc-8d2ac2c52f0d) 1
> sstables to [...] to level=0. 86.997GiB to 86.997GiB (~99% of original) in
> 1,508,155ms. Read Throughput = 59.069MiB/s, Write Throughput = 59.069MiB/s,
> Row Throughput = ~20,283/s. 21,375 total partitions merged to 21,375.
> Partition merge counts were \{1:21375, }
> [ERROR] [CompactionExecutor:4] cluster_id=87 ip_address=127.1.1.1
> CassandraDaemon.java:581 - Exception in thread
> Thread[CompactionExecutor:4,1,main]
> java.lang.RuntimeException: Not enough space for compaction, estimated
> sstables = 1, expected write size = 161228934093
> at
> org.apache.cassandra.db.compaction.CompactionTask.buildCompactionCandidatesForAvailableDiskSpace(CompactionTask.java:386)
> at
> org.apache.cassandra.db.compaction.CompactionTask.runMayThrow(CompactionTask.java:126)
> at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> at
> org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:77)
> at
> org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:100)
> at
> org.apache.cassandra.db.compaction.CompactionManager$7.execute(CompactionManager.java:613)
> at
> org.apache.cassandra.db.compaction.CompactionManager$2.call(CompactionManager.java:377)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:834)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18466) Paxos only repair is treated as an incremental repair
[
https://issues.apache.org/jira/browse/CASSANDRA-18466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew updated CASSANDRA-18466:
---
Description:
Paxos only repair tries to continue or is treated as an incremental repair.
This happened on 4.1.0 and 4.1.1 when trying to run repair in preparation for
enabling paxos_state_purging. The repair was in preparation mode triggered
multiple anti-compactions on the nodes. Running the command with --full behaves
in the expected way, ie. only the paxos data is repaired and it's finished
within a few seconds.
{code:java}
nodetool repair --paxos-only // This does not behave as expected, does it
complete quickly and seems to be waiting on anticompactions
{code}
{code:java}
nodetool repair --full --paxos-only // Completes within a few seconds as
expected
{code}
was:
Paxos only repair tries to continue or is treated as an incremental repair.
This happened on 4.1.0 and 4.1.1 when trying to run repair in preparation for
enabling paxos_state_purging. The repair was in preparation mode triggered
multiple anti-compactions on the nodes. Running the command with --full behaves
in the expected way, ie. only the paxos data is repaired and it's finished
within a few seconds.
```
Text
```
> Paxos only repair is treated as an incremental repair
> -
>
> Key: CASSANDRA-18466
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18466
> Project: Cassandra
> Issue Type: Bug
>Reporter: Andrew
>Priority: Normal
>
> Paxos only repair tries to continue or is treated as an incremental repair.
> This happened on 4.1.0 and 4.1.1 when trying to run repair in preparation for
> enabling paxos_state_purging. The repair was in preparation mode triggered
> multiple anti-compactions on the nodes. Running the command with --full
> behaves in the expected way, ie. only the paxos data is repaired and it's
> finished within a few seconds.
> {code:java}
> nodetool repair --paxos-only // This does not behave as expected, does it
> complete quickly and seems to be waiting on anticompactions
> {code}
> {code:java}
> nodetool repair --full --paxos-only // Completes within a few seconds as
> expected
> {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-18466) Paxos only repair is treated as an incremental repair
Andrew created CASSANDRA-18466: -- Summary: Paxos only repair is treated as an incremental repair Key: CASSANDRA-18466 URL: https://issues.apache.org/jira/browse/CASSANDRA-18466 Project: Cassandra Issue Type: Bug Reporter: Andrew Paxos only repair tries to continue or is treated as an incremental repair. This happened on 4.1.0 and 4.1.1 when trying to run repair in preparation for enabling paxos_state_purging. The repair was in preparation mode triggered multiple anti-compactions on the nodes. Running the command with --full behaves in the expected way, ie. only the paxos data is repaired and it's finished within a few seconds. -- 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-18466) Paxos only repair is treated as an incremental repair
[ https://issues.apache.org/jira/browse/CASSANDRA-18466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew updated CASSANDRA-18466: --- Description: Paxos only repair tries to continue or is treated as an incremental repair. This happened on 4.1.0 and 4.1.1 when trying to run repair in preparation for enabling paxos_state_purging. The repair was in preparation mode triggered multiple anti-compactions on the nodes. Running the command with --full behaves in the expected way, ie. only the paxos data is repaired and it's finished within a few seconds. ``` Text ``` was:Paxos only repair tries to continue or is treated as an incremental repair. This happened on 4.1.0 and 4.1.1 when trying to run repair in preparation for enabling paxos_state_purging. The repair was in preparation mode triggered multiple anti-compactions on the nodes. Running the command with --full behaves in the expected way, ie. only the paxos data is repaired and it's finished within a few seconds. > Paxos only repair is treated as an incremental repair > - > > Key: CASSANDRA-18466 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18466 > Project: Cassandra > Issue Type: Bug >Reporter: Andrew >Priority: Normal > > Paxos only repair tries to continue or is treated as an incremental repair. > This happened on 4.1.0 and 4.1.1 when trying to run repair in preparation for > enabling paxos_state_purging. The repair was in preparation mode triggered > multiple anti-compactions on the nodes. Running the command with --full > behaves in the expected way, ie. only the paxos data is repaired and it's > finished within a few seconds. > ``` > Text > ``` -- 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-17919) Capital P gets confused in the parser for a Duration in places where IDENT are needed
[
https://issues.apache.org/jira/browse/CASSANDRA-17919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17714119#comment-17714119
]
Stefan Miklosovic edited comment on CASSANDRA-17919 at 4/19/23 2:11 PM:
Thanks.
It looks just fine. I noticed there there is also this in the wiki
_The smallest value used may also have a decimal fraction,[38] as in "P0.5Y" to
indicate half a year. This decimal fraction may be specified with either a
comma or a full stop, as in "P0,5Y" or "P0.5Y"._
We do not implement this. This ticket is not to blame, I am just writing what I
see. I looked into the code and it would be quite challenging to support this
format. The values are based on an integer only.
I am +1, I need to find another committer and we may build it all afterwards as
it spans 4 branches.
The sneak peek of the builds is here, for trunk j8 pre-commit, I will build the
rest afterwards to save the resources and time:
https://app.circleci.com/pipelines/github/instaclustr/cassandra/2105/workflows/c50c15aa-8e27-4fd6-b4cc-5a216ed115d6
[~dcapwell] [~e.dimitrova] [~blerer] [~brandon.williams]
was (Author: smiklosovic):
Thanks.
It looks just fine. I noticed there there is also this in the wiki
_The smallest value used may also have a decimal fraction,[38] as in "P0.5Y" to
indicate half a year. This decimal fraction may be specified with either a
comma or a full stop, as in "P0,5Y" or "P0.5Y"._
We do not implement this. This ticket is not to blame, I am just writing what I
see. I looked into the code and it would be quite challenging to support this
format. The values are based on an integer only.
I am +1, I need to find another committer and we may build it all afterwards as
it spans 4 branches.
The sneak peek of the builds is here, for trunk j8 pre-commit, I will build the
rest afterwards to save the resources and time:
https://app.circleci.com/pipelines/github/instaclustr/cassandra/2105/workflows/c50c15aa-8e27-4fd6-b4cc-5a216ed115d6
> Capital P gets confused in the parser for a Duration in places where IDENT
> are needed
> -
>
> Key: CASSANDRA-17919
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17919
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Syntax
>Reporter: David Capwell
>Assignee: Maxim Chanturiay
>Priority: Normal
> Fix For: 3.11.x, 4.0.x, 4.1.x, 5.x
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> This was found while adding Accord Transaction syntax into CQL and fuzz
> testing to validate all possible cases… in doing this the following was found
> {code}
> String query = "BEGIN TRANSACTION\n" +
>" LET P = (SELECT v FROM " + keyspace + ".tbl
> WHERE k=? AND c=?);\n" +
>" LET row2 = (SELECT v FROM " + keyspace + ".tbl
> WHERE k=? AND c=?);\n" +
>" SELECT v FROM " + keyspace + ".tbl WHERE k=?
> AND c=?;\n" +
>" IF P IS NULL AND row2.v = ? THEN\n" +
>"INSERT INTO " + keyspace + ".tbl (k, c, v)
> VALUES (?, ?, ?);\n" +
>" END IF\n" +
>"COMMIT TRANSACTION";
> {code}
> Fails with
> {code}
> SyntaxException: line 2:6 mismatched input 'P' expecting IDENT (BEGIN
> TRANSACTION LET [P]...)
> {code}
> The new LET syntax found this, but was able to reproduce in other cases
> {code}
> cqlsh:ks> CREATE TABLE P (k INT PRIMARY KEY);
> SyntaxException: line 1:13 no viable alternative at input 'P' (CREATE TABLE
> [P]...)
> cqlsh:ks>
> cqlsh:ks> CREATE TABLE p (k INT PRIMARY KEY);
> cqlsh:ks>
> {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-17919) Capital P gets confused in the parser for a Duration in places where IDENT are needed
[
https://issues.apache.org/jira/browse/CASSANDRA-17919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17714119#comment-17714119
]
Stefan Miklosovic commented on CASSANDRA-17919:
---
Thanks.
It looks just fine. I noticed there there is also this in the wiki
_The smallest value used may also have a decimal fraction,[38] as in "P0.5Y" to
indicate half a year. This decimal fraction may be specified with either a
comma or a full stop, as in "P0,5Y" or "P0.5Y"._
We do not implement this. This ticket is not to blame, I am just writing what I
see. I looked into the code and it would be quite challenging to support this
format. The values are based on an integer only.
I am +1, I need to find another committer and we may build it all afterwards as
it spans 4 branches.
The sneak peek of the builds is here, for trunk j8 pre-commit, I will build the
rest afterwards to save the resources and time:
https://app.circleci.com/pipelines/github/instaclustr/cassandra/2105/workflows/c50c15aa-8e27-4fd6-b4cc-5a216ed115d6
> Capital P gets confused in the parser for a Duration in places where IDENT
> are needed
> -
>
> Key: CASSANDRA-17919
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17919
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Syntax
>Reporter: David Capwell
>Assignee: Maxim Chanturiay
>Priority: Normal
> Fix For: 3.11.x, 4.0.x, 4.1.x, 5.x
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> This was found while adding Accord Transaction syntax into CQL and fuzz
> testing to validate all possible cases… in doing this the following was found
> {code}
> String query = "BEGIN TRANSACTION\n" +
>" LET P = (SELECT v FROM " + keyspace + ".tbl
> WHERE k=? AND c=?);\n" +
>" LET row2 = (SELECT v FROM " + keyspace + ".tbl
> WHERE k=? AND c=?);\n" +
>" SELECT v FROM " + keyspace + ".tbl WHERE k=?
> AND c=?;\n" +
>" IF P IS NULL AND row2.v = ? THEN\n" +
>"INSERT INTO " + keyspace + ".tbl (k, c, v)
> VALUES (?, ?, ?);\n" +
>" END IF\n" +
>"COMMIT TRANSACTION";
> {code}
> Fails with
> {code}
> SyntaxException: line 2:6 mismatched input 'P' expecting IDENT (BEGIN
> TRANSACTION LET [P]...)
> {code}
> The new LET syntax found this, but was able to reproduce in other cases
> {code}
> cqlsh:ks> CREATE TABLE P (k INT PRIMARY KEY);
> SyntaxException: line 1:13 no viable alternative at input 'P' (CREATE TABLE
> [P]...)
> cqlsh:ks>
> cqlsh:ks> CREATE TABLE p (k INT PRIMARY KEY);
> cqlsh:ks>
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17919) Capital P gets confused in the parser for a Duration in places where IDENT are needed
[
https://issues.apache.org/jira/browse/CASSANDRA-17919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-17919:
--
Status: Needs Committer (was: Review In Progress)
> Capital P gets confused in the parser for a Duration in places where IDENT
> are needed
> -
>
> Key: CASSANDRA-17919
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17919
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Syntax
>Reporter: David Capwell
>Assignee: Maxim Chanturiay
>Priority: Normal
> Fix For: 3.11.x, 4.0.x, 4.1.x, 5.x
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> This was found while adding Accord Transaction syntax into CQL and fuzz
> testing to validate all possible cases… in doing this the following was found
> {code}
> String query = "BEGIN TRANSACTION\n" +
>" LET P = (SELECT v FROM " + keyspace + ".tbl
> WHERE k=? AND c=?);\n" +
>" LET row2 = (SELECT v FROM " + keyspace + ".tbl
> WHERE k=? AND c=?);\n" +
>" SELECT v FROM " + keyspace + ".tbl WHERE k=?
> AND c=?;\n" +
>" IF P IS NULL AND row2.v = ? THEN\n" +
>"INSERT INTO " + keyspace + ".tbl (k, c, v)
> VALUES (?, ?, ?);\n" +
>" END IF\n" +
>"COMMIT TRANSACTION";
> {code}
> Fails with
> {code}
> SyntaxException: line 2:6 mismatched input 'P' expecting IDENT (BEGIN
> TRANSACTION LET [P]...)
> {code}
> The new LET syntax found this, but was able to reproduce in other cases
> {code}
> cqlsh:ks> CREATE TABLE P (k INT PRIMARY KEY);
> SyntaxException: line 1:13 no viable alternative at input 'P' (CREATE TABLE
> [P]...)
> cqlsh:ks>
> cqlsh:ks> CREATE TABLE p (k INT PRIMARY KEY);
> cqlsh:ks>
> {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-18441) Improvements to SSTable format configuration
[ https://issues.apache.org/jira/browse/CASSANDRA-18441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17714107#comment-17714107 ] Jacek Lewandowski commented on CASSANDRA-18441: --- Ah, you refer to the yaml - right, I meant that I'll use "nesting" > Improvements to SSTable format configuration > > > Key: CASSANDRA-18441 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18441 > Project: Cassandra > Issue Type: Improvement > Components: Local/SSTable >Reporter: Branimir Lambov >Assignee: Jacek Lewandowski >Priority: Normal > Fix For: 5.x > > > CEP-17 and CASSANDRA-17056 abstracted some interfaces for SSTable format > implementations and defined a method of plugging in specific configurations. > This method is brittle and asks users to specify format identifiers whose > configuration does not provide value but can be the source of conflicts and > problems. On the other hand it makes important choices non-obvious, as the > selection of format to write is given by the order of configured interfaces. > An improved specification mechanism needs to be put in place before Cassandra > 5 is released. -- 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-18441) Improvements to SSTable format configuration
[
https://issues.apache.org/jira/browse/CASSANDRA-18441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17714106#comment-17714106
]
Jacek Lewandowski commented on CASSANDRA-18441:
---
{quote}To keep changes limited, I would prefer to not implement any per-table
configuration at this point, and thus only expose and configure the single
write format to use.{quote}
Indeed, I don't want to provide per sstable configuration in this ticket.
> Improvements to SSTable format configuration
>
>
> Key: CASSANDRA-18441
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18441
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/SSTable
>Reporter: Branimir Lambov
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 5.x
>
>
> CEP-17 and CASSANDRA-17056 abstracted some interfaces for SSTable format
> implementations and defined a method of plugging in specific configurations.
> This method is brittle and asks users to specify format identifiers whose
> configuration does not provide value but can be the source of conflicts and
> problems. On the other hand it makes important choices non-obvious, as the
> selection of format to write is given by the order of configured interfaces.
> An improved specification mechanism needs to be put in place before Cassandra
> 5 is released.
--
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-18441) Improvements to SSTable format configuration
[
https://issues.apache.org/jira/browse/CASSANDRA-18441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17714102#comment-17714102
]
Branimir Lambov commented on CASSANDRA-18441:
-
I don't understand why we would want to define more than one write
configuration if we only identify the configuration by format name.
Either we specify the write format per table, or we use the same write
configuration for everything. If we do the former, to me the most important
thing is to allow multiple configurations for the same format. For example, one
with {{row_index_granularity: 0.5kib}} and one with the default
{{row_index_granularity: 16kib}}. Eventually existing schema properties like
bloom filter chance or compression would move into the format configuration.
To keep changes limited, I would prefer to not implement any per-table
configuration at this point, and thus only expose and configure the single
write format to use.
> Improvements to SSTable format configuration
>
>
> Key: CASSANDRA-18441
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18441
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/SSTable
>Reporter: Branimir Lambov
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 5.x
>
>
> CEP-17 and CASSANDRA-17056 abstracted some interfaces for SSTable format
> implementations and defined a method of plugging in specific configurations.
> This method is brittle and asks users to specify format identifiers whose
> configuration does not provide value but can be the source of conflicts and
> problems. On the other hand it makes important choices non-obvious, as the
> selection of format to write is given by the order of configured interfaces.
> An improved specification mechanism needs to be put in place before Cassandra
> 5 is released.
--
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-18018) List command output not correct for super user, after grant command
[
https://issues.apache.org/jira/browse/CASSANDRA-18018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sam Tunnicliffe updated CASSANDRA-18018:
Bug Category: Parent values: Correctness(12982)Level 1 values: API /
Semantic Definition(13162)
Complexity: Normal
Discovered By: User Report
Reviewers: Sam Tunnicliffe, Shailaja Koppu
Severity: Low
Status: Open (was: Triage Needed)
Thanks for the work so far [~maximc] In itself it's fine but this is missing at
least a couple of things and/or making the view inconsistent across different
queries.
It doesn't quite cover list queries where the resource is also specified. For
instance:
{code:java}
LIST ALL PERMISSIONS ON ks1.t1;
LIST ALL PERMISSIONS ON ks1.t1 OF user1;
LIST SELECT PERMISSION ON ks1.t1 OF user1
LIST SELECT, MODIFY PERMISSION ON ks1.t1 OF user1;
{code}
should add addition filters to the set of permissions returned, whether or not
the role has superuser status.
The current version also adds an inconsistency between
{code:java}
LIST ALL PERMISSIONS OF user1;{code}
which now does the inference of additional implied permissions if {{user1}} is
a superuser, and
{code:java}
LIST ALL PERMISSIONS;{code}
which does not (i.e. here, only the explicitly granted permissions are shown
for {{{}user1{}}};
There may be other issues or inconsistencies, but I didn't go any further yet.
Again, I'm wondering whether it's actually worth trying to satisfy all of these
edge cases for the sake of the {{LIST PERMISSIONS}} statement. I'll reiterate
that superuser status doesn't actually grant permissions, rather it causes all
permissions checks to be bypassed for the role in question, so I question
whether the increased complexity is necessary.
> List command output not correct for super user, after grant command
> ---
>
> Key: CASSANDRA-18018
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18018
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Authorization
>Reporter: Shailaja Koppu
>Assignee: Maxim Chanturiay
>Priority: Normal
> Labels: lhf
> Fix For: 4.1.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Running local Cassandra with below config:
> {noformat}
> authenticator: PasswordAuthenticator
> authorizer: CassandraAuthorizer
> role_manager: CassandraRoleManager
> network_authorizer: CassandraNetworkAuthorizer{noformat}
> Created a super user and then ran *Grant select* command on a keyspace.
> {noformat}
> shaadmin1@cqlsh> CREATE USER 'shaadmin1c1' WITH PASSWORD 'shaadmin1c1'
> SUPERUSER;
> shaadmin1@cqlsh:system_auth> grant select on testk1.t1 to shaadmin1c1;
> shaadmin1@cqlsh:system_auth> alter role shaadmin1c1 with access to all
> datacenters;
> {noformat}
>
> After this, list permissions command showing only select permission for that
> role on the resource.
> {noformat}
> shaadmin1c1@cqlsh> list all permissions of shaadmin1c1;
> role | username | resource | permission
> +---
> shaadmin1c1 | shaadmin1c1 | | SELECT
> {noformat}
>
> Row in role_permissions table:
> {noformat}
> role | resource | permissions
> --
> shaadmin1c1 | data/testk1/t1 | {'SELECT'}{noformat}
> But insert command by that role on the resource is successful because role is
> a super user
> {noformat}
> shaadmin1c1@cqlsh> insert into testk1.t1 (c1, c2) values ('a', 1);
> shaadmin1c1@cqlsh> select * from testk1.t1 ;
> c1 | c2
> ---+---
> a | 1
> (1 rows)
> {noformat}
>
> The problem is, output of list permissions command, which indicates only
> select permission on the resource, is misleading. I think list command need
> to be fixed to show all permissions super user has on the resource. Also
> grant command for a super user can be either a no-op or throw error, because
> the role already have requested permissions.
>
> Documentation also misleading:
> {quote}True automatically grants AUTHORIZE, CREATE and DROP permission on ALL
> ROLES.
> Superusers can only manage roles by default. To manage other resources,
> {color:#ff}you must grant the permission set to that resource. **
> {color}For example, to allow access management for all keyspaces: {{{}GRANT
> ALL PERMISSIONS ON ALL KEYSPACES TO }}\{{{}{*}role_name{*}{}}}.
> {quote}
>
>
>
--
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-18336) Sstables were cleared when OOM and best_effort is used
[
https://issues.apache.org/jira/browse/CASSANDRA-18336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-18336:
--
Status: Needs Committer (was: Patch Available)
> Sstables were cleared when OOM and best_effort is used
> --
>
> Key: CASSANDRA-18336
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18336
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Compaction
>Reporter: NAIZHEN QUE
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.x
>
> Attachments: 4031679897782_.pic.jpg, 4241679905694_.pic.jpg,
> system.log.2023-02-21.0
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> 1.When this exception occurs in the system
> {code:java}
> //
> ERROR [CompactionExecutor:351627] 2023-02-21 17:59:20,721
> CassandraDaemon.java:581 - Exception in thread
> Thread[CompactionExecutor:351627,1,main]
> org.apache.cassandra.io.FSReadError: java.io.IOException: Map failed
> at org.apache.cassandra.io.util.ChannelProxy.map(ChannelProxy.java:167)
> at
> org.apache.cassandra.io.util.MmappedRegions$State.add(MmappedRegions.java:310)
> at
> org.apache.cassandra.io.util.MmappedRegions$State.access$400(MmappedRegions.java:246)
> at
> org.apache.cassandra.io.util.MmappedRegions.updateState(MmappedRegions.java:170)
> at
> org.apache.cassandra.io.util.MmappedRegions.(MmappedRegions.java:73)
> at
> org.apache.cassandra.io.util.MmappedRegions.(MmappedRegions.java:61)
> at
> org.apache.cassandra.io.util.MmappedRegions.map(MmappedRegions.java:104)
> at
> org.apache.cassandra.io.util.FileHandle$Builder.complete(FileHandle.java:365)
> at
> org.apache.cassandra.io.sstable.format.big.BigTableWriter.openEarly(BigTableWriter.java:337)
> at
> org.apache.cassandra.io.sstable.SSTableRewriter.maybeReopenEarly(SSTableRewriter.java:172)
> at
> org.apache.cassandra.io.sstable.SSTableRewriter.append(SSTableRewriter.java:124)
> at
> org.apache.cassandra.db.compaction.writers.DefaultCompactionWriter.realAppend(DefaultCompactionWriter.java:64)
> at
> org.apache.cassandra.db.compaction.writers.CompactionAwareWriter.append(CompactionAwareWriter.java:137)
> at
> org.apache.cassandra.db.compaction.CompactionTask.runMayThrow(CompactionTask.java:193)
> at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> at
> org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:77)
> at
> org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:100)
> at
> org.apache.cassandra.db.compaction.CompactionManager$BackgroundCompactionCandidate.run(CompactionManager.java:298)
> at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: java.io.IOException: Map failed
> at java.base/sun.nio.ch.FileChannelImpl.map(FileChannelImpl.java:1016)
> at org.apache.cassandra.io.util.ChannelProxy.map(ChannelProxy.java:163)
> ... 23 common frames omitted
> Caused by: java.lang.OutOfMemoryError: Map failed
> at java.base/sun.nio.ch.FileChannelImpl.map0(Native Method)
> at java.base/sun.nio.ch.FileChannelImpl.map(FileChannelImpl.java:1013)
> {code}
> 2.Restart the node, Verifying logfile transaction ,All sstables are deleted
> {code:java}
> // code placeholder
> INFO [main] 2023-02-21 18:00:23,350 LogTransaction.java:240 - Unfinished
> transaction log, deleting
> /historyData/cassandra/data/kairosdb/data_points-870fab7087ba11eb8b50d3c6960df21b/nb-8819408-big-Index.db
>
> INFO [main] 2023-02-21 18:00:23,615 LogTransaction.java:240 - Unfinished
> transaction log, deleting
> /historyData/cassandra/data/kairosdb/data_points-870fab7087ba11eb8b50d3c6960df21b/nb-8819408-big-Data.db
>
> INFO [main] 2023-02-21 18:00:46,504 LogTransaction.java:240 - Unfinished
> transaction log, deleting
> /historyData/cassandra/data/kairosdb/data_points-870fab7087ba11eb8b50d3c6960df21b/nb_txn_compaction_c923b230-b077-11ed-a081-5d5a5c990823.log
>
> INFO [main] 2023-02-21 18:00:46,510 LogTransaction.java:536 - Verifying
> logfile transaction
> [nb_txn_compaction_461935b0-b1ce-11ed-a081-5d5a5c990823.log in
> /historyData/cassandra/data/kairosdb/data_points-870fab7087ba11eb8b50d3c6960df21b]
> INFO
[jira] [Comment Edited] (CASSANDRA-18441) Improvements to SSTable format configuration
[ https://issues.apache.org/jira/browse/CASSANDRA-18441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17714054#comment-17714054 ] Jacek Lewandowski edited comment on CASSANDRA-18441 at 4/19/23 11:22 AM: - So summarizing things to be done there: 1. sstable format should have hardcoded its string identifier 2. numeric identifier should be removed and we should include a mapping in key cache 3. sstable formats should be discovered via service loader 4. format configuration should look differently - let's use the last proposal from [~maedhroz] with nesting 5. let configure sstable properties via yaml/system properties was (Author: jlewandowski): So summarizing things to be done there: 1. sstable format should have hardcoded its string identifier 2. numeric identifier should be removed and we should include a mapping in row cache 3. sstable formats should be discovered via service loader 4. format configuration should look differently - let's use the last proposal from [~maedhroz] with nesting 5. let configure sstable properties via yaml/system properties > Improvements to SSTable format configuration > > > Key: CASSANDRA-18441 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18441 > Project: Cassandra > Issue Type: Improvement > Components: Local/SSTable >Reporter: Branimir Lambov >Assignee: Jacek Lewandowski >Priority: Normal > Fix For: 5.x > > > CEP-17 and CASSANDRA-17056 abstracted some interfaces for SSTable format > implementations and defined a method of plugging in specific configurations. > This method is brittle and asks users to specify format identifiers whose > configuration does not provide value but can be the source of conflicts and > problems. On the other hand it makes important choices non-obvious, as the > selection of format to write is given by the order of configured interfaces. > An improved specification mechanism needs to be put in place before Cassandra > 5 is released. -- 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-18441) Improvements to SSTable format configuration
[ https://issues.apache.org/jira/browse/CASSANDRA-18441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17714054#comment-17714054 ] Jacek Lewandowski commented on CASSANDRA-18441: --- So summarizing things to be done there: 1. sstable format should have hardcoded its string identifier 2. numeric identifier should be removed and we should include a mapping in row cache 3. sstable formats should be discovered via service loader 4. format configuration should look differently - let's use the last proposal from [~maedhroz] with nesting 5. let configure sstable properties via yaml/system properties > Improvements to SSTable format configuration > > > Key: CASSANDRA-18441 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18441 > Project: Cassandra > Issue Type: Improvement > Components: Local/SSTable >Reporter: Branimir Lambov >Assignee: Jacek Lewandowski >Priority: Normal > Fix For: 5.x > > > CEP-17 and CASSANDRA-17056 abstracted some interfaces for SSTable format > implementations and defined a method of plugging in specific configurations. > This method is brittle and asks users to specify format identifiers whose > configuration does not provide value but can be the source of conflicts and > problems. On the other hand it makes important choices non-obvious, as the > selection of format to write is given by the order of configured interfaces. > An improved specification mechanism needs to be put in place before Cassandra > 5 is released. -- 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-18465) Add support for multiple condition branches and results in Accord transaction
[
https://issues.apache.org/jira/browse/CASSANDRA-18465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacek Lewandowski updated CASSANDRA-18465:
--
Description:
I'd like to propose adding support for multiple branches and result sets for
Accord transactions. It could look like this:
{code:sql}
BEGIN TRANSACTION
LET a = ...
LET b = ...
IF condition THEN
SELECT 'one', a.value
UPDATE ...
ELSE IF condition2 THEN
SELECT 'two', b.value
UPDATE ...
ELSE
SELECT 'three', NULL
END IF
COMMIT TRANSACTION
{code}
The existing syntax would remain valid, when a single SELECT is defined in
which case the conditional SELECTs would not be valid.
SELECTs would be validated to return columns of the same type. They would be
able to return literals as well.
This would be make the result of the transaction more intuitive as the client
would know explicitly if the updates where applied or not.
The following syntax would be considered as invalid:
1. select defined both on the top level and in branches
{code:sql}
BEGIN TRANSACTION
LET a = ...
LET b = ...
SELECT ...
IF condition THEN
SELECT 'one', a.value
UPDATE ...
ELSE IF condition2 THEN
SELECT 'two', b.value
UPDATE ...
ELSE
SELECT 'three', NULL
END IF
COMMIT TRANSACTION
{code}
2. select defined after update - select must be before the update to make it
clear we select data before modification
{code:sql}
BEGIN TRANSACTION
LET a = ...
LET b = ...
IF condition THEN
UPDATE ...
SELECT 'one', a.value
ELSE IF condition2 THEN
UPDATE ...
SELECT 'two', b.value
ELSE
SELECT 'three', NULL
END IF
COMMIT TRANSACTION
{code}
3. missing select - if select is defined in a single branch, it has to be
defined in all branches:
{code:sql}
BEGIN TRANSACTION
LET a = ...
LET b = ...
IF condition THEN
SELECT 'one', a.value
UPDATE ...
ELSE IF condition2 THEN
SELECT 'two', b.value
UPDATE ...
ELSE
UPDATE ...
END IF
COMMIT TRANSACTION
{code}
{code:sql}
BEGIN TRANSACTION
LET a = ...
LET b = ...
IF condition THEN
SELECT 'one', a.value
UPDATE ...
END IF
COMMIT TRANSACTION
{code}
was:
I'd like to propose adding support for multiple branches and result sets for
Accord transactions. It could look like this:
{code:sql}
BEGIN TRANSACTION
LET a = ...
LET b = ...
IF condition THEN
SELECT 'one', a.value
UPDATE ...
ELSE IF condition2 THEN
SELECT 'two', b.value
UPDATE ...
ELSE
SELECT 'three', NULL
END IF
COMMIT TRANSACTION
{code}
The existing syntax would remain valid, when a single SELECT is defined in
which case the conditional SELECTs would not be valid.
SELECTs would be validated to return columns of the same type. They would be
able to return literals as well.
This would be make the result of the transaction more intuitive as the client
would know explicitly if the updates where applied or not.
> Add support for multiple condition branches and results in Accord transaction
> -
>
> Key: CASSANDRA-18465
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18465
> Project: Cassandra
> Issue Type: New Feature
> Components: Accord, CQL/Syntax
>Reporter: Jacek Lewandowski
>Priority: Normal
>
> I'd like to propose adding support for multiple branches and result sets for
> Accord transactions. It could look like this:
> {code:sql}
> BEGIN TRANSACTION
> LET a = ...
> LET b = ...
> IF condition THEN
> SELECT 'one', a.value
> UPDATE ...
> ELSE IF condition2 THEN
> SELECT 'two', b.value
> UPDATE ...
> ELSE
> SELECT 'three', NULL
> END IF
> COMMIT TRANSACTION
> {code}
> The existing syntax would remain valid, when a single SELECT is defined in
> which case the conditional SELECTs would not be valid.
> SELECTs would be validated to return columns of the same type. They would be
> able to return literals as well.
> This would be make the result of the transaction more intuitive as the client
> would know explicitly if the updates where applied or not.
> The following syntax would be considered as invalid:
> 1. select defined both on the top level and in branches
> {code:sql}
> BEGIN TRANSACTION
> LET a = ...
> LET b = ...
> SELECT ...
> IF condition THEN
> SELECT 'one', a.value
> UPDATE ...
> ELSE IF condition2 THEN
> SELECT 'two', b.value
> UPDATE ...
> ELSE
> SELECT 'three', NULL
> END IF
> COMMIT TRANSACTION
> {code}
> 2. select defined after update - select must be before the update to make it
> clear we select data before modification
> {code:sql}
> BEGIN TRANSACTION
> LET a = ...
> LET b = ...
> IF condition THEN
> UPDATE ...
> SELECT 'one', a.value
> ELSE IF condition2 THEN
> UPDATE ...
>
[jira] [Assigned] (CASSANDRA-18464) Enable Direct I/O For CommitLog Files
[ https://issues.apache.org/jira/browse/CASSANDRA-18464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amit Pawar reassigned CASSANDRA-18464: -- Assignee: (was: Amit Pawar) > Enable Direct I/O For CommitLog Files > - > > Key: CASSANDRA-18464 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18464 > Project: Cassandra > Issue Type: New Feature > Components: Local/Commit Log >Reporter: Josh McKenzie >Priority: Normal > Fix For: 6.x > > Attachments: UseDirectIOFeatureForCommitLogFiles.patch > > > Relocating from [dev@ email > thread.|https://lists.apache.org/thread/j6ny17q2rhkp7jxvwxm69dd6v1dozjrg] > > I shared my investigation about Commitlog I/O issue on large core count > system in my previous email dated July-22 and link to the thread is given > below. > [https://lists.apache.org/thread/xc5ocog2qz2v2gnj4xlw5hbthfqytx2n] > Basically, two solutions looked possible to improve the CommitLog I/O. > # Multi-threaded syncing > # Using Direct-IO through JNA > I worked on 2nd option considering the following benefit compared to the > first one > # Direct I/O read/write throughput is very high compared to non-Direct I/O. > Learnt through FIO benchmarking. > # Reduces kernel file cache uses which in-turn reduces kernel I/O activity > for Commitlog files only. > # Overall CPU usage reduced for flush activity. JVisualvm shows CPU usage < > 30% for Commitlog syncer thread with Direct I/O feature > # Direct I/O implementation is easier compared to multi-threaded > As per the community suggestion, less in code complex is good to have. Direct > I/O enablement looked promising but there was one issue. > Java version 8 does not have native support to enable Direct I/O. So, JNA > library usage is must. The same implementation should also work across other > versions of Java (like 11 and beyond). > I have completed Direct I/O implementation and summary of the attached patch > changes are given below. > # This implementation is not using Java file channels and file is opened > through JNA to use Direct I/O feature. > # New Segment are defined named “DirectIOSegment” for Direct I/O and > “NonDirectIOSegment” for non-direct I/O (NonDirectIOSegment is test purpose > only). > # JNA write call is used to flush the changes. > # New helper functions are defined in NativeLibrary.java and platform > specific file. Currently tested on Linux only. > # Patch allows user to configure optimum block size and alignment if > default values are not OK for CommitLog disk. > # Following configuration options are provided in Cassandra.yaml file > a. use_jna_for_commitlog_io : to use jna feature > b. use_direct_io_for_commitlog : to use Direct I/O feature. > c. direct_io_minimum_block_alignment: 512 (default) > d. nvme_disk_block_size: 32MiB (default and can be changed as per the > required size) > Test matrix is complex so CommitLog related testcases and TPCx-IOT benchmark > was tested. It works with both Java 8 and 11 versions. Compressed and > Encrypted based segments are not supported yet and it can be enabled later > based on the Community feedback. > Following improvement are seen with Direct I/O enablement. > # 32 cores >= ~15% > # 64 cores >= ~80% > Also, another observation would like to share here. Reading Commitlog files > with Direct I/O might help in reducing node bring-up time after the node > crash. > Tested with commit ID: 91f6a9aca8d3c22a03e68aa901a0b154d960ab07 > The attached patch enables Direct I/O feature for Commitlog files. Please > check and share your feedback. -- 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-18396) Dtests marked with @ported_to_in_jvm can be skipped since 4.1
[
https://issues.apache.org/jira/browse/CASSANDRA-18396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-18396:
--
Fix Version/s: 3.0.29
3.11.15
5.0
4.1.2
4.0.10
(was: 3.0.x)
(was: 3.11.x)
(was: 5.x)
(was: 4.0.x)
(was: 4.1.x)
Source Control Link:
https://github.com/apache/cassandra-dtest/commit/5715e36a71e261408dfd22f74f1f4b8df3983659
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
> Dtests marked with @ported_to_in_jvm can be skipped since 4.1
> -
>
> Key: CASSANDRA-18396
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18396
> Project: Cassandra
> Issue Type: Improvement
> Components: Test/dtest/python
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 3.0.29, 3.11.15, 5.0, 4.1.2, 4.0.10
>
>
> During the CASSANDRA-15536 epic we ported multiple Python dtests to in-JVM
> dtests.
> The ported Python dtests are still present but marked with a new
> {{@ported_to_in_jvm}} annotation. JVM dtests didn't support vnodes at that
> time, so when a Python dtest is marked with that annotation it's only run for
> vnodes config, whereas it's skipped if vnodes are off.
> However, we have had support for vnodes on JVM dtests since 4.1. Thus, I
> think we should modify the {{@ported_to_in_jvm}} annotation to also skip
> configs with vnodes if all the nodes are in 4.1 or later.
--
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-18396) Dtests marked with @ported_to_in_jvm can be skipped since 4.1
[
https://issues.apache.org/jira/browse/CASSANDRA-18396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17714044#comment-17714044
]
Andres de la Peña commented on CASSANDRA-18396:
---
Thanks for the review.
Committed as
[5715e36a71e261408dfd22f74f1f4b8df3983659|https://github.com/apache/cassandra-dtest/commit/5715e36a71e261408dfd22f74f1f4b8df3983659].
> Dtests marked with @ported_to_in_jvm can be skipped since 4.1
> -
>
> Key: CASSANDRA-18396
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18396
> Project: Cassandra
> Issue Type: Improvement
> Components: Test/dtest/python
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.x
>
>
> During the CASSANDRA-15536 epic we ported multiple Python dtests to in-JVM
> dtests.
> The ported Python dtests are still present but marked with a new
> {{@ported_to_in_jvm}} annotation. JVM dtests didn't support vnodes at that
> time, so when a Python dtest is marked with that annotation it's only run for
> vnodes config, whereas it's skipped if vnodes are off.
> However, we have had support for vnodes on JVM dtests since 4.1. Thus, I
> think we should modify the {{@ported_to_in_jvm}} annotation to also skip
> configs with vnodes if all the nodes are in 4.1 or later.
--
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-dtest] branch trunk updated: Skip tests marked with @ported_to_in_jvm independently of vnodes since 4.1
This is an automated email from the ASF dual-hosted git repository.
adelapena pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra-dtest.git
The following commit(s) were added to refs/heads/trunk by this push:
new 5715e36a Skip tests marked with @ported_to_in_jvm independently of
vnodes since 4.1
5715e36a is described below
commit 5715e36a71e261408dfd22f74f1f4b8df3983659
Author: Andrés de la Peña
AuthorDate: Tue Apr 18 11:48:28 2023 +0100
Skip tests marked with @ported_to_in_jvm independently of vnodes since 4.1
patch by Andrés de la Peña; reviewed by Brandon Williams for CASSANDRA-18396
---
conftest.py | 27 +--
1 file changed, 17 insertions(+), 10 deletions(-)
diff --git a/conftest.py b/conftest.py
index e07aeac6..dd4d00c2 100644
--- a/conftest.py
+++ b/conftest.py
@@ -474,24 +474,26 @@ def fixture_ported_to_in_jvm(request,
fixture_dtest_setup):
"""
Adds a new mark called 'ported_to_in_jvm' which denotes that a test was
ported to an in-JVM dtest.
-In-JVM dtests do not currently support running with vnodes, so tests that
use this annotation will
-still be run around those configurations.
+In-JVM dtests only support running with vnodes since 4.1, so tests that
use this annotation will
+still be run around those configurations if they are testing an older
branch.
"""
marker = request.node.get_closest_marker('ported_to_in_jvm')
-if marker and not request.config.getoption("--use-vnodes"):
+if marker:
-if not marker.args:
-pytest.skip("ported to in-jvm")
-
-from_str = marker.args[0]
+from_str = marker.args[0] if marker.args else "2.2.13" # JVM dtests
were introduced on 2.2.13
ported_from_version = LooseVersion(from_str)
+use_vnodes = request.config.getoption("--use-vnodes")
-# For upgrade tests don't run the test if any of the involved versions
-# are excluded by the annotation
+# For upgrade tests don't run the test if any of the involved versions
are excluded by the annotation
if hasattr(request.cls, "UPGRADE_PATH"):
+
+# JVM upgrade dtests don't support vnodes, so we can't skip them
+if use_vnodes:
+return
+
upgrade_path = request.cls.UPGRADE_PATH
if hasattr(upgrade_path, 'upgrade_meta'):
-skip_msg =
_skip_msg(LooseVersion(upgrade_path.upgrade_meta.family), since, max_version)
+skip_msg =
_skip_ported_msg(LooseVersion(upgrade_path.upgrade_meta.family),
ported_from_version)
if skip_msg:
pytest.skip(skip_msg)
ccm_repo_cache_dir, _ =
ccmlib.repository.setup(upgrade_path.starting_meta.version)
@@ -510,6 +512,11 @@ def fixture_ported_to_in_jvm(request, fixture_dtest_setup):
# Use cassandra_version_from_build as it's guaranteed to be a
LooseVersion
# whereas cassandra_version may be a string if set in the cli
options
current_running_version =
fixture_dtest_setup.dtest_config.cassandra_version_from_build
+
+# vnodes weren't supported nor tested before 4.1, so we can't skip
them if the version is older than that
+if use_vnodes and loose_version_compare(current_running_version,
LooseVersion('4.1')) < 0:
+return
+
skip_msg = _skip_ported_msg(current_running_version,
ported_from_version)
if skip_msg:
pytest.skip(skip_msg)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18105) TRUNCATED data come back after a restart or upgrade
[
https://issues.apache.org/jira/browse/CASSANDRA-18105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-18105:
--
Fix Version/s: 4.1.x
5.x
> TRUNCATED data come back after a restart or upgrade
> ---
>
> Key: CASSANDRA-18105
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18105
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/2i Index
>Reporter: Ke Han
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 2.2.x, 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.x
>
>
> When we use the TRUNCATE command to delete all data in the table, the deleted
> data come back after a node restart or upgrade. This problem happens at the
> latest releases (2.2.19, 3.0.28, or 4.0.7)
> h1. Steps to reproduce
> h2. To reproduce it at release (3.0.28 or 4.0.7)
> Start up a single Cassandra node. Using the default configuration and execute
> the following cqlsh commands.
> {code:java}
> CREATE KEYSPACE IF NOT EXISTS ks WITH REPLICATION = { 'class' :
> 'SimpleStrategy', 'replication_factor' : 1 };
> CREATE TABLE ks.tb (c3 TEXT,c4 TEXT,c2 INT,c1 TEXT, PRIMARY KEY (c1, c2, c3
> ));
> INSERT INTO ks.tb (c3, c1, c2) VALUES ('val1','val2',1);
> CREATE INDEX IF NOT EXISTS tb ON ks.tb ( c3);
> TRUNCATE TABLE ks.tb;
> DROP INDEX IF EXISTS ks.tb; {code}
> Execute a read command
> {code:java}
> cqlsh> SELECT c2 FROM ks.tb;
> c2
>
> (0 rows) {code}
> Then, we flush the node and kill the Cassandra daemon by
> {code:java}
> bin/nodetool flush
> pgrep -f cassandra | xargs kill -9 {code}
> We restart the node. When the node has started, perform the same read, and
> the deleted data comes back again.
> {code:java}
> cqlsh> SELECT c2 FROM ks.tb;
> c2
>
> 1
> (1 rows) {code}
> h2. To reproduce it at release (2.2.19)
> We don't need to kill the Cassandra daemon. Use bin/nodetool stopdaemon is
> enough. The other steps are the same as reproducing it at 4.0.7 or 3.0.28.
> {code:java}
> bin/nodetool -h :::127.0.0.1 flush
> bin/nodetool -h :::127.0.0.1 stopdaemon{code}
>
> I have put the full log to reproduce it for release 4.0.7 and 2.2.19 in the
> comments.
--
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-18460) CEP-21 Ensure that ClusterMetadata::forceEpoch keeps component epochs consistent
[
https://issues.apache.org/jira/browse/CASSANDRA-18460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson updated CASSANDRA-18460:
Status: Review In Progress (was: Patch Available)
+1
> CEP-21 Ensure that ClusterMetadata::forceEpoch keeps component epochs
> consistent
>
>
> Key: CASSANDRA-18460
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18460
> Project: Cassandra
> Issue Type: Improvement
> Components: Transactional Cluster Metadata
>Reporter: Sam Tunnicliffe
>Assignee: Sam Tunnicliffe
>Priority: Normal
>
> {{forceEpoch}} is used to make the application of multiple transformations in
> series appear as a single atomic update. It's primary use is in
> {{UnsafeJoin}} (i.e. join without bootstrap) to apply the usual sequence of
> start/mid/finish join in a single transformation. In such cases, we must
> ensure that no component of {{ClusterMetadata}} which maintains its own
> last-modified epoch, ends up with an epoch greater than the one of the
> enclosing {{ClusterMetadata}}.
--
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-18459) CEP-21 Rewrite o.a.c.distributed.test.SchemaTest
[ https://issues.apache.org/jira/browse/CASSANDRA-18459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-18459: Status: Review In Progress (was: Patch Available) +1 > CEP-21 Rewrite o.a.c.distributed.test.SchemaTest > > > Key: CASSANDRA-18459 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18459 > Project: Cassandra > Issue Type: Improvement > Components: Transactional Cluster Metadata >Reporter: Sam Tunnicliffe >Assignee: Sam Tunnicliffe >Priority: Normal > > Several of the premises that this test is based on are no longer valid. > Rewrite it so that instead of executing schema changes node-locally to > prevent them propagating, we can have the non-cms node pause before enacting > a schema change to enable us to verify that the expected exceptions are > thrown. Also, local schema reset and pulling during startup are not relevant > in TCM, so we can simplify the tests to ensure that a down node learns of any > missed updates when it restarts. -- 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-18458) CEP-21 During startup, don't open SSTables until local metadata log replay is complete
[
https://issues.apache.org/jira/browse/CASSANDRA-18458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson updated CASSANDRA-18458:
Status: Review In Progress (was: Patch Available)
+1
> CEP-21 During startup, don't open SSTables until local metadata log replay is
> complete
> --
>
> Key: CASSANDRA-18458
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18458
> Project: Cassandra
> Issue Type: Improvement
> Components: Transactional Cluster Metadata
>Reporter: Sam Tunnicliffe
>Assignee: Sam Tunnicliffe
>Priority: Normal
>
> Eagerly opening SSTables when their {{ColumnFamilyStore}} is first
> instantiated presents problems when replaying the local metadata log during
> startup. Schema modifications which _had_ been applied by the time an SSTable
> was written may not have been replayed yet, causing serialization errors. To
> address this, we can defer opening SSTables until after the local log replay
> is complete.
--
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-18457) CEP-21 Ensure that SchemaTransformation impls correctly set TableMetadata epoch
[
https://issues.apache.org/jira/browse/CASSANDRA-18457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17714003#comment-17714003
]
Marcus Eriksson commented on CASSANDRA-18457:
-
+1
> CEP-21 Ensure that SchemaTransformation impls correctly set TableMetadata
> epoch
> ---
>
> Key: CASSANDRA-18457
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18457
> Project: Cassandra
> Issue Type: Improvement
> Components: Transactional Cluster Metadata
>Reporter: Sam Tunnicliffe
>Assignee: Sam Tunnicliffe
>Priority: Normal
>
> Many existing {{SchemaTransformation}} implementations (not to mention as yet
> unimplemented ones) have the potential to modify {{TableMetadata}} and it is
> brittle to require each of them to take care of updating the metadata epoch.
> We should have {{ClusterMetadata.Transformer}} or the {{AlterSchema}}
> transformation itself handle this automatically.
--
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-18457) CEP-21 Ensure that SchemaTransformation impls correctly set TableMetadata epoch
[
https://issues.apache.org/jira/browse/CASSANDRA-18457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson updated CASSANDRA-18457:
Status: Review In Progress (was: Patch Available)
> CEP-21 Ensure that SchemaTransformation impls correctly set TableMetadata
> epoch
> ---
>
> Key: CASSANDRA-18457
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18457
> Project: Cassandra
> Issue Type: Improvement
> Components: Transactional Cluster Metadata
>Reporter: Sam Tunnicliffe
>Assignee: Sam Tunnicliffe
>Priority: Normal
>
> Many existing {{SchemaTransformation}} implementations (not to mention as yet
> unimplemented ones) have the potential to modify {{TableMetadata}} and it is
> brittle to require each of them to take care of updating the metadata epoch.
> We should have {{ClusterMetadata.Transformer}} or the {{AlterSchema}}
> transformation itself handle this automatically.
--
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-18465) Add support for multiple condition branches and results in Accord transaction
[
https://issues.apache.org/jira/browse/CASSANDRA-18465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17713988#comment-17713988
]
Benedict Elliott Smith commented on CASSANDRA-18465:
This was always intended to be the natural evolution of the syntax, so fully
support this of course.
> Add support for multiple condition branches and results in Accord transaction
> -
>
> Key: CASSANDRA-18465
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18465
> Project: Cassandra
> Issue Type: New Feature
> Components: Accord, CQL/Syntax
>Reporter: Jacek Lewandowski
>Priority: Normal
>
> I'd like to propose adding support for multiple branches and result sets for
> Accord transactions. It could look like this:
> {code:sql}
> BEGIN TRANSACTION
> LET a = ...
> LET b = ...
> IF condition THEN
> SELECT 'one', a.value
> UPDATE ...
> ELSE IF condition2 THEN
> SELECT 'two', b.value
> UPDATE ...
> ELSE
> SELECT 'three', NULL
> END IF
> COMMIT TRANSACTION
> {code}
> The existing syntax would remain valid, when a single SELECT is defined in
> which case the conditional SELECTs would not be valid.
> SELECTs would be validated to return columns of the same type. They would be
> able to return literals as well.
> This would be make the result of the transaction more intuitive as the client
> would know explicitly if the updates where applied or not.
--
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-18465) Add support for multiple condition branches and results in Accord transaction
Jacek Lewandowski created CASSANDRA-18465:
-
Summary: Add support for multiple condition branches and results
in Accord transaction
Key: CASSANDRA-18465
URL: https://issues.apache.org/jira/browse/CASSANDRA-18465
Project: Cassandra
Issue Type: New Feature
Components: Accord, CQL/Syntax
Reporter: Jacek Lewandowski
I'd like to propose adding support for multiple branches and result sets for
Accord transactions. It could look like this:
{code:sql}
BEGIN TRANSACTION
LET a = ...
LET b = ...
IF condition THEN
SELECT 'one', a.value
UPDATE ...
ELSE IF condition2 THEN
SELECT 'two', b.value
UPDATE ...
ELSE
SELECT 'three', NULL
END IF
COMMIT TRANSACTION
{code}
The existing syntax would remain valid, when a single SELECT is defined in
which case the conditional SELECTs would not be valid.
SELECTs would be validated to return columns of the same type. They would be
able to return literals as well.
This would be make the result of the transaction more intuitive as the client
would know explicitly if the updates where applied or not.
--
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-18464) Enable Direct I/O For CommitLog Files
[ https://issues.apache.org/jira/browse/CASSANDRA-18464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17713938#comment-17713938 ] maxwellguo edited comment on CASSANDRA-18464 at 4/19/23 7:55 AM: - I feel that this ci must be able to pass（of course the build /compile stage should pass first) , as the there lack of relevant ut test cases for Direct IO and the use_jna_for_commitlog_io is set to fasle so the related code are not coverd. was (Author: maxwellguo): I feel that this ci must be able to pass（except for build stage）, as the there lack of relevant ut test cases for Direct IO and the use_jna_for_commitlog_io is set to fasle so the related code are not coverd. > Enable Direct I/O For CommitLog Files > - > > Key: CASSANDRA-18464 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18464 > Project: Cassandra > Issue Type: New Feature > Components: Local/Commit Log >Reporter: Josh McKenzie >Assignee: Amit Pawar >Priority: Normal > Fix For: 6.x > > Attachments: UseDirectIOFeatureForCommitLogFiles.patch > > > Relocating from [dev@ email > thread.|https://lists.apache.org/thread/j6ny17q2rhkp7jxvwxm69dd6v1dozjrg] > > I shared my investigation about Commitlog I/O issue on large core count > system in my previous email dated July-22 and link to the thread is given > below. > [https://lists.apache.org/thread/xc5ocog2qz2v2gnj4xlw5hbthfqytx2n] > Basically, two solutions looked possible to improve the CommitLog I/O. > # Multi-threaded syncing > # Using Direct-IO through JNA > I worked on 2nd option considering the following benefit compared to the > first one > # Direct I/O read/write throughput is very high compared to non-Direct I/O. > Learnt through FIO benchmarking. > # Reduces kernel file cache uses which in-turn reduces kernel I/O activity > for Commitlog files only. > # Overall CPU usage reduced for flush activity. JVisualvm shows CPU usage < > 30% for Commitlog syncer thread with Direct I/O feature > # Direct I/O implementation is easier compared to multi-threaded > As per the community suggestion, less in code complex is good to have. Direct > I/O enablement looked promising but there was one issue. > Java version 8 does not have native support to enable Direct I/O. So, JNA > library usage is must. The same implementation should also work across other > versions of Java (like 11 and beyond). > I have completed Direct I/O implementation and summary of the attached patch > changes are given below. > # This implementation is not using Java file channels and file is opened > through JNA to use Direct I/O feature. > # New Segment are defined named “DirectIOSegment” for Direct I/O and > “NonDirectIOSegment” for non-direct I/O (NonDirectIOSegment is test purpose > only). > # JNA write call is used to flush the changes. > # New helper functions are defined in NativeLibrary.java and platform > specific file. Currently tested on Linux only. > # Patch allows user to configure optimum block size and alignment if > default values are not OK for CommitLog disk. > # Following configuration options are provided in Cassandra.yaml file > a. use_jna_for_commitlog_io : to use jna feature > b. use_direct_io_for_commitlog : to use Direct I/O feature. > c. direct_io_minimum_block_alignment: 512 (default) > d. nvme_disk_block_size: 32MiB (default and can be changed as per the > required size) > Test matrix is complex so CommitLog related testcases and TPCx-IOT benchmark > was tested. It works with both Java 8 and 11 versions. Compressed and > Encrypted based segments are not supported yet and it can be enabled later > based on the Community feedback. > Following improvement are seen with Direct I/O enablement. > # 32 cores >= ~15% > # 64 cores >= ~80% > Also, another observation would like to share here. Reading Commitlog files > with Direct I/O might help in reducing node bring-up time after the node > crash. > Tested with commit ID: 91f6a9aca8d3c22a03e68aa901a0b154d960ab07 > The attached patch enables Direct I/O feature for Commitlog files. Please > check and share your feedback. -- 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-17919) Capital P gets confused in the parser for a Duration in places where IDENT are needed
[
https://issues.apache.org/jira/browse/CASSANDRA-17919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-17919:
--
Reviewers: Stefan Miklosovic, Stefan Miklosovic
Stefan Miklosovic, Stefan Miklosovic (was: Stefan Miklosovic)
Status: Review In Progress (was: Patch Available)
> Capital P gets confused in the parser for a Duration in places where IDENT
> are needed
> -
>
> Key: CASSANDRA-17919
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17919
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Syntax
>Reporter: David Capwell
>Assignee: Maxim Chanturiay
>Priority: Normal
> Fix For: 3.11.x, 4.0.x, 4.1.x
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> This was found while adding Accord Transaction syntax into CQL and fuzz
> testing to validate all possible cases… in doing this the following was found
> {code}
> String query = "BEGIN TRANSACTION\n" +
>" LET P = (SELECT v FROM " + keyspace + ".tbl
> WHERE k=? AND c=?);\n" +
>" LET row2 = (SELECT v FROM " + keyspace + ".tbl
> WHERE k=? AND c=?);\n" +
>" SELECT v FROM " + keyspace + ".tbl WHERE k=?
> AND c=?;\n" +
>" IF P IS NULL AND row2.v = ? THEN\n" +
>"INSERT INTO " + keyspace + ".tbl (k, c, v)
> VALUES (?, ?, ?);\n" +
>" END IF\n" +
>"COMMIT TRANSACTION";
> {code}
> Fails with
> {code}
> SyntaxException: line 2:6 mismatched input 'P' expecting IDENT (BEGIN
> TRANSACTION LET [P]...)
> {code}
> The new LET syntax found this, but was able to reproduce in other cases
> {code}
> cqlsh:ks> CREATE TABLE P (k INT PRIMARY KEY);
> SyntaxException: line 1:13 no viable alternative at input 'P' (CREATE TABLE
> [P]...)
> cqlsh:ks>
> cqlsh:ks> CREATE TABLE p (k INT PRIMARY KEY);
> cqlsh:ks>
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17919) Capital P gets confused in the parser for a Duration in places where IDENT are needed
[
https://issues.apache.org/jira/browse/CASSANDRA-17919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-17919:
--
Fix Version/s: 5.x
> Capital P gets confused in the parser for a Duration in places where IDENT
> are needed
> -
>
> Key: CASSANDRA-17919
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17919
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Syntax
>Reporter: David Capwell
>Assignee: Maxim Chanturiay
>Priority: Normal
> Fix For: 3.11.x, 4.0.x, 4.1.x, 5.x
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> This was found while adding Accord Transaction syntax into CQL and fuzz
> testing to validate all possible cases… in doing this the following was found
> {code}
> String query = "BEGIN TRANSACTION\n" +
>" LET P = (SELECT v FROM " + keyspace + ".tbl
> WHERE k=? AND c=?);\n" +
>" LET row2 = (SELECT v FROM " + keyspace + ".tbl
> WHERE k=? AND c=?);\n" +
>" SELECT v FROM " + keyspace + ".tbl WHERE k=?
> AND c=?;\n" +
>" IF P IS NULL AND row2.v = ? THEN\n" +
>"INSERT INTO " + keyspace + ".tbl (k, c, v)
> VALUES (?, ?, ?);\n" +
>" END IF\n" +
>"COMMIT TRANSACTION";
> {code}
> Fails with
> {code}
> SyntaxException: line 2:6 mismatched input 'P' expecting IDENT (BEGIN
> TRANSACTION LET [P]...)
> {code}
> The new LET syntax found this, but was able to reproduce in other cases
> {code}
> cqlsh:ks> CREATE TABLE P (k INT PRIMARY KEY);
> SyntaxException: line 1:13 no viable alternative at input 'P' (CREATE TABLE
> [P]...)
> cqlsh:ks>
> cqlsh:ks> CREATE TABLE p (k INT PRIMARY KEY);
> cqlsh:ks>
> {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-18018) List command output not correct for super user, after grant command
[
https://issues.apache.org/jira/browse/CASSANDRA-18018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17713947#comment-17713947
]
Sam Tunnicliffe commented on CASSANDRA-18018:
-
[~maximc] yep, I will review in the next day or two.
> List command output not correct for super user, after grant command
> ---
>
> Key: CASSANDRA-18018
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18018
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Authorization
>Reporter: Shailaja Koppu
>Assignee: Maxim Chanturiay
>Priority: Normal
> Labels: lhf
> Fix For: 4.1.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Running local Cassandra with below config:
> {noformat}
> authenticator: PasswordAuthenticator
> authorizer: CassandraAuthorizer
> role_manager: CassandraRoleManager
> network_authorizer: CassandraNetworkAuthorizer{noformat}
> Created a super user and then ran *Grant select* command on a keyspace.
> {noformat}
> shaadmin1@cqlsh> CREATE USER 'shaadmin1c1' WITH PASSWORD 'shaadmin1c1'
> SUPERUSER;
> shaadmin1@cqlsh:system_auth> grant select on testk1.t1 to shaadmin1c1;
> shaadmin1@cqlsh:system_auth> alter role shaadmin1c1 with access to all
> datacenters;
> {noformat}
>
> After this, list permissions command showing only select permission for that
> role on the resource.
> {noformat}
> shaadmin1c1@cqlsh> list all permissions of shaadmin1c1;
> role | username | resource | permission
> +---
> shaadmin1c1 | shaadmin1c1 | | SELECT
> {noformat}
>
> Row in role_permissions table:
> {noformat}
> role | resource | permissions
> --
> shaadmin1c1 | data/testk1/t1 | {'SELECT'}{noformat}
> But insert command by that role on the resource is successful because role is
> a super user
> {noformat}
> shaadmin1c1@cqlsh> insert into testk1.t1 (c1, c2) values ('a', 1);
> shaadmin1c1@cqlsh> select * from testk1.t1 ;
> c1 | c2
> ---+---
> a | 1
> (1 rows)
> {noformat}
>
> The problem is, output of list permissions command, which indicates only
> select permission on the resource, is misleading. I think list command need
> to be fixed to show all permissions super user has on the resource. Also
> grant command for a super user can be either a no-op or throw error, because
> the role already have requested permissions.
>
> Documentation also misleading:
> {quote}True automatically grants AUTHORIZE, CREATE and DROP permission on ALL
> ROLES.
> Superusers can only manage roles by default. To manage other resources,
> {color:#ff}you must grant the permission set to that resource. **
> {color}For example, to allow access management for all keyspaces: {{{}GRANT
> ALL PERMISSIONS ON ALL KEYSPACES TO }}\{{{}{*}role_name{*}{}}}.
> {quote}
>
>
>
--
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-18464) Enable Direct I/O For CommitLog Files
[ https://issues.apache.org/jira/browse/CASSANDRA-18464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17713938#comment-17713938 ] maxwellguo commented on CASSANDRA-18464: I feel that this ci must be able to pass（except for build stage）, as the there lack of relevant ut test cases for Direct IO and the use_jna_for_commitlog_io is set to fasle so the related code are not coverd. > Enable Direct I/O For CommitLog Files > - > > Key: CASSANDRA-18464 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18464 > Project: Cassandra > Issue Type: New Feature > Components: Local/Commit Log >Reporter: Josh McKenzie >Assignee: Amit Pawar >Priority: Normal > Fix For: 6.x > > Attachments: UseDirectIOFeatureForCommitLogFiles.patch > > > Relocating from [dev@ email > thread.|https://lists.apache.org/thread/j6ny17q2rhkp7jxvwxm69dd6v1dozjrg] > > I shared my investigation about Commitlog I/O issue on large core count > system in my previous email dated July-22 and link to the thread is given > below. > [https://lists.apache.org/thread/xc5ocog2qz2v2gnj4xlw5hbthfqytx2n] > Basically, two solutions looked possible to improve the CommitLog I/O. > # Multi-threaded syncing > # Using Direct-IO through JNA > I worked on 2nd option considering the following benefit compared to the > first one > # Direct I/O read/write throughput is very high compared to non-Direct I/O. > Learnt through FIO benchmarking. > # Reduces kernel file cache uses which in-turn reduces kernel I/O activity > for Commitlog files only. > # Overall CPU usage reduced for flush activity. JVisualvm shows CPU usage < > 30% for Commitlog syncer thread with Direct I/O feature > # Direct I/O implementation is easier compared to multi-threaded > As per the community suggestion, less in code complex is good to have. Direct > I/O enablement looked promising but there was one issue. > Java version 8 does not have native support to enable Direct I/O. So, JNA > library usage is must. The same implementation should also work across other > versions of Java (like 11 and beyond). > I have completed Direct I/O implementation and summary of the attached patch > changes are given below. > # This implementation is not using Java file channels and file is opened > through JNA to use Direct I/O feature. > # New Segment are defined named “DirectIOSegment” for Direct I/O and > “NonDirectIOSegment” for non-direct I/O (NonDirectIOSegment is test purpose > only). > # JNA write call is used to flush the changes. > # New helper functions are defined in NativeLibrary.java and platform > specific file. Currently tested on Linux only. > # Patch allows user to configure optimum block size and alignment if > default values are not OK for CommitLog disk. > # Following configuration options are provided in Cassandra.yaml file > a. use_jna_for_commitlog_io : to use jna feature > b. use_direct_io_for_commitlog : to use Direct I/O feature. > c. direct_io_minimum_block_alignment: 512 (default) > d. nvme_disk_block_size: 32MiB (default and can be changed as per the > required size) > Test matrix is complex so CommitLog related testcases and TPCx-IOT benchmark > was tested. It works with both Java 8 and 11 versions. Compressed and > Encrypted based segments are not supported yet and it can be enabled later > based on the Community feedback. > Following improvement are seen with Direct I/O enablement. > # 32 cores >= ~15% > # 64 cores >= ~80% > Also, another observation would like to share here. Reading Commitlog files > with Direct I/O might help in reducing node bring-up time after the node > crash. > Tested with commit ID: 91f6a9aca8d3c22a03e68aa901a0b154d960ab07 > The attached patch enables Direct I/O feature for Commitlog files. Please > check and share your feedback. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17869) Add JDK17 option to cassandra-builds (build-scripts and jenkins dsl) and on jenkins agents
[
https://issues.apache.org/jira/browse/CASSANDRA-17869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17713936#comment-17713936
]
Michael Semb Wever commented on CASSANDRA-17869:
{quote}
bq. Strictly speaking I think this is out-of-scope. Will look if it is easy to
fix…
I am confused. When I asked for a separate ticket for upgrade tests you said
you will handle them here and you also initiated updating the upgrade paths.
With that said, I don't mind if you pull in a follow up ticket all upgrade
paths changes and we focus on bringing upgrade tests J11 to what we see
currently with J8. Please let me know.
{quote}
Fixed here:
https://github.com/apache/cassandra-dtest/commit/274865a2526c4f267b0ff0552d286573a395d4ad#r109607751
> Add JDK17 option to cassandra-builds (build-scripts and jenkins dsl) and on
> jenkins agents
> --
>
> Key: CASSANDRA-17869
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17869
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> Add JDK17 option to cassandra-builds build-scripts, they only currently
> support options {{8}} and {{11}}.
> Add JDK17 to the matrix axes in the jenkins dsl.
> Ensure JDK17 is installed on all the jenkins agents.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
