[jira] [Commented] (CASSANDRA-17761) WEBSITE - July 2022 blog "Apache Cassandra 4.1 Features: Pluggable Memtable Implementations"
[
https://issues.apache.org/jira/browse/CASSANDRA-17761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17569816#comment-17569816
]
Erick Ramirez commented on CASSANDRA-17761:
---
I’ve completed final verification in staging and [published to
production|https://github.com/apache/cassandra-website#merging-asf-staging-to-asf-site]:
{noformat}
$ git branch
* trunk
$ git fetch origin
$ git checkout asf-site
Branch ‘asf-site’ set up to track remote branch ‘asf-site’ from ‘origin’.
Switched to a new branch ‘asf-site’
$ git branch
* asf-site
trunk
$ git reset --hard origin/asf-staging
HEAD is now at 74fe0267 generate docs for 93aef61a
$ git push -f origin asf-site
Username for ‘https://github.com’: erickramirezau
Password for ‘https://erickramire...@github.com’:
Total 0 (delta 0), reused 0 (delta 0)
To https://github.com/apache/cassandra-website.git
+ d0a618ba...74fe0267 asf-site -> asf-site (forced update)
{noformat}
The blog post is now live on the site –
https://cassandra.apache.org/_/blog/Apache-Cassandra-4.1-Features-Pluggable-Memtable-Implementations.html
> WEBSITE - July 2022 blog "Apache Cassandra 4.1 Features: Pluggable Memtable
> Implementations"
>
>
> Key: CASSANDRA-17761
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17761
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Blog
>Reporter: Diogenese Topper
>Assignee: Erick Ramirez
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.1.x
>
> Attachments: CASSANDRA-17761v2.patch, c17761-01-blog-index.png,
> c17761-02-blog-post.png
>
>
> This ticket is to capture the work associated with publishing the July 2022
> blog "Apache Cassandra 4.1 Features: Pluggable Memtable Implementations"
> If this blog cannot be published by the *July 21, 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 asf-site updated (d0a618ba -> 74fe0267)
This is an automated email from the ASF dual-hosted git repository.
erickramirezau pushed a change to branch asf-site
in repository https://gitbox.apache.org/repos/asf/cassandra-website.git
discard d0a618ba ninja-fix 4.0.5 until ci rebuilds
discard 2c21e605 generate docs for 16e3fe55
add ea0e75d5 Release 4.0.5 ref:
https://lists.apache.org/thread/7yld3zbhpwpzsszmppfzf6x4bff1vtow
add 93aef61a BLOG - Pluggable Memtable Implementations in C* 4.1
add 74fe0267 generate docs for 93aef61a
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 (d0a618ba)
\
N -- N -- N refs/heads/asf-site (74fe0267)
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.
No new revisions were added by this update.
Summary of changes:
...es-Pluggable-Memtable-Implementations-graph.png | Bin 0 -> 59505 bytes
...ble-Implementations-unsplash-neven-krcmarek.jpg | Bin 0 -> 160183 bytes
content/_/blog.html| 24 +++
...atures-Pluggable-Memtable-Implementations.html} | 80 -
content/search-index.js| 2 +-
...es-Pluggable-Memtable-Implementations-graph.png | Bin 0 -> 59505 bytes
...ble-Implementations-unsplash-neven-krcmarek.jpg | Bin 0 -> 160183 bytes
site-content/source/modules/ROOT/pages/blog.adoc | 25 +++
...eatures-Pluggable-Memtable-Implementations.adoc | 49 +
.../source/modules/ROOT/pages/download.adoc| 4 +-
site-ui/build/ui-bundle.zip| Bin 4740078 -> 4740078
bytes
11 files changed, 148 insertions(+), 36 deletions(-)
create mode 100644
content/_/_images/blog/Apache-Cassandra-4.1-Features-Pluggable-Memtable-Implementations-graph.png
create mode 100644
content/_/_images/blog/Apache-Cassandra-4.1-Features-Pluggable-Memtable-Implementations-unsplash-neven-krcmarek.jpg
copy
content/_/blog/{Last-Chance-to-Register-Schedule-Moderators-Announced.html =>
Apache-Cassandra-4.1-Features-Pluggable-Memtable-Implementations.html} (74%)
create mode 100644
site-content/source/modules/ROOT/images/blog/Apache-Cassandra-4.1-Features-Pluggable-Memtable-Implementations-graph.png
create mode 100644
site-content/source/modules/ROOT/images/blog/Apache-Cassandra-4.1-Features-Pluggable-Memtable-Implementations-unsplash-neven-krcmarek.jpg
create mode 100644
site-content/source/modules/ROOT/pages/blog/Apache-Cassandra-4.1-Features-Pluggable-Memtable-Implementations.adoc
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17761) WEBSITE - July 2022 blog "Apache Cassandra 4.1 Features: Pluggable Memtable Implementations"
[ https://issues.apache.org/jira/browse/CASSANDRA-17761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17569813#comment-17569813 ] Erick Ramirez commented on CASSANDRA-17761: --- The blog post is now in staging – https://cassandra.staged.apache.org/_/blog/Apache-Cassandra-4.1-Features-Pluggable-Memtable-Implementations.html > WEBSITE - July 2022 blog "Apache Cassandra 4.1 Features: Pluggable Memtable > Implementations" > > > Key: CASSANDRA-17761 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17761 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Diogenese Topper >Assignee: Erick Ramirez >Priority: Normal > Labels: pull-request-available > Fix For: 4.1.x > > Attachments: CASSANDRA-17761v2.patch, c17761-01-blog-index.png, > c17761-02-blog-post.png > > > This ticket is to capture the work associated with publishing the July 2022 > blog "Apache Cassandra 4.1 Features: Pluggable Memtable Implementations" > If this blog cannot be published by the *July 21, 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 asf-staging updated (21cc0a70 -> 74fe0267)
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 21cc0a70 generate docs for ea0e75d5
add 93aef61a BLOG - Pluggable Memtable Implementations in C* 4.1
new 74fe0267 generate docs for 93aef61a
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 (21cc0a70)
\
N -- N -- N refs/heads/asf-staging (74fe0267)
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:
...es-Pluggable-Memtable-Implementations-graph.png | Bin 0 -> 59505 bytes
...ble-Implementations-unsplash-neven-krcmarek.jpg | Bin 0 -> 160183 bytes
content/_/blog.html| 24 +++
...atures-Pluggable-Memtable-Implementations.html} | 80 -
content/search-index.js| 2 +-
...es-Pluggable-Memtable-Implementations-graph.png | Bin 0 -> 59505 bytes
...ble-Implementations-unsplash-neven-krcmarek.jpg | Bin 0 -> 160183 bytes
site-content/source/modules/ROOT/pages/blog.adoc | 25 +++
...eatures-Pluggable-Memtable-Implementations.adoc | 49 +
site-ui/build/ui-bundle.zip| Bin 4740078 -> 4740078
bytes
10 files changed, 146 insertions(+), 34 deletions(-)
create mode 100644
content/_/_images/blog/Apache-Cassandra-4.1-Features-Pluggable-Memtable-Implementations-graph.png
create mode 100644
content/_/_images/blog/Apache-Cassandra-4.1-Features-Pluggable-Memtable-Implementations-unsplash-neven-krcmarek.jpg
copy
content/_/blog/{Last-Chance-to-Register-Schedule-Moderators-Announced.html =>
Apache-Cassandra-4.1-Features-Pluggable-Memtable-Implementations.html} (74%)
create mode 100644
site-content/source/modules/ROOT/images/blog/Apache-Cassandra-4.1-Features-Pluggable-Memtable-Implementations-graph.png
create mode 100644
site-content/source/modules/ROOT/images/blog/Apache-Cassandra-4.1-Features-Pluggable-Memtable-Implementations-unsplash-neven-krcmarek.jpg
create mode 100644
site-content/source/modules/ROOT/pages/blog/Apache-Cassandra-4.1-Features-Pluggable-Memtable-Implementations.adoc
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17761) WEBSITE - July 2022 blog "Apache Cassandra 4.1 Features: Pluggable Memtable Implementations"
[
https://issues.apache.org/jira/browse/CASSANDRA-17761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17569808#comment-17569808
]
Erick Ramirez commented on CASSANDRA-17761:
---
The website content is getting built in staging:
||Branch||PR||Commit||Build||
|{{trunk}}|[#155|https://github.com/apache/cassandra-website/pull/155]|[93aef61
|https://github.com/apache/cassandra-website/commit/93aef61a162c3074b284b096208c38964930baea]|[#438|https://ci-cassandra.apache.org/job/cassandra-website/438/]|
> WEBSITE - July 2022 blog "Apache Cassandra 4.1 Features: Pluggable Memtable
> Implementations"
>
>
> Key: CASSANDRA-17761
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17761
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Blog
>Reporter: Diogenese Topper
>Assignee: Erick Ramirez
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.1.x
>
> Attachments: CASSANDRA-17761v2.patch, c17761-01-blog-index.png,
> c17761-02-blog-post.png
>
>
> This ticket is to capture the work associated with publishing the July 2022
> blog "Apache Cassandra 4.1 Features: Pluggable Memtable Implementations"
> If this blog cannot be published by the *July 21, 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-17761) WEBSITE - July 2022 blog "Apache Cassandra 4.1 Features: Pluggable Memtable Implementations"
[
https://issues.apache.org/jira/browse/CASSANDRA-17761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Ramirez updated CASSANDRA-17761:
--
Source Control Link:
https://github.com/apache/cassandra-website/commit/93aef61a162c3074b284b096208c38964930baea
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Committed:
||Branch||PR||Commit||
|{{trunk}}|[#155|https://github.com/apache/cassandra-website/pull/155]|[93aef61
|https://github.com/apache/cassandra-website/commit/93aef61a162c3074b284b096208c38964930baea]|
> WEBSITE - July 2022 blog "Apache Cassandra 4.1 Features: Pluggable Memtable
> Implementations"
>
>
> Key: CASSANDRA-17761
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17761
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Blog
>Reporter: Diogenese Topper
>Assignee: Erick Ramirez
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.1.x
>
> Attachments: CASSANDRA-17761v2.patch, c17761-01-blog-index.png,
> c17761-02-blog-post.png
>
>
> This ticket is to capture the work associated with publishing the July 2022
> blog "Apache Cassandra 4.1 Features: Pluggable Memtable Implementations"
> If this blog cannot be published by the *July 21, 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 - Pluggable Memtable Implementations in C* 4.1
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 93aef61a BLOG - Pluggable Memtable Implementations in C* 4.1 93aef61a is described below commit 93aef61a162c3074b284b096208c38964930baea Author: Diogenese Topper AuthorDate: Thu Jul 21 16:53:28 2022 -0700 BLOG - Pluggable Memtable Implementations in C* 4.1 patch by Branimir Lambov, Chris Thornett, Diogenese Topper; reviewed by Erick Ramirez for CASSANDRA-17761 Co-authored by: Branimir Lambov Co-authored by: Chris Thornett Co-authored by: Diogenese Topper --- ...es-Pluggable-Memtable-Implementations-graph.png | Bin 0 -> 59505 bytes ...ble-Implementations-unsplash-neven-krcmarek.jpg | Bin 0 -> 160183 bytes site-content/source/modules/ROOT/pages/blog.adoc | 25 +++ ...eatures-Pluggable-Memtable-Implementations.adoc | 49 + 4 files changed, 74 insertions(+) diff --git a/site-content/source/modules/ROOT/images/blog/Apache-Cassandra-4.1-Features-Pluggable-Memtable-Implementations-graph.png b/site-content/source/modules/ROOT/images/blog/Apache-Cassandra-4.1-Features-Pluggable-Memtable-Implementations-graph.png new file mode 100644 index ..73734f08 Binary files /dev/null and b/site-content/source/modules/ROOT/images/blog/Apache-Cassandra-4.1-Features-Pluggable-Memtable-Implementations-graph.png differ diff --git a/site-content/source/modules/ROOT/images/blog/Apache-Cassandra-4.1-Features-Pluggable-Memtable-Implementations-unsplash-neven-krcmarek.jpg b/site-content/source/modules/ROOT/images/blog/Apache-Cassandra-4.1-Features-Pluggable-Memtable-Implementations-unsplash-neven-krcmarek.jpg new file mode 100644 index ..feb54ba1 Binary files /dev/null and b/site-content/source/modules/ROOT/images/blog/Apache-Cassandra-4.1-Features-Pluggable-Memtable-Implementations-unsplash-neven-krcmarek.jpg differ diff --git a/site-content/source/modules/ROOT/pages/blog.adoc b/site-content/source/modules/ROOT/pages/blog.adoc index ac901176..29b6fe3a 100644 --- a/site-content/source/modules/ROOT/pages/blog.adoc +++ b/site-content/source/modules/ROOT/pages/blog.adoc @@ -8,6 +8,31 @@ 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] +=== Apache Cassandra 4.1 Features: Pluggable Memtable Implementations +[discrete] + July 21, 2022 +-- +[openblock,card-content] +-- +Apache Cassandra 4.1 supports alternative memtable implementations. Learn more about this feature and the proof of concept implementation included in the new release. + +[openblock,card-btn card-btn--blog] + + +[.btn.btn--alt] +xref:blog/Apache-Cassandra-4.1-Features-Pluggable-Memtable-Implementations.adoc[Read More] + + +-- + +//end card + //start card [openblock,card shadow relative test] diff --git a/site-content/source/modules/ROOT/pages/blog/Apache-Cassandra-4.1-Features-Pluggable-Memtable-Implementations.adoc b/site-content/source/modules/ROOT/pages/blog/Apache-Cassandra-4.1-Features-Pluggable-Memtable-Implementations.adoc new file mode 100644 index ..b10fe337 --- /dev/null +++ b/site-content/source/modules/ROOT/pages/blog/Apache-Cassandra-4.1-Features-Pluggable-Memtable-Implementations.adoc @@ -0,0 +1,49 @@ += Apache Cassandra 4.1 Features: Pluggable Memtable Implementations +:page-layout: single-post +:page-role: blog-post +:page-post-date: July 21, 2022 +:page-post-author: Branimir Lambov +:description: Pluggable Memtable Implementations in Apache Cassandra 4.1 +:keywords: apache cassandra, world party, cassandra world party, CWP, 2022, schedule, moderator + +:!figure-caption: + +.Image credit: https://unsplash.com/@nevenkrcmarek[Neven Krcmarek^] +image::blog/Apache-Cassandra-4.1-Features-Pluggable-Memtable-Implementations-unsplash-neven-krcmarek.jpg[Pluggable Memtable Implementations] + +One of the new features of Apache Cassandra 4.1, introduced with enhancement proposal #11 (https://cwiki.apache.org/confluence/x/0goBCw[CEP-11^]), is support for alternative memtable implementations. This feature enables developers to implement new memtable solutions and for users to select a memtable implementation and configuration for each individual table in the database. +This is enabled by a new memtable option in `CREATE TABLE` and `ALTER TABLE` statements that specifies the memtable configuration out of a set of options defined in `cassandra.yaml`, for example: + + +CREATE TABLE heavy_use … WITH memtable = 'sharded'; + + +where the `'sharded'` configuration is defined in `cassandra.yaml` as + + +Memtable: + Configurations: + Sharded: +
[jira] [Updated] (CASSANDRA-17761) WEBSITE - July 2022 blog "Apache Cassandra 4.1 Features: Pluggable Memtable Implementations"
[ https://issues.apache.org/jira/browse/CASSANDRA-17761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Ramirez updated CASSANDRA-17761: -- Status: Ready to Commit (was: Review In Progress) I've made the necessary updates so the PR is ready to commit. Details in [^CASSANDRA-17761v2.patch]. !c17761-01-blog-index.png|width=300! !c17761-02-blog-post.png|width=300! > WEBSITE - July 2022 blog "Apache Cassandra 4.1 Features: Pluggable Memtable > Implementations" > > > Key: CASSANDRA-17761 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17761 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Diogenese Topper >Assignee: Erick Ramirez >Priority: Normal > Labels: pull-request-available > Fix For: 4.1.x > > Attachments: CASSANDRA-17761v2.patch, c17761-01-blog-index.png, > c17761-02-blog-post.png > > > This ticket is to capture the work associated with publishing the July 2022 > blog "Apache Cassandra 4.1 Features: Pluggable Memtable Implementations" > If this blog cannot be published by the *July 21, 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-17761) WEBSITE - July 2022 blog "Apache Cassandra 4.1 Features: Pluggable Memtable Implementations"
[ https://issues.apache.org/jira/browse/CASSANDRA-17761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Ramirez updated CASSANDRA-17761: -- Status: Review In Progress (was: Changes Suggested) > WEBSITE - July 2022 blog "Apache Cassandra 4.1 Features: Pluggable Memtable > Implementations" > > > Key: CASSANDRA-17761 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17761 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Diogenese Topper >Assignee: Erick Ramirez >Priority: Normal > Labels: pull-request-available > Fix For: 4.1.x > > Attachments: CASSANDRA-17761v2.patch, c17761-01-blog-index.png, > c17761-02-blog-post.png > > > This ticket is to capture the work associated with publishing the July 2022 > blog "Apache Cassandra 4.1 Features: Pluggable Memtable Implementations" > If this blog cannot be published by the *July 21, 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-17761) WEBSITE - July 2022 blog "Apache Cassandra 4.1 Features: Pluggable Memtable Implementations"
[ https://issues.apache.org/jira/browse/CASSANDRA-17761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Ramirez updated CASSANDRA-17761: -- Attachment: c17761-02-blog-post.png c17761-01-blog-index.png > WEBSITE - July 2022 blog "Apache Cassandra 4.1 Features: Pluggable Memtable > Implementations" > > > Key: CASSANDRA-17761 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17761 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Diogenese Topper >Assignee: Erick Ramirez >Priority: Normal > Labels: pull-request-available > Fix For: 4.1.x > > Attachments: CASSANDRA-17761v2.patch, c17761-01-blog-index.png, > c17761-02-blog-post.png > > > This ticket is to capture the work associated with publishing the July 2022 > blog "Apache Cassandra 4.1 Features: Pluggable Memtable Implementations" > If this blog cannot be published by the *July 21, 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-17761) WEBSITE - July 2022 blog "Apache Cassandra 4.1 Features: Pluggable Memtable Implementations"
[ https://issues.apache.org/jira/browse/CASSANDRA-17761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Ramirez updated CASSANDRA-17761: -- Attachment: CASSANDRA-17761v2.patch > WEBSITE - July 2022 blog "Apache Cassandra 4.1 Features: Pluggable Memtable > Implementations" > > > Key: CASSANDRA-17761 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17761 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Diogenese Topper >Assignee: Erick Ramirez >Priority: Normal > Labels: pull-request-available > Fix For: 4.1.x > > Attachments: CASSANDRA-17761v2.patch > > > This ticket is to capture the work associated with publishing the July 2022 > blog "Apache Cassandra 4.1 Features: Pluggable Memtable Implementations" > If this blog cannot be published by the *July 21, 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-17761) WEBSITE - July 2022 blog "Apache Cassandra 4.1 Features: Pluggable Memtable Implementations"
[
https://issues.apache.org/jira/browse/CASSANDRA-17761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Ramirez updated CASSANDRA-17761:
--
Status: Changes Suggested (was: Review In Progress)
The following elements need to be fixed:
bq. One of the new features of Apache Cassandra 4.1, introduced with [Cassandra
Enhancement Proposal (CEP) 11|https://cwiki.apache.org/confluence/x/0goBCw], is
support for alternative memtable implementations.
bq. where the '{{{color:#DE350B}sharded{color}}}' configuration is defined in
cassandra.yaml as
bq. A Trie-based memtable
([CEP-19|https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-19%3A+Trie+memtable+implementation]/https://issues.apache.org/jira/browse/CASSANDRA-17240[CASSANDRA-17240]),
> WEBSITE - July 2022 blog "Apache Cassandra 4.1 Features: Pluggable Memtable
> Implementations"
>
>
> Key: CASSANDRA-17761
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17761
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Blog
>Reporter: Diogenese Topper
>Assignee: Erick Ramirez
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.1.x
>
>
> This ticket is to capture the work associated with publishing the July 2022
> blog "Apache Cassandra 4.1 Features: Pluggable Memtable Implementations"
> If this blog cannot be published by the *July 21, 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-17761) WEBSITE - July 2022 blog "Apache Cassandra 4.1 Features: Pluggable Memtable Implementations"
[ https://issues.apache.org/jira/browse/CASSANDRA-17761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Ramirez updated CASSANDRA-17761: -- Authors: Branimir Lambov, Chris Thornett, Diogenese Topper (was: Erick Ramirez) > WEBSITE - July 2022 blog "Apache Cassandra 4.1 Features: Pluggable Memtable > Implementations" > > > Key: CASSANDRA-17761 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17761 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Diogenese Topper >Assignee: Erick Ramirez >Priority: Normal > Labels: pull-request-available > Fix For: 4.1.x > > > This ticket is to capture the work associated with publishing the July 2022 > blog "Apache Cassandra 4.1 Features: Pluggable Memtable Implementations" > If this blog cannot be published by the *July 21, 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-17761) WEBSITE - July 2022 blog "Apache Cassandra 4.1 Features: Pluggable Memtable Implementations"
[ https://issues.apache.org/jira/browse/CASSANDRA-17761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Ramirez updated CASSANDRA-17761: -- Reviewers: Erick Ramirez Status: Review In Progress (was: Patch Available) > WEBSITE - July 2022 blog "Apache Cassandra 4.1 Features: Pluggable Memtable > Implementations" > > > Key: CASSANDRA-17761 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17761 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Diogenese Topper >Assignee: Erick Ramirez >Priority: Normal > Labels: pull-request-available > Fix For: 4.1.x > > > This ticket is to capture the work associated with publishing the July 2022 > blog "Apache Cassandra 4.1 Features: Pluggable Memtable Implementations" > If this blog cannot be published by the *July 21, 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-17761) WEBSITE - July 2022 blog "Apache Cassandra 4.1 Features: Pluggable Memtable Implementations"
[ https://issues.apache.org/jira/browse/CASSANDRA-17761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Ramirez reassigned CASSANDRA-17761: - Assignee: Erick Ramirez > WEBSITE - July 2022 blog "Apache Cassandra 4.1 Features: Pluggable Memtable > Implementations" > > > Key: CASSANDRA-17761 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17761 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Diogenese Topper >Assignee: Erick Ramirez >Priority: Normal > Labels: pull-request-available > Fix For: 4.1.x > > > This ticket is to capture the work associated with publishing the July 2022 > blog "Apache Cassandra 4.1 Features: Pluggable Memtable Implementations" > If this blog cannot be published by the *July 21, 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-17735) Fix issues with index_summary_resize_interval and index_summary_capacity
[ https://issues.apache.org/jira/browse/CASSANDRA-17735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17569757#comment-17569757 ] Ekaterina Dimitrova commented on CASSANDRA-17735: - It seems there were some environmental issues - I just resubmitted the 4.1 [upgrade tests|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1793/workflows/951fd90a-618d-4156-91d1-559cb144d6cb], also one of the [cqlsh jobs|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1793/workflows/8e7db3b0-f847-428e-91df-eca838d09185/jobs/13345] The rest seems like known issues.It is interesting I see second time the simulator tests, one failing. I will open a ticket for that one but it is not related to this patch > Fix issues with index_summary_resize_interval and index_summary_capacity > > > Key: CASSANDRA-17735 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17735 > Project: Cassandra > Issue Type: Bug > Components: Local/Config >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Low > Fix For: 4.0.x, 4.1-beta, 4.x > > > There are a few problems: > 4.0+: > * the virtual table displays only the cassandra.yaml values for both > properties, all changes after startup are not updated > 4.1+: > * Breaking compatibility - -1 was considered disabled, this should be > considered as null now for the new config. The converter should be updated. > There is a test for the -1, disable but it didn't caught the issue because of > the previous issue mentioned (the disconnect between jmx and the actual > property in Config class) -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17768) streaming_keep_alive_period is not used after [CASSANDRA-16927] CEP-10 Phase 1: Refactor Streaming
[
https://issues.apache.org/jira/browse/CASSANDRA-17768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17569738#comment-17569738
]
Paulo Motta edited comment on CASSANDRA-17768 at 7/22/22 1:20 AM:
--
Nice catch [~e.dimitrova]! Can we clarify if {{streaming_keep_alive_period}} is
no longer needed to keep long-lived cross-dc connections active? I remember the
reason this was added was due to idle connections being reset and causing
streaming to fail after an inactivity period (since we used one inbound and
another outbound connection for streaming, so one direction could stay idle
while the other was active), not sure if this is still a potential issue after
CEP-10.
was (Author: paulo):
Nice catch [~e.dimitrova]! Can we clarify if {{streaming_keep_alive_period}} is
no longer needed to keep long-lived cross-dc connections active? I remember the
reason this was added was due to idle connections being reset after an
inactivity period (since we used one inbound and another outbound connection
for streaming, so one direction could stay idle while the other was active),
not sure if this is still a potential issue after CEP-10.
> streaming_keep_alive_period is not used after [CASSANDRA-16927] CEP-10 Phase
> 1: Refactor Streaming
> --
>
> Key: CASSANDRA-17768
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17768
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Streaming and Messaging
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.1-beta, 4.1.x, 4.x
>
>
> While working on another ticket I noticed that after [CASSANDRA-16927] CEP-10
> Phase 1: Refactor Streaming
> streaming_keep_alive_period is not used anymore, except to print it in error
> message
> [here|https://github.com/apache/cassandra/blob/cassandra-4.1/src/java/org/apache/cassandra/streaming/StreamSession.java#L689]
> If the property should not be used anymore, we need to deprecate it and fix
> the error message as it is misleading.
> [~benedict] , [~samt] , [~aleksey] , can you, please, check and take care of
> this one as authors of that patch?
> Thank you in advance!
--
This message was sent by Atlassian Jira
(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-17768) streaming_keep_alive_period is not used after [CASSANDRA-16927] CEP-10 Phase 1: Refactor Streaming
[
https://issues.apache.org/jira/browse/CASSANDRA-17768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17569738#comment-17569738
]
Paulo Motta commented on CASSANDRA-17768:
-
Nice catch [~e.dimitrova]! Can we clarify if {{streaming_keep_alive_period}} is
no longer needed to keep long-lived cross-dc connections active? I remember the
reason this was added was due to idle connections being reset after an
inactivity period (since we used one inbound and another outbound connection
for streaming, so one direction could stay idle while the other was active),
not sure if this is still a potential issue after CEP-10.
> streaming_keep_alive_period is not used after [CASSANDRA-16927] CEP-10 Phase
> 1: Refactor Streaming
> --
>
> Key: CASSANDRA-17768
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17768
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Streaming and Messaging
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.1-beta, 4.1.x, 4.x
>
>
> While working on another ticket I noticed that after [CASSANDRA-16927] CEP-10
> Phase 1: Refactor Streaming
> streaming_keep_alive_period is not used anymore, except to print it in error
> message
> [here|https://github.com/apache/cassandra/blob/cassandra-4.1/src/java/org/apache/cassandra/streaming/StreamSession.java#L689]
> If the property should not be used anymore, we need to deprecate it and fix
> the error message as it is misleading.
> [~benedict] , [~samt] , [~aleksey] , can you, please, check and take care of
> this one as authors of that patch?
> Thank you in advance!
--
This message was sent by Atlassian Jira
(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-17768) streaming_keep_alive_period is not used after [CASSANDRA-16927] CEP-10 Phase 1: Refactor Streaming
[ https://issues.apache.org/jira/browse/CASSANDRA-17768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-17768: Description: While working on another ticket I noticed that after [CASSANDRA-16927] CEP-10 Phase 1: Refactor Streaming streaming_keep_alive_period is not used anymore, except to print it in error message [here|https://github.com/apache/cassandra/blob/cassandra-4.1/src/java/org/apache/cassandra/streaming/StreamSession.java#L689] If the property should not be used anymore, we need to deprecate it and fix the error message as it is misleading. [~benedict] , [~samt] , [~aleksey] , can you, please, check and take care of this one as authors of that patch? Thank you in advance! was: While working on another ticket I noticed that after [CASSANDRA-16927] CEP-10 Phase 1: Refactor Streaming streaming_keep_alive_period is not used anymore, except to print it in error message [here|https://github.com/apache/cassandra/blob/cassandra-4.1/src/java/org/apache/cassandra/streaming/StreamSession.java#L689] If the property should not be used anymore, we need to deprecate it and fix the error message as it is misleading. [~benedict] , [~samt] , [~tuxslayer] , can you, please, check and take care of this one as authors of that patch? Thank you in advance! > streaming_keep_alive_period is not used after [CASSANDRA-16927] CEP-10 Phase > 1: Refactor Streaming > -- > > Key: CASSANDRA-17768 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17768 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Streaming and Messaging >Reporter: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.1-beta, 4.1.x, 4.x > > > While working on another ticket I noticed that after [CASSANDRA-16927] CEP-10 > Phase 1: Refactor Streaming > streaming_keep_alive_period is not used anymore, except to print it in error > message > [here|https://github.com/apache/cassandra/blob/cassandra-4.1/src/java/org/apache/cassandra/streaming/StreamSession.java#L689] > If the property should not be used anymore, we need to deprecate it and fix > the error message as it is misleading. > [~benedict] , [~samt] , [~aleksey] , can you, please, check and take care of > this one as authors of that patch? > Thank you in advance! -- This message was sent by Atlassian Jira (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-17768) streaming_keep_alive_period is not used after [CASSANDRA-16927] CEP-10 Phase 1: Refactor Streaming
[ https://issues.apache.org/jira/browse/CASSANDRA-17768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-17768: Bug Category: Parent values: Correctness(12982) Complexity: Normal Component/s: Legacy/Streaming and Messaging Discovered By: User Report Severity: Normal Status: Open (was: Triage Needed) > streaming_keep_alive_period is not used after [CASSANDRA-16927] CEP-10 Phase > 1: Refactor Streaming > -- > > Key: CASSANDRA-17768 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17768 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Streaming and Messaging >Reporter: Ekaterina Dimitrova >Priority: Normal > > While working on another ticket I noticed that after [CASSANDRA-16927] CEP-10 > Phase 1: Refactor Streaming > streaming_keep_alive_period is not used anymore, except to print it in error > message > [here|https://github.com/apache/cassandra/blob/cassandra-4.1/src/java/org/apache/cassandra/streaming/StreamSession.java#L689] > If the property should not be used anymore, we need to deprecate it and fix > the error message as it is misleading. > [~benedict] , [~samt] , [~tuxslayer] , can you, please, check and take care > of this one as authors of that patch? > Thank you in advance! -- This message was sent by Atlassian Jira (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-17768) streaming_keep_alive_period is not used after [CASSANDRA-16927] CEP-10 Phase 1: Refactor Streaming
[ https://issues.apache.org/jira/browse/CASSANDRA-17768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-17768: Fix Version/s: 4.1-beta 4.1.x 4.x > streaming_keep_alive_period is not used after [CASSANDRA-16927] CEP-10 Phase > 1: Refactor Streaming > -- > > Key: CASSANDRA-17768 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17768 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Streaming and Messaging >Reporter: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.1-beta, 4.1.x, 4.x > > > While working on another ticket I noticed that after [CASSANDRA-16927] CEP-10 > Phase 1: Refactor Streaming > streaming_keep_alive_period is not used anymore, except to print it in error > message > [here|https://github.com/apache/cassandra/blob/cassandra-4.1/src/java/org/apache/cassandra/streaming/StreamSession.java#L689] > If the property should not be used anymore, we need to deprecate it and fix > the error message as it is misleading. > [~benedict] , [~samt] , [~tuxslayer] , can you, please, check and take care > of this one as authors of that patch? > Thank you in advance! -- This message was sent by Atlassian Jira (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-17768) streaming_keep_alive_period is not used after [CASSANDRA-16927] CEP-10 Phase 1: Refactor Streaming
Ekaterina Dimitrova created CASSANDRA-17768: --- Summary: streaming_keep_alive_period is not used after [CASSANDRA-16927] CEP-10 Phase 1: Refactor Streaming Key: CASSANDRA-17768 URL: https://issues.apache.org/jira/browse/CASSANDRA-17768 Project: Cassandra Issue Type: Bug Reporter: Ekaterina Dimitrova While working on another ticket I noticed that after [CASSANDRA-16927] CEP-10 Phase 1: Refactor Streaming streaming_keep_alive_period is not used anymore, except to print it in error message [here|https://github.com/apache/cassandra/blob/cassandra-4.1/src/java/org/apache/cassandra/streaming/StreamSession.java#L689] If the property should not be used anymore, we need to deprecate it and fix the error message as it is misleading. [~benedict] , [~samt] , [~tuxslayer] , can you, please, check and take care of this one as authors of that patch? Thank you in advance! -- This message was sent by Atlassian Jira (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-17761) WEBSITE - July 2022 blog "Apache Cassandra 4.1 Features: Pluggable Memtable Implementations"
[ https://issues.apache.org/jira/browse/CASSANDRA-17761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17569723#comment-17569723 ] Diogenese Topper commented on CASSANDRA-17761: -- Text reviewed, translated to .adoc format - need someone for final check in staging and commit. > WEBSITE - July 2022 blog "Apache Cassandra 4.1 Features: Pluggable Memtable > Implementations" > > > Key: CASSANDRA-17761 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17761 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Diogenese Topper >Priority: Normal > Labels: pull-request-available > Fix For: 4.1.x > > > This ticket is to capture the work associated with publishing the July 2022 > blog "Apache Cassandra 4.1 Features: Pluggable Memtable Implementations" > If this blog cannot be published by the *July 21, 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-17761) WEBSITE - July 2022 blog "Apache Cassandra 4.1 Features: Pluggable Memtable Implementations"
[ https://issues.apache.org/jira/browse/CASSANDRA-17761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Diogenese Topper updated CASSANDRA-17761: - Authors: Branimir Lambov, Branimir Lambov Test and Documentation Plan: * Add blog post titled "Apache Cassandra 4.1 Features: Pluggable Memtable Implementations" * Modify blog index page Add images for blog: "Apache-Cassandra-4.1-Features-Pluggable-Memtable-Implementations-graph.png" and "Apache-Cassandra-4.1-Features-Pluggable-Memtable-Implementations-unsplash-neven-krcmarek.jpg" Status: Patch Available (was: Open) https://github.com/apache/cassandra-website/pull/155 > WEBSITE - July 2022 blog "Apache Cassandra 4.1 Features: Pluggable Memtable > Implementations" > > > Key: CASSANDRA-17761 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17761 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Diogenese Topper >Priority: Normal > Labels: pull-request-available > Fix For: 4.1.x > > > This ticket is to capture the work associated with publishing the July 2022 > blog "Apache Cassandra 4.1 Features: Pluggable Memtable Implementations" > If this blog cannot be published by the *July 21, 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-17761) WEBSITE - July 2022 blog "Apache Cassandra 4.1 Features: Pluggable Memtable Implementations"
[ https://issues.apache.org/jira/browse/CASSANDRA-17761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CASSANDRA-17761: --- Labels: pull-request-available (was: ) > WEBSITE - July 2022 blog "Apache Cassandra 4.1 Features: Pluggable Memtable > Implementations" > > > Key: CASSANDRA-17761 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17761 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Diogenese Topper >Priority: Normal > Labels: pull-request-available > Fix For: 4.1.x > > > This ticket is to capture the work associated with publishing the July 2022 > blog "Apache Cassandra 4.1 Features: Pluggable Memtable Implementations" > If this blog cannot be published by the *July 21, 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-13979) update contributing guidelines
[ https://issues.apache.org/jira/browse/CASSANDRA-13979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Haddad updated CASSANDRA-13979: --- Resolution: Fixed Status: Resolved (was: Open) > update contributing guidelines > -- > > Key: CASSANDRA-13979 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13979 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Documentation and Website >Reporter: Jon Haddad >Assignee: Lorina Poland >Priority: Normal > Labels: lhf > > Current contributing guidelines point to the more or less dead wiki, we > should point to the website docs. -- This message was sent by Atlassian Jira (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-15372) Add Jon Haddad's GPG key to KEYS file
[ https://issues.apache.org/jira/browse/CASSANDRA-15372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Haddad updated CASSANDRA-15372: --- Resolution: Fixed Status: Resolved (was: Open) > Add Jon Haddad's GPG key to KEYS file > - > > Key: CASSANDRA-15372 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15372 > Project: Cassandra > Issue Type: Task > Components: Packaging >Reporter: Jon Haddad >Assignee: Jon Haddad >Priority: Normal > > Following up CASSANDRA-15360 and the mailing list discussion, I'll add my GPG > key to the keys file. > References: > - [https://www.apache.org/dev/release-signing#keys-policy] > - [http://www.apache.org/legal/release-policy.html] > - [dev ML thread "Improving our frequency of (patch) releases, and letting > committers make > releases"|https://lists.apache.org/thread.html/660ed8c73e7b79afa610f3e45f37914ef43a4358a85a99c8b4b0288a@%3Cdev.cassandra.apache.org%3E] -- This message was sent by Atlassian Jira (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-15093) update hardware recommendations
[ https://issues.apache.org/jira/browse/CASSANDRA-15093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Haddad updated CASSANDRA-15093: --- Resolution: Fixed Status: Resolved (was: Triage Needed) > update hardware recommendations > --- > > Key: CASSANDRA-15093 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15093 > Project: Cassandra > Issue Type: Improvement > Components: Documentation/Website >Reporter: Jon Haddad >Assignee: Lorina Poland >Priority: Normal > > The recommendations on > http://cassandra.apache.org/doc/latest/operating/hardware.html are pretty out > of date. We should improve the following: > * GC recommendations. We (The Last Pickle) routinely use 16GB heaps with > 8-10GB of new gen, Survivor ratio of 4-6 and max tenuring threshold of 6. It > works far better than G1GC > * The instance sizes in AWS are pretty outdated. M1s are years out of date. > i3's work well with NVMe disks, EBS works OK if you want easy backups and > replacements. -- This message was sent by Atlassian Jira (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-17314) Test Failure: org.apache.cassandra.db.ScrubTest.testScrubCorruptedCounterRow
[
https://issues.apache.org/jira/browse/CASSANDRA-17314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17569720#comment-17569720
]
Runtian Liu commented on CASSANDRA-17314:
-
I think this is only broken in 3.0. The fix is mostly borrowed from 3.11/4.0
code. The bug in 3.0 is that when throwing error
[here|https://github.com/apache/cassandra/pull/1707/files#diff-34814e77850d8cdcae4e28d7edb14ae7a3052c2e28101ca7c347687fc427670aR122],
the checksum is not reset. We need to reset checksum every time we try to
compare. 3.11 and 4.0 has the function to calculate the checksum. Also, we need
to clear the buffer to make sure the reader doesn't see stale data. 4.0 has
similar code
[here|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/io/util/CompressedChunkReader.java#L165].
> Test Failure: org.apache.cassandra.db.ScrubTest.testScrubCorruptedCounterRow
>
>
> Key: CASSANDRA-17314
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17314
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Josh McKenzie
>Assignee: Runtian Liu
>Priority: Normal
> Fix For: 3.0.x
>
>
> Failed 10 times in the last 14 runs. Flakiness: 61%, Stability: 28%
> Error Message
> Timeout occurred. Please note the time in the report does not reflect the
> time until the timeout.
> {code}
> Stacktrace
> junit.framework.AssertionFailedError: Timeout occurred. Please note the time
> in the report does not reflect the time until the timeout.
> at java.util.Vector.forEach(Vector.java:1277)
> at java.util.Vector.forEach(Vector.java:1277)
> at java.util.Vector.forEach(Vector.java:1277)
> at jdk.nashorn.internal.scripts.Script$3$\^eval\_.:program(:13)
> at
> jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:637)
> at
> jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:494)
> at
> jdk.nashorn.internal.runtime.ScriptRuntime.apply(ScriptRuntime.java:393)
> at
> jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:449)
> at
> jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:406)
> at
> jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:402)
> at
> jdk.nashorn.api.scripting.NashornScriptEngine.eval(NashornScriptEngine.java:155)
> at javax.script.AbstractScriptEngine.eval(AbstractScriptEngine.java:264)
> at java.util.Vector.forEach(Vector.java:1277)
> {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-17735) Fix issues with index_summary_resize_interval and index_summary_capacity
[ https://issues.apache.org/jira/browse/CASSANDRA-17735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17569701#comment-17569701 ] Ekaterina Dimitrova commented on CASSANDRA-17735: - Thanks [~adelapena] , I just rebased, applied the suggestions, updated also the changed Converter unit test and pushed to the PRs, CI running (last runs in the pipeline). I don't expect surprises from CI but let's see when it finishes, will keep an eye on it. > Fix issues with index_summary_resize_interval and index_summary_capacity > > > Key: CASSANDRA-17735 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17735 > Project: Cassandra > Issue Type: Bug > Components: Local/Config >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Low > Fix For: 4.0.x, 4.1-beta, 4.x > > > There are a few problems: > 4.0+: > * the virtual table displays only the cassandra.yaml values for both > properties, all changes after startup are not updated > 4.1+: > * Breaking compatibility - -1 was considered disabled, this should be > considered as null now for the new config. The converter should be updated. > There is a test for the -1, disable but it didn't caught the issue because of > the previous issue mentioned (the disconnect between jmx and the actual > property in Config class) -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17764) Extra writePreparedStatement call
[ https://issues.apache.org/jira/browse/CASSANDRA-17764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17569686#comment-17569686 ] Brandon Williams commented on CASSANDRA-17764: -- Whoops, [j8|https://app.circleci.com/pipelines/github/driftx/cassandra/553/workflows/30e249ec-ac2c-4186-a27c-7e76baf6b83c], [j11|https://app.circleci.com/pipelines/github/driftx/cassandra/553/workflows/8999aa80-d7a8-4356-9630-61db41fd084a] > Extra writePreparedStatement call > - > > Key: CASSANDRA-17764 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17764 > Project: Cassandra > Issue Type: Bug > Components: Local/Caching >Reporter: T Jake Luciani >Assignee: Brandon Williams >Priority: Normal > Fix For: 4.0.x, 4.1-rc, 4.x > > > There seems to be a double insert happening in > QueryProcessor.storePreparedStatement() > > [https://github.com/apache/cassandra/blob/ab9ab903fa590409251e97fe075e02a64c8aa4f3/src/java/org/apache/cassandra/cql3/QueryProcessor.java#L788-L791] > > I think it's intended to only write to prepared statement table when it's > new to the cache vs every prepare call. Regardless the extra one should be > dropped. -- This message was sent by Atlassian Jira (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-17764) Extra writePreparedStatement call
[ https://issues.apache.org/jira/browse/CASSANDRA-17764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17569685#comment-17569685 ] Caleb Rackliffe edited comment on CASSANDRA-17764 at 7/21/22 8:51 PM: -- +1 to all three branches, but it looks like we need a MID/HIGHRES CircleCI run for 4.1 was (Author: maedhroz): +1 to all three patches, but it looks like we need a MID/HIGHRES CircleCI run for 4.1 > Extra writePreparedStatement call > - > > Key: CASSANDRA-17764 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17764 > Project: Cassandra > Issue Type: Bug > Components: Local/Caching >Reporter: T Jake Luciani >Assignee: Brandon Williams >Priority: Normal > Fix For: 4.0.x, 4.1-rc, 4.x > > > There seems to be a double insert happening in > QueryProcessor.storePreparedStatement() > > [https://github.com/apache/cassandra/blob/ab9ab903fa590409251e97fe075e02a64c8aa4f3/src/java/org/apache/cassandra/cql3/QueryProcessor.java#L788-L791] > > I think it's intended to only write to prepared statement table when it's > new to the cache vs every prepare call. Regardless the extra one should be > dropped. -- This message was sent by Atlassian Jira (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-17764) Extra writePreparedStatement call
[ https://issues.apache.org/jira/browse/CASSANDRA-17764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17569685#comment-17569685 ] Caleb Rackliffe commented on CASSANDRA-17764: - +1 to all three patches, but it looks like we need a MID/HIGHRES CircleCI run for 4.1 > Extra writePreparedStatement call > - > > Key: CASSANDRA-17764 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17764 > Project: Cassandra > Issue Type: Bug > Components: Local/Caching >Reporter: T Jake Luciani >Assignee: Brandon Williams >Priority: Normal > Fix For: 4.0.x, 4.1-rc, 4.x > > > There seems to be a double insert happening in > QueryProcessor.storePreparedStatement() > > [https://github.com/apache/cassandra/blob/ab9ab903fa590409251e97fe075e02a64c8aa4f3/src/java/org/apache/cassandra/cql3/QueryProcessor.java#L788-L791] > > I think it's intended to only write to prepared statement table when it's > new to the cache vs every prepare call. Regardless the extra one should be > dropped. -- This message was sent by Atlassian Jira (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-17766) Add centos 7 docker/build infra
[ https://issues.apache.org/jira/browse/CASSANDRA-17766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17569675#comment-17569675 ] Brandon Williams commented on CASSANDRA-17766: -- I have a branch [here|https://github.com/driftx/cassandra-builds/tree/CASSANDRA-17766] which is enough to see that our current rpm packages won't build on centos7 due to the 'or' usage as described in CASSANDRA-17765. Centos7 doesn't have ant >= 1.10 so is immediately blocked by CASSANDRA-17428, so that is manually installed in the docker image. > Add centos 7 docker/build infra > --- > > Key: CASSANDRA-17766 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17766 > Project: Cassandra > Issue Type: New Feature > Components: CI >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > > For CASSANDRA-17765 we will need CI for centos 7 packages, but also we should > support it over (now deprecated) centos 8, because it is supported until 2024 > (because centos is weird.) -- This message was sent by Atlassian Jira (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-17767) Add guardrail to disallow DROP KEYSPACE commands for non superuser accounts
[ https://issues.apache.org/jira/browse/CASSANDRA-17767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh McKenzie updated CASSANDRA-17767: -- Test and Documentation Plan: New unit tests Status: Patch Available (was: Open) > Add guardrail to disallow DROP KEYSPACE commands for non superuser accounts > --- > > Key: CASSANDRA-17767 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17767 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Guardrails >Reporter: Josh McKenzie >Assignee: Josh McKenzie >Priority: Normal > > Similar to CASSANDRA-17558, we should have the ability to ban DROP KEYSPACE > commands cluster-wide for non superuser accounts. > The goal as with blocking DROP/TRUNCATE TABLE is to help prevent users from > inadvertently throwing away data and providing a cleaner way for operators to > just disable this cluster-wide than role management / runbook / etc. -- This message was sent by Atlassian Jira (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-17767) Add guardrail to disallow DROP KEYSPACE commands for non superuser accounts
[ https://issues.apache.org/jira/browse/CASSANDRA-17767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17569671#comment-17569671 ] Josh McKenzie commented on CASSANDRA-17767: --- ||Item|Link|| ||PR|[Link|https://github.com/apache/cassandra/pull/1740]| ||JDK8 CI|[Link|https://app.circleci.com/pipelines/github/josh-mckenzie/cassandra/242/workflows/456fdc77-c2e7-4e2c-92db-a73adef9cc92]| ||JDK11 CI|[Link|https://app.circleci.com/pipelines/github/josh-mckenzie/cassandra/242/workflows/a767f637-3d3a-4080-be26-74ad5c14184f]| > Add guardrail to disallow DROP KEYSPACE commands for non superuser accounts > --- > > Key: CASSANDRA-17767 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17767 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Guardrails >Reporter: Josh McKenzie >Assignee: Josh McKenzie >Priority: Normal > > Similar to CASSANDRA-17558, we should have the ability to ban DROP KEYSPACE > commands cluster-wide for non superuser accounts. > The goal as with blocking DROP/TRUNCATE TABLE is to help prevent users from > inadvertently throwing away data and providing a cleaner way for operators to > just disable this cluster-wide than role management / runbook / etc. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-staging updated (ee9d6d2f -> 21cc0a70)
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 ee9d6d2f generate docs for ea0e75d5 new 21cc0a70 generate docs for ea0e75d5 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 (ee9d6d2f) \ N -- N -- N refs/heads/asf-staging (21cc0a70) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: site-ui/build/ui-bundle.zip | Bin 4740078 -> 4740078 bytes 1 file changed, 0 insertions(+), 0 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17764) Extra writePreparedStatement call
[ https://issues.apache.org/jira/browse/CASSANDRA-17764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17569522#comment-17569522 ] Brandon Williams edited comment on CASSANDRA-17764 at 7/21/22 7:16 PM: --- ||Branch||Circle|| |[4.0|https://github.com/driftx/cassandra/tree/CASSANDRA-17764-4.0]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/552/workflows/f36a189e-eadb-4dab-8185-fa1f09388446], [j11|https://app.circleci.com/pipelines/github/driftx/cassandra/552/workflows/4093179e-f232-4429-a0ff-9932fdf6ea82]| |[4.1|https://github.com/driftx/cassandra/tree/CASSANDRA-17764-4.1]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/549/workflows/ce1cf2d8-7e8e-4cbe-b533-ffe96ebe29bb], [J11|https://app.circleci.com/pipelines/github/driftx/cassandra/549/workflows/8b3af374-12b2-48a4-a9ab-18916a3b071c]| |[trunk|https://github.com/driftx/cassandra/tree/CASSANDRA-17764-trunk]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/551/workflows/ba8cadb9-025f-46f9-b663-69d9e956d30d], [j11|https://app.circleci.com/pipelines/github/driftx/cassandra/551/workflows/353e45a9-0c64-4871-9cb4-245a8279e031]| was (Author: brandon.williams): ||Branch||Circle|| |[4.0|https://github.com/driftx/cassandra/tree/CASSANDRA-17764-4.0]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/550/workflows/c56eb4a7-e393-41c9-a9b8-5aff61e3d69c], [j11|https://app.circleci.com/pipelines/github/driftx/cassandra/550/workflows/c94a50d1-751b-432b-bcbb-83e23c586ff0]| |[4.1|https://github.com/driftx/cassandra/tree/CASSANDRA-17764-4.1]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/549/workflows/ce1cf2d8-7e8e-4cbe-b533-ffe96ebe29bb], [J11|https://app.circleci.com/pipelines/github/driftx/cassandra/549/workflows/8b3af374-12b2-48a4-a9ab-18916a3b071c]| |[trunk|https://github.com/driftx/cassandra/tree/CASSANDRA-17764-trunk]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/551/workflows/ba8cadb9-025f-46f9-b663-69d9e956d30d], [j11|https://app.circleci.com/pipelines/github/driftx/cassandra/551/workflows/353e45a9-0c64-4871-9cb4-245a8279e031]| > Extra writePreparedStatement call > - > > Key: CASSANDRA-17764 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17764 > Project: Cassandra > Issue Type: Bug > Components: Local/Caching >Reporter: T Jake Luciani >Assignee: Brandon Williams >Priority: Normal > Fix For: 4.0.x, 4.1-rc, 4.x > > > There seems to be a double insert happening in > QueryProcessor.storePreparedStatement() > > [https://github.com/apache/cassandra/blob/ab9ab903fa590409251e97fe075e02a64c8aa4f3/src/java/org/apache/cassandra/cql3/QueryProcessor.java#L788-L791] > > I think it's intended to only write to prepared statement table when it's > new to the cache vs every prepare call. Regardless the extra one should be > dropped. -- This message was sent by Atlassian Jira (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-17767) Add guardrail to disallow DROP KEYSPACE commands for non superuser accounts
[ https://issues.apache.org/jira/browse/CASSANDRA-17767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh McKenzie updated CASSANDRA-17767: -- Change Category: Operability Complexity: Normal Status: Open (was: Triage Needed) > Add guardrail to disallow DROP KEYSPACE commands for non superuser accounts > --- > > Key: CASSANDRA-17767 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17767 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Guardrails >Reporter: Josh McKenzie >Assignee: Josh McKenzie >Priority: Normal > > Similar to CASSANDRA-17558, we should have the ability to ban DROP KEYSPACE > commands cluster-wide for non superuser accounts. > The goal as with blocking DROP/TRUNCATE TABLE is to help prevent users from > inadvertently throwing away data and providing a cleaner way for operators to > just disable this cluster-wide than role management / runbook / etc. -- This message was sent by Atlassian Jira (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-17767) Add guardrail to disallow DROP KEYSPACE commands for non superuser accounts
Josh McKenzie created CASSANDRA-17767: - Summary: Add guardrail to disallow DROP KEYSPACE commands for non superuser accounts Key: CASSANDRA-17767 URL: https://issues.apache.org/jira/browse/CASSANDRA-17767 Project: Cassandra Issue Type: New Feature Components: Feature/Guardrails Reporter: Josh McKenzie Assignee: Josh McKenzie Similar to CASSANDRA-17558, we should have the ability to ban DROP KEYSPACE commands cluster-wide for non superuser accounts. The goal as with blocking DROP/TRUNCATE TABLE is to help prevent users from inadvertently throwing away data and providing a cleaner way for operators to just disable this cluster-wide than role management / runbook / etc. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRASC-40) Fix search in list snapshot endpoint
[
https://issues.apache.org/jira/browse/CASSANDRASC-40?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francisco Guerrero updated CASSANDRASC-40:
--
Status: Needs Committer (was: Review In Progress)
> Fix search in list snapshot endpoint
>
>
> Key: CASSANDRASC-40
> URL: https://issues.apache.org/jira/browse/CASSANDRASC-40
> Project: Sidecar for Apache Cassandra
> Issue Type: Bug
> Components: Rest API
>Reporter: Francisco Guerrero
>Assignee: Francisco Guerrero
>Priority: Normal
> Labels: pull-request-available
>
> The test setup in {{SnapshotUtils}} is incorrect. Because of the incorrect
> test setup
> the execution is providing incorrect results. For example, assume the
> following path
> {{/cassandra-test/data/ks/tbl/snapshots/test-snapshot}}
> The test is configuring data directories as {{["/cassandra-test/data"]}}, but
> in a real
> execution data directories are provided as {{["/cassandra-test"]}}. This is
> causing the
> endpoint to return incorrect values in the JSON payload.
> Additionally, the response is providing the port for Cassandra and not the
> Sidecar
> port.
--
This message was sent by Atlassian Jira
(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-17764) Extra writePreparedStatement call
[ https://issues.apache.org/jira/browse/CASSANDRA-17764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Rackliffe updated CASSANDRA-17764: Reviewers: Caleb Rackliffe, Caleb Rackliffe Caleb Rackliffe, Caleb Rackliffe (was: Caleb Rackliffe) Status: Review In Progress (was: Patch Available) > Extra writePreparedStatement call > - > > Key: CASSANDRA-17764 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17764 > Project: Cassandra > Issue Type: Bug > Components: Local/Caching >Reporter: T Jake Luciani >Assignee: Brandon Williams >Priority: Normal > Fix For: 4.0.x, 4.1-rc, 4.x > > > There seems to be a double insert happening in > QueryProcessor.storePreparedStatement() > > [https://github.com/apache/cassandra/blob/ab9ab903fa590409251e97fe075e02a64c8aa4f3/src/java/org/apache/cassandra/cql3/QueryProcessor.java#L788-L791] > > I think it's intended to only write to prepared statement table when it's > new to the cache vs every prepare call. Regardless the extra one should be > dropped. -- This message was sent by Atlassian Jira (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-17718) CEP-15: (Accord) Transaction Invalidation
[ https://issues.apache.org/jira/browse/CASSANDRA-17718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CASSANDRA-17718: --- Labels: pull-request-available (was: ) > CEP-15: (Accord) Transaction Invalidation > - > > Key: CASSANDRA-17718 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17718 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: Benedict Elliott Smith >Assignee: Benedict Elliott Smith >Priority: Normal > Labels: pull-request-available > > In order to ensure progress, and to support partial replication of > transactions, we must be able to decide that a transaction is a no-op. -- This message was sent by Atlassian Jira (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-17575) forceCompactionForTokenRange when using a wrapped range may include sstables not within that range
[
https://issues.apache.org/jira/browse/CASSANDRA-17575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17569529#comment-17569529
]
Andres de la Peña edited comment on CASSANDRA-17575 at 7/21/22 5:05 PM:
{quote}if you change to do (32, 31] you see that compaction included a
partition it shouldn't have; we include partition 32 even though the range
filters out that partition. This ticket should figure out why we include the
wrong partition and attempt to fix it so we stop
{quote}
I think that
[{{wrappingRange}}|https://github.com/apache/cassandra/blob/cassandra-4.1/test/unit/org/apache/cassandra/db/compaction/LeveledCompactionStrategyTest.java#L503-L511]
in that test actually is {{(32, 31]}} without changing it. I understand that
[the asserted
value|https://github.com/apache/cassandra/blob/cassandra-4.1/test/unit/org/apache/cassandra/db/compaction/LeveledCompactionStrategyTest.java#L520-L521]
should be 11 instead of 1, because we don't compact the ten {{[32, 32]}}
sstables, but only the the ten {{[31,32]}} and the ten {{[31, 31]}} sstables.
So 20 sstables compacted into one single sstable, plus 10 uncompacted sstables,
makes 11 sstables. Is that right?
Probably the issue is on
[{{CompactionManger#sstablesInBounds}}|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/compaction/CompactionManager.java#L991],
where it passes token ranges that exclude the start bound to
[{{View.sstablesInBounds}}|https://github.com/apache/cassandra/blob/e4e19e33faf9ac7cf27a9779c8083a7f5c5b865a/src/java/org/apache/cassandra/db/lifecycle/View.java#L181-L185],
which includes both bounds.
Also, what token range should we use to compact a single token?
[Here|https://github.com/apache/cassandra/blob/cassandra-4.1/test/unit/org/apache/cassandra/db/compaction/LeveledCompactionStrategyTest.java#L446-L447]
the test uses {{{}(32, 32]{}}}, although for the comment it seems that the
intention in the past was to use {{{}(31, 32]){}}}.
was (Author: adelapena):
{quote}if you change to do (32, 31] you see that compaction included a
partition it shouldn't have; we include partition 32 even though the range
filters out that partition. This ticket should figure out why we include the
wrong partition and attempt to fix it so we stop
{quote}
I think that
[{{wrappingRange}}|https://github.com/apache/cassandra/blob/cassandra-4.1/test/unit/org/apache/cassandra/db/compaction/LeveledCompactionStrategyTest.java#L503-L511]
in that test actually is {{(32, 31]}} without changing it. I understand that
[the asserted
value|https://github.com/apache/cassandra/blob/cassandra-4.1/test/unit/org/apache/cassandra/db/compaction/LeveledCompactionStrategyTest.java#L520-L521]
should be 11 instead of 1, because we don't compact the ten {{[32, 32]}}
sstables, but only the the ten {{[31,32]}} and the ten {{[31, 31]}} sstables.
So 20 sstables compacted into one single sstable, plus 10 uncompacted sstables,
makes 11 sstables. Is that right?
Probably the issue is on
[{{CompactionManger#sstablesInBounds}}|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/compaction/CompactionManager.java#L991],
where it passes token ranges that exclude the start bound to
[{{View.sstablesInBounds}}|https://github.com/apache/cassandra/blob/e4e19e33faf9ac7cf27a9779c8083a7f5c5b865a/src/java/org/apache/cassandra/db/lifecycle/View.java#L181-L185],
which includes both bounds.
Also, what token range should we use to compact a single token?
[Here|https://github.com/apache/cassandra/blob/cassandra-4.1/test/unit/org/apache/cassandra/db/compaction/LeveledCompactionStrategyTest.java#L446-L447]
the tests uses {{(32, 32]}}, although for the comment it seems that the
intention in the past was to use {{(31, 32])}}.
> forceCompactionForTokenRange when using a wrapped range may include sstables
> not within that range
> --
>
> Key: CASSANDRA-17575
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17575
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Compaction
>Reporter: David Capwell
>Priority: Normal
> Fix For: 4.1-beta, 4.1.x
>
>
> This was found in CASSANDRA-17537
> When you compact the range (32, 31] this should include everything BUT 32,
> but in the test
> org.apache.cassandra.db.compaction.LeveledCompactionStrategyTest#testTokenRangeCompaction
> it found that SSTables with the bounds (32, 32) were getting included in the
> set of SSTables to compact
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail:
[jira] [Comment Edited] (CASSANDRA-17575) forceCompactionForTokenRange when using a wrapped range may include sstables not within that range
[
https://issues.apache.org/jira/browse/CASSANDRA-17575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17569529#comment-17569529
]
Andres de la Peña edited comment on CASSANDRA-17575 at 7/21/22 5:04 PM:
{quote}if you change to do (32, 31] you see that compaction included a
partition it shouldn't have; we include partition 32 even though the range
filters out that partition. This ticket should figure out why we include the
wrong partition and attempt to fix it so we stop
{quote}
I think that
[{{wrappingRange}}|https://github.com/apache/cassandra/blob/cassandra-4.1/test/unit/org/apache/cassandra/db/compaction/LeveledCompactionStrategyTest.java#L503-L511]
in that test actually is {{(32, 31]}} without changing it. I understand that
[the asserted
value|https://github.com/apache/cassandra/blob/cassandra-4.1/test/unit/org/apache/cassandra/db/compaction/LeveledCompactionStrategyTest.java#L520-L521]
should be 11 instead of 1, because we don't compact the ten {{[32, 32]}}
sstables, but only the the ten {{[31,32]}} and the ten {{[31, 31]}} sstables.
So 20 sstables compacted into one single sstable, plus 10 uncompacted sstables,
makes 11 sstables. Is that right?
Probably the issue is on
[{{CompactionManger#sstablesInBounds}}|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/compaction/CompactionManager.java#L991],
where it passes token ranges that exclude the start bound to
[{{View.sstablesInBounds}}|https://github.com/apache/cassandra/blob/e4e19e33faf9ac7cf27a9779c8083a7f5c5b865a/src/java/org/apache/cassandra/db/lifecycle/View.java#L181-L185],
which includes both bounds.
Also, what token range should we use to compact a single token?
[Here|https://github.com/apache/cassandra/blob/cassandra-4.1/test/unit/org/apache/cassandra/db/compaction/LeveledCompactionStrategyTest.java#L446-L447]
the tests uses {{(32, 32]}}, although for the comment it seems that the
intention in the past was to use {{(31, 32])}}.
was (Author: adelapena):
{quote}if you change to do (32, 31] you see that compaction included a
partition it shouldn't have; we include partition 32 even though the range
filters out that partition. This ticket should figure out why we include the
wrong partition and attempt to fix it so we stop
{quote}
I think that
[{{wrappingRange}}|https://github.com/apache/cassandra/blob/cassandra-4.1/test/unit/org/apache/cassandra/db/compaction/LeveledCompactionStrategyTest.java#L503-L511]
in that test actually is {{(32, 31]}} without changing it. I understand that
[the asserted
value|https://github.com/apache/cassandra/blob/cassandra-4.1/test/unit/org/apache/cassandra/db/compaction/LeveledCompactionStrategyTest.java#L520-L521]
should be 11 instead of 1, because we don't compact the ten {{[32, 32]}}
sstables, but only the the ten {{[31,32]}} and the ten {{[31, 31]}} sstables,
is that right?
Probably the issue is on
[{{CompactionManger#sstablesInBounds}}|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/compaction/CompactionManager.java#L991],
where it passes token ranges that exclude the start bound to
[{{View.sstablesInBounds}}|https://github.com/apache/cassandra/blob/e4e19e33faf9ac7cf27a9779c8083a7f5c5b865a/src/java/org/apache/cassandra/db/lifecycle/View.java#L181-L185],
which includes both bounds.
> forceCompactionForTokenRange when using a wrapped range may include sstables
> not within that range
> --
>
> Key: CASSANDRA-17575
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17575
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Compaction
>Reporter: David Capwell
>Priority: Normal
> Fix For: 4.1-beta, 4.1.x
>
>
> This was found in CASSANDRA-17537
> When you compact the range (32, 31] this should include everything BUT 32,
> but in the test
> org.apache.cassandra.db.compaction.LeveledCompactionStrategyTest#testTokenRangeCompaction
> it found that SSTables with the bounds (32, 32) were getting included in the
> set of SSTables to compact
--
This message was sent by Atlassian Jira
(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-13851) Allow existing nodes to use all peers in shadow round
[ https://issues.apache.org/jira/browse/CASSANDRA-13851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17569535#comment-17569535 ] Brandon Williams commented on CASSANDRA-13851: -- Please open a ticket for that to be added to the documentation. > Allow existing nodes to use all peers in shadow round > - > > Key: CASSANDRA-13851 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13851 > Project: Cassandra > Issue Type: Bug > Components: Local/Startup and Shutdown >Reporter: Kurt Greaves >Assignee: Kurt Greaves >Priority: Normal > Fix For: 3.11.3, 4.0-alpha1, 4.0 > > > In CASSANDRA-10134 we made collision checks necessary on every startup. A > side-effect was introduced that then requires a nodes seeds to be contacted > on every startup. Prior to this change an existing node could start up > regardless whether it could contact a seed node or not (because > checkForEndpointCollision() was only called for bootstrapping nodes). > Now if a nodes seeds are removed/deleted/fail it will no longer be able to > start up until live seeds are configured (or itself is made a seed), even > though it already knows about the rest of the ring. This is inconvenient for > operators and has the potential to cause some nasty surprises and increase > downtime. > One solution would be to use all a nodes existing peers as seeds in the > shadow round. Not a Gossip guru though so not sure of implications. -- This message was sent by Atlassian Jira (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-17575) forceCompactionForTokenRange when using a wrapped range may include sstables not within that range
[
https://issues.apache.org/jira/browse/CASSANDRA-17575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17569529#comment-17569529
]
Andres de la Peña commented on CASSANDRA-17575:
---
{quote}if you change to do (32, 31] you see that compaction included a
partition it shouldn't have; we include partition 32 even though the range
filters out that partition. This ticket should figure out why we include the
wrong partition and attempt to fix it so we stop
{quote}
I think that
[{{wrappingRange}}|https://github.com/apache/cassandra/blob/cassandra-4.1/test/unit/org/apache/cassandra/db/compaction/LeveledCompactionStrategyTest.java#L503-L511]
in that test actually is {{(32, 31]}} without changing it. I understand that
[the asserted
value|https://github.com/apache/cassandra/blob/cassandra-4.1/test/unit/org/apache/cassandra/db/compaction/LeveledCompactionStrategyTest.java#L520-L521]
should be 11 instead of 1, because we don't compact the ten {{[32, 32]}}
sstables, but only the the ten {{[31,32]}} and the ten {{[31, 31]}} sstables,
is that right?
Probably the issue is on
[{{CompactionManger#sstablesInBounds}}|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/compaction/CompactionManager.java#L991],
where it passes token ranges that exclude the start bound to
[{{View.sstablesInBounds}}|https://github.com/apache/cassandra/blob/e4e19e33faf9ac7cf27a9779c8083a7f5c5b865a/src/java/org/apache/cassandra/db/lifecycle/View.java#L181-L185],
which includes both bounds.
> forceCompactionForTokenRange when using a wrapped range may include sstables
> not within that range
> --
>
> Key: CASSANDRA-17575
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17575
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Compaction
>Reporter: David Capwell
>Priority: Normal
> Fix For: 4.1-beta, 4.1.x
>
>
> This was found in CASSANDRA-17537
> When you compact the range (32, 31] this should include everything BUT 32,
> but in the test
> org.apache.cassandra.db.compaction.LeveledCompactionStrategyTest#testTokenRangeCompaction
> it found that SSTables with the bounds (32, 32) were getting included in the
> set of SSTables to compact
--
This message was sent by Atlassian Jira
(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-17766) Add centos 7 docker/build infra
[ https://issues.apache.org/jira/browse/CASSANDRA-17766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams reassigned CASSANDRA-17766: Assignee: Brandon Williams > Add centos 7 docker/build infra > --- > > Key: CASSANDRA-17766 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17766 > Project: Cassandra > Issue Type: New Feature >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > > For CASSANDRA-17765 we will need CI for centos 7 packages, but also we should > support it over (now deprecated) centos 8, because it is supported until 2024 > (because centos is weird.) -- This message was sent by Atlassian Jira (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-17766) Add centos 7 docker/build infra
[ https://issues.apache.org/jira/browse/CASSANDRA-17766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-17766: - Change Category: Quality Assurance Complexity: Normal Component/s: CI Status: Open (was: Triage Needed) > Add centos 7 docker/build infra > --- > > Key: CASSANDRA-17766 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17766 > Project: Cassandra > Issue Type: New Feature > Components: CI >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > > For CASSANDRA-17765 we will need CI for centos 7 packages, but also we should > support it over (now deprecated) centos 8, because it is supported until 2024 > (because centos is weird.) -- This message was sent by Atlassian Jira (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-17764) Extra writePreparedStatement call
[ https://issues.apache.org/jira/browse/CASSANDRA-17764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-17764: - Test and Documentation Plan: run CI Status: Patch Available (was: Open) > Extra writePreparedStatement call > - > > Key: CASSANDRA-17764 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17764 > Project: Cassandra > Issue Type: Bug > Components: Local/Caching >Reporter: T Jake Luciani >Assignee: Brandon Williams >Priority: Normal > Fix For: 4.0.x, 4.1-rc, 4.x > > > There seems to be a double insert happening in > QueryProcessor.storePreparedStatement() > > [https://github.com/apache/cassandra/blob/ab9ab903fa590409251e97fe075e02a64c8aa4f3/src/java/org/apache/cassandra/cql3/QueryProcessor.java#L788-L791] > > I think it's intended to only write to prepared statement table when it's > new to the cache vs every prepare call. Regardless the extra one should be > dropped. -- This message was sent by Atlassian Jira (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-17764) Extra writePreparedStatement call
[ https://issues.apache.org/jira/browse/CASSANDRA-17764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams reassigned CASSANDRA-17764: Assignee: Brandon Williams > Extra writePreparedStatement call > - > > Key: CASSANDRA-17764 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17764 > Project: Cassandra > Issue Type: Bug > Components: Local/Caching >Reporter: T Jake Luciani >Assignee: Brandon Williams >Priority: Normal > Fix For: 4.0.x, 4.1-rc, 4.x > > > There seems to be a double insert happening in > QueryProcessor.storePreparedStatement() > > [https://github.com/apache/cassandra/blob/ab9ab903fa590409251e97fe075e02a64c8aa4f3/src/java/org/apache/cassandra/cql3/QueryProcessor.java#L788-L791] > > I think it's intended to only write to prepared statement table when it's > new to the cache vs every prepare call. Regardless the extra one should be > dropped. -- This message was sent by Atlassian Jira (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-17764) Extra writePreparedStatement call
[ https://issues.apache.org/jira/browse/CASSANDRA-17764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17569522#comment-17569522 ] Brandon Williams edited comment on CASSANDRA-17764 at 7/21/22 4:38 PM: --- ||Branch||Circle|| |[4.0|https://github.com/driftx/cassandra/tree/CASSANDRA-17764-4.0]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/550/workflows/c56eb4a7-e393-41c9-a9b8-5aff61e3d69c], [j11|https://app.circleci.com/pipelines/github/driftx/cassandra/550/workflows/c94a50d1-751b-432b-bcbb-83e23c586ff0]| |[4.1|https://github.com/driftx/cassandra/tree/CASSANDRA-17764-4.1]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/549/workflows/ce1cf2d8-7e8e-4cbe-b533-ffe96ebe29bb], [J11|https://app.circleci.com/pipelines/github/driftx/cassandra/549/workflows/8b3af374-12b2-48a4-a9ab-18916a3b071c]| |[trunk|https://github.com/driftx/cassandra/tree/CASSANDRA-17764-trunk]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/551/workflows/ba8cadb9-025f-46f9-b663-69d9e956d30d], [j11|https://app.circleci.com/pipelines/github/driftx/cassandra/551/workflows/353e45a9-0c64-4871-9cb4-245a8279e031]| was (Author: brandon.williams): ||Branch||Circle|| |[4.0|https://github.com/driftx/cassandra/tree/CASSANDRA-17764-4.0]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/550/workflows/c56eb4a7-e393-41c9-a9b8-5aff61e3d69c], [j11|https://app.circleci.com/pipelines/github/driftx/cassandra/550/workflows/c94a50d1-751b-432b-bcbb-83e23c586ff0]| |[4.1|https://github.com/driftx/cassandra/tree/CASSANDRA-17764-4.1]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/549/workflows/ce1cf2d8-7e8e-4cbe-b533-ffe96ebe29bb], [J11|https://app.circleci.com/pipelines/github/driftx/cassandra/549/workflows/8b3af374-12b2-48a4-a9ab-18916a3b071c]| [trunk|https://github.com/driftx/cassandra/tree/CASSANDRA-17764-trunk]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/551/workflows/ba8cadb9-025f-46f9-b663-69d9e956d30d], [j11|https://app.circleci.com/pipelines/github/driftx/cassandra/551/workflows/353e45a9-0c64-4871-9cb4-245a8279e031]| > Extra writePreparedStatement call > - > > Key: CASSANDRA-17764 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17764 > Project: Cassandra > Issue Type: Bug > Components: Local/Caching >Reporter: T Jake Luciani >Priority: Normal > Fix For: 4.0.x, 4.1-rc, 4.x > > > There seems to be a double insert happening in > QueryProcessor.storePreparedStatement() > > [https://github.com/apache/cassandra/blob/ab9ab903fa590409251e97fe075e02a64c8aa4f3/src/java/org/apache/cassandra/cql3/QueryProcessor.java#L788-L791] > > I think it's intended to only write to prepared statement table when it's > new to the cache vs every prepare call. Regardless the extra one should be > dropped. -- This message was sent by Atlassian Jira (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-17764) Extra writePreparedStatement call
[ https://issues.apache.org/jira/browse/CASSANDRA-17764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17569522#comment-17569522 ] Brandon Williams commented on CASSANDRA-17764: -- ||Branch||Circle|| |[4.0|https://github.com/driftx/cassandra/tree/CASSANDRA-17764-4.0]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/550/workflows/c56eb4a7-e393-41c9-a9b8-5aff61e3d69c], [j11|https://app.circleci.com/pipelines/github/driftx/cassandra/550/workflows/c94a50d1-751b-432b-bcbb-83e23c586ff0]| |[4.1|https://github.com/driftx/cassandra/tree/CASSANDRA-17764-4.1]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/549/workflows/ce1cf2d8-7e8e-4cbe-b533-ffe96ebe29bb], [J11|https://app.circleci.com/pipelines/github/driftx/cassandra/549/workflows/8b3af374-12b2-48a4-a9ab-18916a3b071c]| [trunk|https://github.com/driftx/cassandra/tree/CASSANDRA-17764-trunk]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/551/workflows/ba8cadb9-025f-46f9-b663-69d9e956d30d], [j11|https://app.circleci.com/pipelines/github/driftx/cassandra/551/workflows/353e45a9-0c64-4871-9cb4-245a8279e031]| > Extra writePreparedStatement call > - > > Key: CASSANDRA-17764 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17764 > Project: Cassandra > Issue Type: Bug > Components: Local/Caching >Reporter: T Jake Luciani >Priority: Normal > Fix For: 4.0.x, 4.1-rc, 4.x > > > There seems to be a double insert happening in > QueryProcessor.storePreparedStatement() > > [https://github.com/apache/cassandra/blob/ab9ab903fa590409251e97fe075e02a64c8aa4f3/src/java/org/apache/cassandra/cql3/QueryProcessor.java#L788-L791] > > I think it's intended to only write to prepared statement table when it's > new to the cache vs every prepare call. Regardless the extra one should be > dropped. -- This message was sent by Atlassian Jira (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-13851) Allow existing nodes to use all peers in shadow round
[ https://issues.apache.org/jira/browse/CASSANDRA-13851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17569515#comment-17569515 ] Daniel Cranford commented on CASSANDRA-13851: - This is still an *undocumented* regression in the definition of a "seed" node. A node *will not start* unless it can contact at least one seed node which is a detail that still hasn't made it into the [documentation|https://cassandra.apache.org/doc/latest/cassandra/faq/index.html#what-are-seeds] > Allow existing nodes to use all peers in shadow round > - > > Key: CASSANDRA-13851 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13851 > Project: Cassandra > Issue Type: Bug > Components: Local/Startup and Shutdown >Reporter: Kurt Greaves >Assignee: Kurt Greaves >Priority: Normal > Fix For: 3.11.3, 4.0-alpha1, 4.0 > > > In CASSANDRA-10134 we made collision checks necessary on every startup. A > side-effect was introduced that then requires a nodes seeds to be contacted > on every startup. Prior to this change an existing node could start up > regardless whether it could contact a seed node or not (because > checkForEndpointCollision() was only called for bootstrapping nodes). > Now if a nodes seeds are removed/deleted/fail it will no longer be able to > start up until live seeds are configured (or itself is made a seed), even > though it already knows about the rest of the ring. This is inconvenient for > operators and has the potential to cause some nasty surprises and increase > downtime. > One solution would be to use all a nodes existing peers as seeds in the > shadow round. Not a Gossip guru though so not sure of implications. -- This message was sent by Atlassian Jira (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-17766) Add centos 7 docker/build infra
Brandon Williams created CASSANDRA-17766: Summary: Add centos 7 docker/build infra Key: CASSANDRA-17766 URL: https://issues.apache.org/jira/browse/CASSANDRA-17766 Project: Cassandra Issue Type: New Feature Reporter: Brandon Williams For CASSANDRA-17765 we will need CI for centos 7 packages, but also we should support it over (now deprecated) centos 8, because it is supported until 2024 (because centos is weird.) -- This message was sent by Atlassian Jira (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-17765) RPM Installation on centos 7 is broken by CASSANDRA-17669
[ https://issues.apache.org/jira/browse/CASSANDRA-17765?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-17765: - Bug Category: Parent values: Packaging(13660)Level 1 values: Package Distribution(13662) Complexity: Normal Discovered By: User Report Fix Version/s: 4.0.x 4.1-rc 4.x Severity: Normal Assignee: Brandon Williams Status: Open (was: Triage Needed) > RPM Installation on centos 7 is broken by CASSANDRA-17669 > - > > Key: CASSANDRA-17765 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17765 > Project: Cassandra > Issue Type: Bug > Components: Packaging >Reporter: Jeremiah Jordan >Assignee: Brandon Williams >Priority: Normal > Fix For: 4.0.x, 4.1-rc, 4.x > > > With CASSANDRA-17669 adding use of "or" in the dependencies for the RPM so it > can depend on java 8 or java 11 it broke installation on CentOS Linux 7. > This is bad because CentOS Linux 7 is the "current" release of CentOS Linux, > version 8 was EOL'ed in favor of the new pre-release distribution model being > used for CentOS Stream 8. > I don't know what the best answer is here, maybe making a CentOS 7 specific > package that reverts back to just java 8 in the requirements? But I think > should needs to be done. -- This message was sent by Atlassian Jira (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-17765) RPM Installation on centos 7 is broken by CASSANDRA-17669
Jeremiah Jordan created CASSANDRA-17765: --- Summary: RPM Installation on centos 7 is broken by CASSANDRA-17669 Key: CASSANDRA-17765 URL: https://issues.apache.org/jira/browse/CASSANDRA-17765 Project: Cassandra Issue Type: Bug Components: Packaging Reporter: Jeremiah Jordan With CASSANDRA-17669 adding use of "or" in the dependencies for the RPM so it can depend on java 8 or java 11 it broke installation on CentOS Linux 7. This is bad because CentOS Linux 7 is the "current" release of CentOS Linux, version 8 was EOL'ed in favor of the new pre-release distribution model being used for CentOS Stream 8. I don't know what the best answer is here, maybe making a CentOS 7 specific package that reverts back to just java 8 in the requirements? But I think should needs to be done. -- This message was sent by Atlassian Jira (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-17764) Extra writePreparedStatement call
[ https://issues.apache.org/jira/browse/CASSANDRA-17764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-17764: - Fix Version/s: 4.0.x > Extra writePreparedStatement call > - > > Key: CASSANDRA-17764 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17764 > Project: Cassandra > Issue Type: Bug > Components: Local/Caching >Reporter: T Jake Luciani >Priority: Normal > Fix For: 4.0.x, 4.1-rc, 4.x > > > There seems to be a double insert happening in > QueryProcessor.storePreparedStatement() > > [https://github.com/apache/cassandra/blob/ab9ab903fa590409251e97fe075e02a64c8aa4f3/src/java/org/apache/cassandra/cql3/QueryProcessor.java#L788-L791] > > I think it's intended to only write to prepared statement table when it's > new to the cache vs every prepare call. Regardless the extra one should be > dropped. -- This message was sent by Atlassian Jira (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-17764) Extra writePreparedStatement call
[ https://issues.apache.org/jira/browse/CASSANDRA-17764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-17764: - Bug Category: Parent values: Correctness(12982) Complexity: Low Hanging Fruit Discovered By: User Report Fix Version/s: 4.1-rc 4.x Severity: Normal Status: Open (was: Triage Needed) > Extra writePreparedStatement call > - > > Key: CASSANDRA-17764 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17764 > Project: Cassandra > Issue Type: Bug > Components: Local/Caching >Reporter: T Jake Luciani >Priority: Normal > Fix For: 4.1-rc, 4.x > > > There seems to be a double insert happening in > QueryProcessor.storePreparedStatement() > > [https://github.com/apache/cassandra/blob/ab9ab903fa590409251e97fe075e02a64c8aa4f3/src/java/org/apache/cassandra/cql3/QueryProcessor.java#L788-L791] > > I think it's intended to only write to prepared statement table when it's > new to the cache vs every prepare call. Regardless the extra one should be > dropped. -- This message was sent by Atlassian Jira (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-17764) Extra writePreparedStatement call
[ https://issues.apache.org/jira/browse/CASSANDRA-17764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] T Jake Luciani updated CASSANDRA-17764: --- Impacts: (was: None) > Extra writePreparedStatement call > - > > Key: CASSANDRA-17764 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17764 > Project: Cassandra > Issue Type: Bug > Components: Local/Caching >Reporter: T Jake Luciani >Priority: Normal > > There seems to be a double insert happening in > QueryProcessor.storePreparedStatement() > > [https://github.com/apache/cassandra/blob/ab9ab903fa590409251e97fe075e02a64c8aa4f3/src/java/org/apache/cassandra/cql3/QueryProcessor.java#L788-L791] > > I think it's intended to only write to prepared statement when its new to the > cache vs every prepare call. Regardless the extra one should be dropped. -- This message was sent by Atlassian Jira (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-17764) Extra writePreparedStatement call
[ https://issues.apache.org/jira/browse/CASSANDRA-17764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] T Jake Luciani updated CASSANDRA-17764: --- Description: There seems to be a double insert happening in QueryProcessor.storePreparedStatement() [https://github.com/apache/cassandra/blob/ab9ab903fa590409251e97fe075e02a64c8aa4f3/src/java/org/apache/cassandra/cql3/QueryProcessor.java#L788-L791] I think it's intended to only write to prepared statement table when it's new to the cache vs every prepare call. Regardless the extra one should be dropped. was: There seems to be a double insert happening in QueryProcessor.storePreparedStatement() [https://github.com/apache/cassandra/blob/ab9ab903fa590409251e97fe075e02a64c8aa4f3/src/java/org/apache/cassandra/cql3/QueryProcessor.java#L788-L791] I think it's intended to only write to prepared statement when its new to the cache vs every prepare call. Regardless the extra one should be dropped. > Extra writePreparedStatement call > - > > Key: CASSANDRA-17764 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17764 > Project: Cassandra > Issue Type: Bug > Components: Local/Caching >Reporter: T Jake Luciani >Priority: Normal > > There seems to be a double insert happening in > QueryProcessor.storePreparedStatement() > > [https://github.com/apache/cassandra/blob/ab9ab903fa590409251e97fe075e02a64c8aa4f3/src/java/org/apache/cassandra/cql3/QueryProcessor.java#L788-L791] > > I think it's intended to only write to prepared statement table when it's > new to the cache vs every prepare call. Regardless the extra one should be > dropped. -- This message was sent by Atlassian Jira (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-17764) Extra writePreparedStatement call
T Jake Luciani created CASSANDRA-17764: -- Summary: Extra writePreparedStatement call Key: CASSANDRA-17764 URL: https://issues.apache.org/jira/browse/CASSANDRA-17764 Project: Cassandra Issue Type: Bug Components: Local/Caching Reporter: T Jake Luciani There seems to be a double insert happening in QueryProcessor.storePreparedStatement() [https://github.com/apache/cassandra/blob/ab9ab903fa590409251e97fe075e02a64c8aa4f3/src/java/org/apache/cassandra/cql3/QueryProcessor.java#L788-L791] I think it's intended to only write to prepared statement when its new to the cache vs every prepare call. Regardless the extra one should be dropped. -- This message was sent by Atlassian Jira (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-17736) Settings Virtual Table should display the values assigned to a property in the DatabaseDescriptor on startup and not null (as per the yaml)
[ https://issues.apache.org/jira/browse/CASSANDRA-17736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17569470#comment-17569470 ] Ekaterina Dimitrova commented on CASSANDRA-17736: - I was talking to others today and I realized I didn't leave anything about testing. I think the best way forward will be to ensure any jmx methods tests are also updating properly the respective property in Config. Some JMX methods already have tests, for others we will have to add more. I think this is what will add more to this patch probably. Maybe another way to approach this is checking per MBean properties of interest? On one side I hope we will move fully to virtual tables, but on the other one 4.0 needs to have this working properly... > Settings Virtual Table should display the values assigned to a property in > the DatabaseDescriptor on startup and not null (as per the yaml) > --- > > Key: CASSANDRA-17736 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17736 > Project: Cassandra > Issue Type: Bug > Components: Local/Config >Reporter: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.0.x, 4.1.x, 4.x > > > There are a few properties that after startup do not show their assigned > values as per the DatabaseDescriptor assignment but the cassandra.yaml value. > They will not be also updated in the virtual table down the road in case they > are updated through JMX, nodetool etc. > EDIT: This ticket should serve to check the properties that are not type > Duration, Data Storage and Data Rate; also that are not new to 4.1. I will > post a list of who are those later today for convenience. We target all those > in Config class (some advanced properties are not broadly advertised in > cassandra.yaml intentionally). > There is [Settings Virtual Table > |https://cassandra.apache.org/doc/trunk/cassandra/new/virtualtables.html#settings-virtual-table] > which is supposed to show the values for our config parameters at any time. > Especially useful if any property was changed after startup through > JMX/nodetool and it doesn't match anymore the value in cassandra.yaml. For > this to be possible, we need to ensure that the parameters are always updated > in the Config class. It was observed that some are not always updating in > Config class, but after startup delegating to other internal variables. This > is a bug and this task should review and address any new findings. > Classes of interest - > [SettingsTable|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/virtual/SettingsTable.java] > where you can see how config parameters are listed; > [Config|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/config/Config.java] > class where our configuration parameters are defined. > We need patches 4.0 and above. I suggest you start looking into 4.0 branch > and then merge into higher branches. As you won't be checking the data > storage, data rate and duration type parameters, there shouldn't be many > conflicts on merge. > We have a lot of parameters and I suggest you split the list into batches to > check and produce patches where/if needed to make the work more incremental > and easier to work on and review it. > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17753) Include GitSHA in nodetool version output
[ https://issues.apache.org/jira/browse/CASSANDRA-17753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17569458#comment-17569458 ] Brandon Williams commented on CASSANDRA-17753: -- Can we detect if there is no .git and quiet the output a bit? > Include GitSHA in nodetool version output > - > > Key: CASSANDRA-17753 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17753 > Project: Cassandra > Issue Type: New Feature > Components: Tool/nodetool >Reporter: Abe Ratnofsky >Assignee: Abe Ratnofsky >Priority: Normal > Fix For: 4.x > > Time Spent: 1h 50m > Remaining Estimate: 0h > > It can be useful to see specifically which Git SHA a running instance of > Cassandra was built with, especially when running clusters in development for > soak testing. > > I have a patch ready for this, and am preparing it now. -- This message was sent by Atlassian Jira (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-17658) Test Failures: org.apache.cassandra.metrics.KeyspaceMetricsTest.testMetricsCleanupOnDrop
[
https://issues.apache.org/jira/browse/CASSANDRA-17658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17569433#comment-17569433
]
Ekaterina Dimitrova commented on CASSANDRA-17658:
-
Hey [~jlewandowski] , did you try your commit rights? I don't think you will
get any notification or anything, they are just assigned pretty quickly
normally after you are told you are a committer already. Please let us know if
you need any help.
> Test Failures:
> org.apache.cassandra.metrics.KeyspaceMetricsTest.testMetricsCleanupOnDrop
>
>
> Key: CASSANDRA-17658
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17658
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Andres de la Peña
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 4.1-beta, 4.1.x, 4.x
>
>
> The test
> {{org.apache.cassandra.metrics.KeyspaceMetricsTest.testMetricsCleanupOnDrop}}
> seems to be flaky on CircleCI, although I haven't seen it failing on Jenkins.
> It was first detected during CASSANDRA-17509, on [this
> run|https://app.circleci.com/pipelines/github/josh-mckenzie/cassandra/211/workflows/2cbb5465-a970-440b-a502-06e380ce6851/jobs/1977/tests]:
> {code}
> junit.framework.AssertionFailedError:
>
[jira] [Comment Edited] (CASSANDRA-17753) Include GitSHA in nodetool version output
[ https://issues.apache.org/jira/browse/CASSANDRA-17753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17569423#comment-17569423 ] Michael Semb Wever edited comment on CASSANDRA-17753 at 7/21/22 1:54 PM: - I'm good with the PR, and was about to commit, but on some final testing I have another question to raise… If we build the source when it's not a git clone, for example one of our officially voted on release tarballs, the build output gets quick noisy… ``` get-git-sha: [exec] fatal: not a git repository (or any of the parent directories): .git [exec] Result: 128 [echo] git.sha= [exec] warning: Not a git repository. Use --no-index to compare two paths outside a working tree [exec] usage: git diff --no-index [] [exec] [exec] Diff output format options [exec] -p, --patch generate patch [exec] -s, --no-patchsuppress diff output [exec] -ugenerate patch [exec] -U, --unified[=] generate diffs with lines context [exec] -W, --function-context [exec] generate diffs with lines context [exec] --raw generate the diff in raw format [exec] --patch-with-raw synonym for '-p --raw' [exec] --patch-with-stat synonym for '-p --stat' [exec] --numstat machine friendly --stat [exec] --shortstat output only the last line of --stat [exec] -X, --dirstat[=...] [exec] output the distribution of relative amount of changes for each sub-directory [exec] --cumulative synonym for --dirstat=cumulative [exec] --dirstat-by-file[=...] [exec] synonym for --dirstat=files,param1,param2... [exec] --check warn if changes introduce conflict markers or whitespace errors [exec] --summary condensed summary such as creations, renames and mode changes [exec] --name-only show only names of changed files [exec] --name-status show only names and status of changed files [exec] --stat[=[,[,]]] [exec] generate diffstat [exec] --stat-width generate diffstat with a given width [exec] --stat-name-width [exec] generate diffstat with a given name width [exec] --stat-graph-width [exec] generate diffstat with a given graph width [exec] --stat-count generate diffstat with limited lines [exec] --compact-summary generate compact summary in diffstat [exec] --binary output a binary diff that can be applied [exec] --full-index show full pre- and post-image object names on the "index" lines [exec] --color[=] show colored diff [exec] --ws-error-highlight [exec] highlight whitespace errors in the 'context', 'old' or 'new' lines in the diff [exec] -zdo not munge pathnames and use NULs as output field terminators in --raw or --numstat [exec] --abbrev[=]use digits to display object names [exec] --src-prefix [exec] show the given source prefix instead of "a/" [exec] --dst-prefix [exec] show the given destination prefix instead of "b/" [exec] --line-prefix [exec] prepend an additional prefix to every line of output [exec] --no-prefix do not show any source or destination prefix [exec] --inter-hunk-context [exec] show context between diff hunks up to the specified number of lines [exec] --output-indicator-new [exec] specify the character to indicate a new line instead of '+' [exec] --output-indicator-old [exec] specify the character to indicate an old line instead of '-' [exec] --output-indicator-context [exec] specify the character to indicate a context instead of ' ' [exec] [exec] Diff rename options [exec] -B, --break-rewrites[=[/]] [exec] break complete rewrite changes into pairs of delete and create [exec] -M, --find-renames[=] [exec] detect renames [exec] -D, --irreversible-delete [exec] omit the preimage for deletes [exec] -C, --find-copies[=] [exec] detect copies [exec] --find-copies-harder use unmodified files as source to find copies [exec]
[jira] [Comment Edited] (CASSANDRA-17753) Include GitSHA in nodetool version output
[ https://issues.apache.org/jira/browse/CASSANDRA-17753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17569423#comment-17569423 ] Michael Semb Wever edited comment on CASSANDRA-17753 at 7/21/22 1:53 PM: - I'm good with the PR, and was about to commit, but on some final testing I have another question to raise… If we build the source when it's not a git clone, for example one of our officially voted on release tarballs, the build output gets quick noisy… ``` get-git-sha: [exec] fatal: not a git repository (or any of the parent directories): .git [exec] Result: 128 [echo] git.sha= [exec] warning: Not a git repository. Use --no-index to compare two paths outside a working tree [exec] usage: git diff --no-index [] [exec] [exec] Diff output format options [exec] -p, --patch generate patch [exec] -s, --no-patchsuppress diff output [exec] -ugenerate patch [exec] -U, --unified[=] generate diffs with lines context [exec] -W, --function-context [exec] generate diffs with lines context [exec] --raw generate the diff in raw format [exec] --patch-with-raw synonym for '-p --raw' [exec] --patch-with-stat synonym for '-p --stat' [exec] --numstat machine friendly --stat [exec] --shortstat output only the last line of --stat [exec] -X, --dirstat[=...] [exec] output the distribution of relative amount of changes for each sub-directory [exec] --cumulative synonym for --dirstat=cumulative [exec] --dirstat-by-file[=...] [exec] synonym for --dirstat=files,param1,param2... [exec] --check warn if changes introduce conflict markers or whitespace errors [exec] --summary condensed summary such as creations, renames and mode changes [exec] --name-only show only names of changed files [exec] --name-status show only names and status of changed files [exec] --stat[=[,[,]]] [exec] generate diffstat [exec] --stat-width generate diffstat with a given width [exec] --stat-name-width [exec] generate diffstat with a given name width [exec] --stat-graph-width [exec] generate diffstat with a given graph width [exec] --stat-count generate diffstat with limited lines [exec] --compact-summary generate compact summary in diffstat [exec] --binary output a binary diff that can be applied [exec] --full-index show full pre- and post-image object names on the "index" lines [exec] --color[=] show colored diff [exec] --ws-error-highlight [exec] highlight whitespace errors in the 'context', 'old' or 'new' lines in the diff [exec] -zdo not munge pathnames and use NULs as output field terminators in --raw or --numstat [exec] --abbrev[=]use digits to display object names [exec] --src-prefix [exec] show the given source prefix instead of "a/" [exec] --dst-prefix [exec] show the given destination prefix instead of "b/" [exec] --line-prefix [exec] prepend an additional prefix to every line of output [exec] --no-prefix do not show any source or destination prefix [exec] --inter-hunk-context [exec] show context between diff hunks up to the specified number of lines [exec] --output-indicator-new [exec] specify the character to indicate a new line instead of '+' [exec] --output-indicator-old [exec] specify the character to indicate an old line instead of '-' [exec] --output-indicator-context [exec] specify the character to indicate a context instead of ' ' [exec] [exec] Diff rename options [exec] -B, --break-rewrites[=[/]] [exec] break complete rewrite changes into pairs of delete and create [exec] -M, --find-renames[=] [exec] detect renames [exec] -D, --irreversible-delete [exec] omit the preimage for deletes [exec] -C, --find-copies[=] [exec] detect copies [exec] --find-copies-harder use unmodified files as source to find copies [exec]
[jira] [Commented] (CASSANDRA-17753) Include GitSHA in nodetool version output
[ https://issues.apache.org/jira/browse/CASSANDRA-17753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17569423#comment-17569423 ] Michael Semb Wever commented on CASSANDRA-17753: I'm good with the PR, and was about to commit, but on some final testing I have another question to raise… If we build the source when it's not a git clone, for example one of our officially voted on release tarballs, the build output gets quick noisy… ``` get-git-sha: [exec] fatal: not a git repository (or any of the parent directories): .git [exec] Result: 128 [echo] git.sha= [exec] warning: Not a git repository. Use --no-index to compare two paths outside a working tree [exec] usage: git diff --no-index [] [exec] [exec] Diff output format options [exec] -p, --patch generate patch [exec] -s, --no-patchsuppress diff output [exec] -ugenerate patch [exec] -U, --unified[=] generate diffs with lines context [exec] -W, --function-context [exec] generate diffs with lines context [exec] --raw generate the diff in raw format [exec] --patch-with-raw synonym for '-p --raw' [exec] --patch-with-stat synonym for '-p --stat' [exec] --numstat machine friendly --stat [exec] --shortstat output only the last line of --stat [exec] -X, --dirstat[=...] [exec] output the distribution of relative amount of changes for each sub-directory [exec] --cumulative synonym for --dirstat=cumulative [exec] --dirstat-by-file[=...] [exec] synonym for --dirstat=files,param1,param2... [exec] --check warn if changes introduce conflict markers or whitespace errors [exec] --summary condensed summary such as creations, renames and mode changes [exec] --name-only show only names of changed files [exec] --name-status show only names and status of changed files [exec] --stat[=[,[,]]] [exec] generate diffstat [exec] --stat-width generate diffstat with a given width [exec] --stat-name-width [exec] generate diffstat with a given name width [exec] --stat-graph-width [exec] generate diffstat with a given graph width [exec] --stat-count generate diffstat with limited lines [exec] --compact-summary generate compact summary in diffstat [exec] --binary output a binary diff that can be applied [exec] --full-index show full pre- and post-image object names on the "index" lines [exec] --color[=] show colored diff [exec] --ws-error-highlight [exec] highlight whitespace errors in the 'context', 'old' or 'new' lines in the diff [exec] -zdo not munge pathnames and use NULs as output field terminators in --raw or --numstat [exec] --abbrev[=]use digits to display object names [exec] --src-prefix [exec] show the given source prefix instead of "a/" [exec] --dst-prefix [exec] show the given destination prefix instead of "b/" [exec] --line-prefix [exec] prepend an additional prefix to every line of output [exec] --no-prefix do not show any source or destination prefix [exec] --inter-hunk-context [exec] show context between diff hunks up to the specified number of lines [exec] --output-indicator-new [exec] specify the character to indicate a new line instead of '+' [exec] --output-indicator-old [exec] specify the character to indicate an old line instead of '-' [exec] --output-indicator-context [exec] specify the character to indicate a context instead of ' ' [exec] [exec] Diff rename options [exec] -B, --break-rewrites[=[/]] [exec] break complete rewrite changes into pairs of delete and create [exec] -M, --find-renames[=] [exec] detect renames [exec] -D, --irreversible-delete [exec] omit the preimage for deletes [exec] -C, --find-copies[=] [exec] detect copies [exec] --find-copies-harder use unmodified files as source to find copies [exec] --no-renames disable rename detection
[jira] [Updated] (CASSANDRA-17753) Include GitSHA in nodetool version output
[ https://issues.apache.org/jira/browse/CASSANDRA-17753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-17753: --- Status: Ready to Commit (was: Review In Progress) > Include GitSHA in nodetool version output > - > > Key: CASSANDRA-17753 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17753 > Project: Cassandra > Issue Type: New Feature > Components: Tool/nodetool >Reporter: Abe Ratnofsky >Assignee: Abe Ratnofsky >Priority: Normal > Fix For: 4.x > > Time Spent: 1h 50m > Remaining Estimate: 0h > > It can be useful to see specifically which Git SHA a running instance of > Cassandra was built with, especially when running clusters in development for > soak testing. > > I have a patch ready for this, and am preparing it now. -- This message was sent by Atlassian Jira (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-8877) Ability to read the TTL and WRITE TIME of an element in a collection
[ https://issues.apache.org/jira/browse/CASSANDRA-8877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andres de la Peña updated CASSANDRA-8877: - Test and Documentation Plan: ||PR||CI|| |[trunk|https://github.com/apache/cassandra/pull/1739]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/1943/workflows/947857e9-c2a5-4ad3-9c4c-c99869dd868b] [j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/1943/workflows/2851c046-e704-4c51-a8a4-b995475530be]| Status: Patch Available (was: In Progress) > Ability to read the TTL and WRITE TIME of an element in a collection > > > Key: CASSANDRA-8877 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8877 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/CQL >Reporter: Drew Kutcharian >Assignee: Andres de la Peña >Priority: Low > Fix For: 4.x > > > Currently it's possible to set the TTL and WRITE TIME of an element in a > collection using CQL, but there is no way to read them back. -- This message was sent by Atlassian Jira (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-8877) Ability to read the TTL and WRITE TIME of an element in a collection
[
https://issues.apache.org/jira/browse/CASSANDRA-8877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17569390#comment-17569390
]
Andres de la Peña commented on CASSANDRA-8877:
--
The proposed patch provides CQL support for getting the writetime/ttl of the
cells of:
* Entire collections/UDTs
* Single collections/UDTs elements
* Slices of collection elements
||PR||CI||
|[trunk|https://github.com/apache/cassandra/pull/1739]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/1943/workflows/947857e9-c2a5-4ad3-9c4c-c99869dd868b]
[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/1943/workflows/2851c046-e704-4c51-a8a4-b995475530be]|
It is based on an old patch that I wrote some time ago with the invaluable help
of [~blerer].
Here is an example of the behaviour for frozen collections:
{code}
CREATE TABLE IF NOT EXISTS t (k int PRIMARY KEY, s frozen>);
INSERT INTO t (k, s) VALUES (1, {1, 2, 3}) USING TIMESTAMP 100 AND TTL 1;
SELECT s, WRITETIME(s), TTL(s) FROM t;
s | writetime(s) | ttl(s)
---+--+
{1, 2, 3} | 100 | 1
SELECT s[2], WRITETIME(s[2]), TTL(s[2]) FROM t;
s[2] | writetime(s[2]) | ttl(s[2])
--+-+---
2 | 100 | 1
SELECT s[4], WRITETIME(s[4]), TTL(s[4]) FROM t;
s[4] | writetime(s[4]) | ttl(s[4])
--+-+---
null |null | null
SELECT s[2..], WRITETIME(s[2..]), TTL(s[2..]) FROM t;
s[2..] | writetime(s[2..]) | ttl(s[2..])
+---+-
{2, 3} | 100 |9897
{code}
For not-frozen collections:
{code}
CREATE TABLE IF NOT EXISTS t (k int PRIMARY KEY, s set);
INSERT INTO t (k, s) VALUES (1, {1, 2}) USING TIMESTAMP 100 AND TTL 1;
UPDATE t USING TIMESTAMP 200 AND TTL 2 SET s += {3} WHERE k=1;
SELECT s, WRITETIME(s), TTL(s) FROM t;
s | writetime(s)| ttl(s)
---+-+---
{1, 2, 3} | [100, 100, 200] | [1, 1, 2]
SELECT s[2], WRITETIME(s[2]), TTL(s[2]) FROM t;
s[2] | writetime(s[2]) | ttl(s[2])
--+-+---
2 | 100 | 1
SELECT s[4], WRITETIME(s[4]), TTL(s[4]) FROM t;
s[4] | writetime(s[4]) | ttl(s[4])
--+-+---
null |null | null
SELECT s[2..], WRITETIME(s[2..]), TTL(s[2..]) FROM t;
s[2..] | writetime(s[2..]) | ttl(s[2..])
+---+
{2, 3} |[100, 200] | [1, 2]
{code}
For frozen UDTs:
{code}
CREATE TYPE udt (f1 int, f2 int, f3 int);
CREATE TABLE t (k int PRIMARY KEY, t frozen);
INSERT INTO t (k, t) VALUES (1, {f1: 1, f2: 2}) USING TIMESTAMP 100 AND TTL
1;
SELECT t, WRITETIME(t), TTL(t) FROM t;
t| writetime(t) | ttl(t)
--+--+
{f1: 1, f2: 2, f3: null} | 100 | 1
SELECT t.f1, WRITETIME(t.f1), TTL(t.f1) FROM t;
t.f1 | writetime(t.f1) | ttl(t.f1)
--+-+---
1 | 100 | 1
SELECT t.f2, WRITETIME(t.f2), TTL(t.f2) FROM t;
t.f2 | writetime(t.f2) | ttl(t.f2)
--+-+---
2 | 100 | 1
SELECT t.f3, WRITETIME(t.f3), TTL(t.f3) FROM t;
t.f3 | writetime(t.f3) | ttl(t.f3)
--+-+---
null |null | null
{code}
For not-frozen UDTs:
{code}
CREATE TYPE udt (f1 int, f2 int, f3 int);
CREATE TABLE t (k int PRIMARY KEY, t udt);
INSERT INTO t (k, t) VALUES (1, {f1: 1}) USING TIMESTAMP 100 AND TTL 1;
UPDATE t USING TIMESTAMP 200 AND TTL 2 SET t.f2 = 2 WHERE k = 1;
SELECT t, WRITETIME(t), TTL(t) FROM t;
t| writetime(t) | ttl(t)
--+--+--
{f1: 1, f2: 2, f3: null} | [100, 200, None] | [1, 2, None]
SELECT t.f1, WRITETIME(t.f1), TTL(t.f1) FROM t;
t.f1 | writetime(t.f1) | ttl(t.f1)
--+-+---
1 | 100 | 1
SELECT t.f2, WRITETIME(t.f2), TTL(t.f2) FROM t;
t.f2 | writetime(t.f2) | ttl(t.f2)
--+-+---
2 | 200 | 2
SELECT t.f3, WRITETIME(t.f3), TTL(t.f3) FROM t;
t.f3 | writetime(t.f3) | ttl(t.f3)
--+-+---
null |null | null
{code}
As for the {{MAXWRITETIME}} function added by CASSANDRA-17425, I have adapted
it so it can also used on items of a collection. It's possible to query things
like {{MAXWRITETTIME(phones[2..4])}} or {{MAXWRITETTIME(user.name)}}. However,
I think we should try to get rid of that function and instead provide generic
functions to aggregate the elements of a collection, so instead of
{{MAXWRITETTIME(phones[2..4])}} we would write something like
{{GREATEST(WRITETTIME(phones[2..4]))}}. In any
[cassandra-website] branch asf-staging updated (288387fc -> ee9d6d2f)
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 288387fc generate docs for ea0e75d5 new ee9d6d2f generate docs for ea0e75d5 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 (288387fc) \ N -- N -- N refs/heads/asf-staging (ee9d6d2f) 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/search-index.js | 2 +- site-ui/build/ui-bundle.zip | Bin 4740078 -> 4740078 bytes 2 files changed, 1 insertion(+), 1 deletion(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17763) Allow node to serve traffic only once compactions settle
[ https://issues.apache.org/jira/browse/CASSANDRA-17763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17569343#comment-17569343 ] Brandon Williams commented on CASSANDRA-17763: -- Note that we already wait for 2Is to build, so this shouldn't be too difficult. > Allow node to serve traffic only once compactions settle > > > Key: CASSANDRA-17763 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17763 > Project: Cassandra > Issue Type: New Feature > Components: Local/Compaction >Reporter: Gil Ganz >Priority: Normal > Fix For: 4.x > > > Today when nodes are joined to the cluster, once data streaming is completed, > node starts serving traffic, but it's possible there are a lot of pending > compactions, so having reads accessing sstables during that time is going to > make these reads slower and load the server. In some cases performance is so > bad it can bring the application down. > Today I overcome this by stopping native transport to a node after join > finishes, and enabling it after compactions pending reach a certain > threshold, it would be nice to have that as part of the join process, only > consider join completed once there are not that many compactions pending. -- This message was sent by Atlassian Jira (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-17763) Allow node to serve traffic only once compactions settle
[ https://issues.apache.org/jira/browse/CASSANDRA-17763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-17763: - Change Category: Performance Complexity: Normal Component/s: Local/Compaction Fix Version/s: 4.x Status: Open (was: Triage Needed) > Allow node to serve traffic only once compactions settle > > > Key: CASSANDRA-17763 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17763 > Project: Cassandra > Issue Type: New Feature > Components: Local/Compaction >Reporter: Gil Ganz >Priority: Normal > Fix For: 4.x > > > Today when nodes are joined to the cluster, once data streaming is completed, > node starts serving traffic, but it's possible there are a lot of pending > compactions, so having reads accessing sstables during that time is going to > make these reads slower and load the server. In some cases performance is so > bad it can bring the application down. > Today I overcome this by stopping native transport to a node after join > finishes, and enabling it after compactions pending reach a certain > threshold, it would be nice to have that as part of the join process, only > consider join completed once there are not that many compactions pending. -- This message was sent by Atlassian Jira (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-17753) Include GitSHA in nodetool version output
[ https://issues.apache.org/jira/browse/CASSANDRA-17753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-17753: --- Status: Review In Progress (was: Changes Suggested) > Include GitSHA in nodetool version output > - > > Key: CASSANDRA-17753 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17753 > Project: Cassandra > Issue Type: New Feature > Components: Tool/nodetool >Reporter: Abe Ratnofsky >Assignee: Abe Ratnofsky >Priority: Normal > Fix For: 4.x > > Time Spent: 1h 50m > Remaining Estimate: 0h > > It can be useful to see specifically which Git SHA a running instance of > Cassandra was built with, especially when running clusters in development for > soak testing. > > I have a patch ready for this, and am preparing it now. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-staging updated (8569ded7 -> 288387fc)
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 8569ded7 generate docs for ea0e75d5 new 288387fc generate docs for ea0e75d5 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 (8569ded7) \ N -- N -- N refs/heads/asf-staging (288387fc) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: site-ui/build/ui-bundle.zip | Bin 4740078 -> 4740078 bytes 1 file changed, 0 insertions(+), 0 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17763) Allow node to serve traffic only once compactions settle
[ https://issues.apache.org/jira/browse/CASSANDRA-17763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gil Ganz updated CASSANDRA-17763: - Summary: Allow node to serve traffic only once compactions settle (was: Allow node to serve traffic once compactions settle) > Allow node to serve traffic only once compactions settle > > > Key: CASSANDRA-17763 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17763 > Project: Cassandra > Issue Type: New Feature >Reporter: Gil Ganz >Priority: Normal > > Today when nodes are joined to the cluster, once data streaming is completed, > node starts serving traffic, but it's possible there are a lot of pending > compactions, so having reads accessing sstables during that time is going to > make these reads slower and load the server. In some cases performance is so > bad it can bring the application down. > Today I overcome this by stopping native transport to a node after join > finishes, and enabling it after compactions pending reach a certain > threshold, it would be nice to have that as part of the join process, only > consider join completed once there are not that many compactions pending. -- This message was sent by Atlassian Jira (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-17763) Allow node to serve traffic once compactions settle
Gil Ganz created CASSANDRA-17763: Summary: Allow node to serve traffic once compactions settle Key: CASSANDRA-17763 URL: https://issues.apache.org/jira/browse/CASSANDRA-17763 Project: Cassandra Issue Type: New Feature Reporter: Gil Ganz Today when nodes are joined to the cluster, once data streaming is completed, node starts serving traffic, but it's possible there are a lot of pending compactions, so having reads accessing sstables during that time is going to make these reads slower and load the server. In some cases performance is so bad it can bring the application down. Today I overcome this by stopping native transport to a node after join finishes, and enabling it after compactions pending reach a certain threshold, it would be nice to have that as part of the join process, only consider join completed once there are not that many compactions pending. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
