[jira] [Commented] (CASSANDRA-17469) Test Failure: org.apache.cassandra.db.commitlog.GroupCommitLogTest
[
https://issues.apache.org/jira/browse/CASSANDRA-17469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17525388#comment-17525388
]
Ekaterina Dimitrova commented on CASSANDRA-17469:
-
One more:
https://jenkins-cm4.apache.org/job/Cassandra-trunk/1089/testReport/junit/org.apache.cassandra.db.commitlog/BatchCommitLogTest/testOutOfOrderFlushRecoveryWithCompaction_3__compression/
> Test Failure: org.apache.cassandra.db.commitlog.GroupCommitLogTest
> --
>
> Key: CASSANDRA-17469
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17469
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Andres de la Peña
>Priority: Normal
> Fix For: 4.x
>
>
> Intermitent failures in
> {{{}org.apache.cassandra.db.commitlog.GroupCommitLogTest{}}}:
> *
> [testTruncateWithoutSnapshotNonDurable|https://ci-cassandra.apache.org/job/Cassandra-trunk/1024/testReport/org.apache.cassandra.db.commitlog/GroupCommitLogTest/testTruncateWithoutSnapshotNonDurable_4__cdc_2/]
> *
> [testRecoveryWithEmptyLog|https://ci-cassandra.apache.org/job/Cassandra-trunk/1024/testReport/org.apache.cassandra.db.commitlog/GroupCommitLogTest/testTruncateWithoutSnapshotNonDurable_4__cdc_2/]
> *
> [testOutOfOrderLogDiscardWithCompaction|https://ci-cassandra.apache.org/job/Cassandra-trunk/1024/testReport/org.apache.cassandra.db.commitlog/GroupCommitLogTest/testTruncateWithoutSnapshotNonDurable_4__cdc_2/]
> *
> [testExceedRecordLimitWithMultiplePartitions|https://ci-cassandra.apache.org/job/Cassandra-trunk/1024/testReport/org.apache.cassandra.db.commitlog/GroupCommitLogTest/testExceedRecordLimitWithMultiplePartitions_5__cdc_2/]
> *
> [testRecoveryWithShortMutationSize|https://ci-cassandra.apache.org/job/Cassandra-trunk/1024/testReport/org.apache.cassandra.db.commitlog/GroupCommitLogTest/testRecoveryWithShortMutationSize_4__cdc_2/]
> {code:java}
> Failed 2 times in the last 11 runs. Flakiness: 30%, Stability: 81%
> Stacktrace
> java.io.UncheckedIOException
> at
> org.apache.cassandra.io.util.PathUtils.propagateUnchecked(PathUtils.java:768)
> at
> org.apache.cassandra.io.util.PathUtils.propagateUnchecked(PathUtils.java:753)
> at org.apache.cassandra.io.util.PathUtils.delete(PathUtils.java:255)
> at org.apache.cassandra.io.util.PathUtils.delete(PathUtils.java:297)
> at org.apache.cassandra.io.util.PathUtils.delete(PathUtils.java:304)
> at org.apache.cassandra.io.util.File.delete(File.java:158)
> at org.apache.cassandra.io.util.File.delete(File.java:167)
> at
> org.apache.cassandra.db.commitlog.CommitLogSegmentManagerCDC.discard(CommitLogSegmentManagerCDC.java:75)
> at
> org.apache.cassandra.db.commitlog.AbstractCommitLogSegmentManager.closeAndDeleteSegmentUnsafe(AbstractCommitLogSegmentManager.java:479)
> at
> org.apache.cassandra.db.commitlog.AbstractCommitLogSegmentManager.stopUnsafe(AbstractCommitLogSegmentManager.java:452)
> at
> org.apache.cassandra.db.commitlog.CommitLog.stopUnsafe(CommitLog.java:504)
> at
> org.apache.cassandra.db.commitlog.CommitLog.resetUnsafe(CommitLog.java:470)
> at
> org.apache.cassandra.db.commitlog.CommitLogTest.beforeTest(CommitLogTest.java:184)
> at jdk.internal.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> Caused by: java.nio.file.NoSuchFileException:
> build/test/cassandra/commitlog/CommitLog-7-1647704321215.log
> at
> java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:92)
> at
> java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:111)
> at
> java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:116)
> at
> java.base/sun.nio.fs.UnixFileSystemProvider.implDelete(UnixFileSystemProvider.java:249)
> at
> java.base/sun.nio.fs.AbstractFileSystemProvider.delete(AbstractFileSystemProvider.java:105)
> at java.base/java.nio.file.Files.delete(Files.java:1142)
> at org.apache.cassandra.io.util.PathUtils.delete(PathUtils.java:250)
> Standard Output
> DEBUG [main] 2022-03-19 15:41:04,702 InternalLoggerFactory.java:63 - Using
> SLF4J as the default logging framework
> DEBUG [main] 2022-03-19 15:41:04,712 InternalThreadLocalMap.java:83 -
> -Dio.netty.threadLocalMap.stringBuilder.initialSize: 1024
> DEBUG [main] 2022-03-19 15:41:04,712 InternalThreadLocalMap.java:86 -
> -Dio.netty.threadLocalMap.stringBuilder.maxSize: 4096
> INFO [main] 2022-03-19 15:41:04,713 CipherFactory.java:68 - initializing
> CipherFactory
> INFO [main] 2022-03-19 15:41:04,713 JKSKeyPro
> ...[truncated 1879728 chars]...
> tLog-7-1647704466908.log
> INFO [main]
[jira] [Created] (CASSANDRA-17569) DOC - tools/nodetool is untitled and might be affecting search results
Erick Ramirez created CASSANDRA-17569:
-
Summary: DOC - tools/nodetool is untitled and might be affecting
search results
Key: CASSANDRA-17569
URL: https://issues.apache.org/jira/browse/CASSANDRA-17569
Project: Cassandra
Issue Type: Task
Reporter: Erick Ramirez
Assignee: Erick Ramirez
Reported by [~mck] in [ASF Slack
#cassandra-website|https://the-asf.slack.com/archives/C01RY1LUPD5/p1650446747714449]:
{quote}I see that the nodetool doc pages have the title {{Untitled | …}} ( i
think this impacting search results){quote}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17555) WEBSITE - April 2022 blog "Inside Cassandra: An Interview with Project Contributor, Aleksandr Sorokoumov"
[
https://issues.apache.org/jira/browse/CASSANDRA-17555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17525377#comment-17525377
]
Erick Ramirez commented on CASSANDRA-17555:
---
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 924e389d generate docs for 8fd077a6
$ 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
+ 7c8e43e0...924e389d asf-site -> asf-site (forced update){noformat}
The post is now live in production –
https://cassandra.apache.org/_/blog/Inside-Cassandra-an-interview-with-Project-Contributor-Aleksandr-Sorokoumov.html
> WEBSITE - April 2022 blog "Inside Cassandra: An Interview with Project
> Contributor, Aleksandr Sorokoumov"
> -
>
> Key: CASSANDRA-17555
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17555
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Blog
>Reporter: Diogenese Topper
>Assignee: Erick Ramirez
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.0.3
>
> Attachments: c17555-01-blog-index.png, c17555-02-blog-post.png
>
>
> This ticket is to capture the work associated with publishing the April 2022
> blog "Inside Cassandra: An Interview with Project Contributor, Aleksandr
> Sorokoumov"
> If this blog cannot be published by the *April 14, 2022 publish date*, please
> contact me, suggest changes, or correct the date when possible in the pull
> request for the appropriate time that the blog will go live (on both the
> blog.adoc and the blog post's file).
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
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 (7c8e43e0 -> 924e389d)
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 7c8e43e0 generate docs for b7ad0c5f
add 8fd077a6 BLOG - Inside Cassandra: Interview with Aleksandr Sorokoumov
add 924e389d generate docs for 8fd077a6
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 (7c8e43e0)
\
N -- N -- N refs/heads/asf-site (924e389d)
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:
.../blog/inside-Cassandra-Aleksandr-Sorokoumov.png | Bin 0 -> 405151 bytes
content/_/blog.html| 24 +
...-Project-Contributor-Aleksandr-Sorokoumov.html} | 53 --
.../cassandra/configuration/cass_yaml_file.html| 52 +-
content/doc/4.1/cassandra/new/configuration.html | 30 +++
.../doc/4.1/cassandra/tools/cassandra_stress.html | 4 --
.../cassandra/configuration/cass_yaml_file.html| 52 +-
.../doc/latest/cassandra/new/configuration.html| 30 +++
.../latest/cassandra/tools/cassandra_stress.html | 4 --
.../cassandra/configuration/cass_yaml_file.html| 52 +-
content/doc/trunk/cassandra/new/configuration.html | 30 +++
.../trunk/cassandra/tools/cassandra_stress.html| 4 --
content/search-index.js| 2 +-
.../blog/inside-Cassandra-Aleksandr-Sorokoumov.png | Bin 0 -> 405151 bytes
site-content/source/modules/ROOT/pages/blog.adoc | 25 +
...h-Project-Contributor-Aleksandr-Sorokoumov.adoc | 59 +
site-ui/build/ui-bundle.zip| Bin 4740078 -> 4740078
bytes
17 files changed, 324 insertions(+), 97 deletions(-)
create mode 100644
content/_/_images/blog/inside-Cassandra-Aleksandr-Sorokoumov.png
copy
content/_/blog/{Inside-Cassandra-an-interview-with-Project-Contributor-Lorina-Poland.html
=>
Inside-Cassandra-an-interview-with-Project-Contributor-Aleksandr-Sorokoumov.html}
(66%)
create mode 100644
site-content/source/modules/ROOT/images/blog/inside-Cassandra-Aleksandr-Sorokoumov.png
create mode 100644
site-content/source/modules/ROOT/pages/blog/Inside-Cassandra-an-interview-with-Project-Contributor-Aleksandr-Sorokoumov.adoc
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17555) WEBSITE - April 2022 blog "Inside Cassandra: An Interview with Project Contributor, Aleksandr Sorokoumov"
[ https://issues.apache.org/jira/browse/CASSANDRA-17555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17525354#comment-17525354 ] Erick Ramirez edited comment on CASSANDRA-17555 at 4/21/22 1:53 AM: Made some minor formatting changes. Ready to commit. !c17555-01-blog-index.png|width=400! !c17555-02-blog-post.png|width=400! was (Author: JIRAUSER285101): Made some minor formatting changes. Ready to commit. > WEBSITE - April 2022 blog "Inside Cassandra: An Interview with Project > Contributor, Aleksandr Sorokoumov" > - > > Key: CASSANDRA-17555 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17555 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Diogenese Topper >Assignee: Erick Ramirez >Priority: Normal > Labels: pull-request-available > Fix For: 4.0.3 > > Attachments: c17555-01-blog-index.png, c17555-02-blog-post.png > > > This ticket is to capture the work associated with publishing the April 2022 > blog "Inside Cassandra: An Interview with Project Contributor, Aleksandr > Sorokoumov" > If this blog cannot be published by the *April 14, 2022 publish date*, please > contact me, suggest changes, or correct the date when possible in the pull > request for the appropriate time that the blog will go live (on both the > blog.adoc and the blog post's file). -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17555) WEBSITE - April 2022 blog "Inside Cassandra: An Interview with Project Contributor, Aleksandr Sorokoumov"
[ https://issues.apache.org/jira/browse/CASSANDRA-17555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17525375#comment-17525375 ] Erick Ramirez commented on CASSANDRA-17555: --- The build completed and is live in staging – https://cassandra.staged.apache.org/_/blog/Inside-Cassandra-an-interview-with-Project-Contributor-Aleksandr-Sorokoumov.html > WEBSITE - April 2022 blog "Inside Cassandra: An Interview with Project > Contributor, Aleksandr Sorokoumov" > - > > Key: CASSANDRA-17555 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17555 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Diogenese Topper >Assignee: Erick Ramirez >Priority: Normal > Labels: pull-request-available > Fix For: 4.0.3 > > Attachments: c17555-01-blog-index.png, c17555-02-blog-post.png > > > This ticket is to capture the work associated with publishing the April 2022 > blog "Inside Cassandra: An Interview with Project Contributor, Aleksandr > Sorokoumov" > If this blog cannot be published by the *April 14, 2022 publish date*, please > contact me, suggest changes, or correct the date when possible in the pull > request for the appropriate time that the blog will go live (on both the > blog.adoc and the blog post's file). -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15254) Allow UPDATE on settings virtual table to change running configurations
[
https://issues.apache.org/jira/browse/CASSANDRA-15254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17525371#comment-17525371
]
David Capwell commented on CASSANDRA-15254:
---
FYI I am trying to get CASSANDRA-17166 in before the freeze, I know you are
busy but if you do have the time it would be good to look at least the
SettingsTable changes; one open issue I do not address is
{code}
prop.set(config, fromStringtoString(prop.get(config)))
{code}
I figured this patch could deal with it. The core issue is for types where
toString doesn't return something that can be parsed (such as setting
hinted_handoff_disabled_datacenters (uses collections)), so we need to change
the table's output values to be something which can be parsed
> Allow UPDATE on settings virtual table to change running configurations
> ---
>
> Key: CASSANDRA-15254
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15254
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Virtual Tables
>Reporter: Chris Lohfink
>Assignee: Benjamin Lerer
>Priority: Normal
>
> Allow using UPDATE on the system_views.settings virtual table to update
> configs at runtime for the equivalent of the dispersed JMX
> attributes/operations.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17166) Enhance SnakeYAML properties to be reusable outside of YAML parsing, support camel case conversion to snake case, and add support to ignore properties
[ https://issues.apache.org/jira/browse/CASSANDRA-17166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17525369#comment-17525369 ] David Capwell commented on CASSANDRA-17166: --- now that [~e.dimitrova] patch is in, I rebased and did the type change logic (taking advantage of diff). I also went through to make sure I replied or fixed all feedback [~maedhroz], [~smiklosovic], [~e.dimitrova], [~jjordan] would you mind taking a look? > Enhance SnakeYAML properties to be reusable outside of YAML parsing, support > camel case conversion to snake case, and add support to ignore properties > -- > > Key: CASSANDRA-17166 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17166 > Project: Cassandra > Issue Type: Improvement > Components: Local/Config >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 4.x > > Time Spent: 15h > Remaining Estimate: 0h > > SnakeYaml is rather limited in the “object mapping” layer, which forces our > internal code to match specific patterns (all fields public and camel case); > we can remove this restriction by leveraging Jackson for property lookup, and > leaving the YAML handling to SnakeYAML -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17555) WEBSITE - April 2022 blog "Inside Cassandra: An Interview with Project Contributor, Aleksandr Sorokoumov"
[
https://issues.apache.org/jira/browse/CASSANDRA-17555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17525360#comment-17525360
]
Erick Ramirez commented on CASSANDRA-17555:
---
||Branch||PR||Commit||Build||
|{{trunk}}|[#124|https://github.com/apache/cassandra-website/pull/124]|[8fd077a|https://github.com/apache/cassandra-website/commit/8fd077a60165d991ce75cbde2726688a90d38ad0]|[#182|https://ci-cassandra.apache.org/job/cassandra-website/182/]|
> WEBSITE - April 2022 blog "Inside Cassandra: An Interview with Project
> Contributor, Aleksandr Sorokoumov"
> -
>
> Key: CASSANDRA-17555
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17555
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Blog
>Reporter: Diogenese Topper
>Assignee: Erick Ramirez
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.0.3
>
> Attachments: c17555-01-blog-index.png, c17555-02-blog-post.png
>
>
> This ticket is to capture the work associated with publishing the April 2022
> blog "Inside Cassandra: An Interview with Project Contributor, Aleksandr
> Sorokoumov"
> If this blog cannot be published by the *April 14, 2022 publish date*, please
> contact me, suggest changes, or correct the date when possible in the pull
> request for the appropriate time that the blog will go live (on both the
> blog.adoc and the blog post's file).
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
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 (148922ea -> 924e389d)
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 148922ea generate docs for b7ad0c5f
add 8fd077a6 BLOG - Inside Cassandra: Interview with Aleksandr Sorokoumov
new 924e389d generate docs for 8fd077a6
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 (148922ea)
\
N -- N -- N refs/heads/asf-staging (924e389d)
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:
.../blog/inside-Cassandra-Aleksandr-Sorokoumov.png | Bin 0 -> 405151 bytes
content/_/blog.html| 24 +
...-Project-Contributor-Aleksandr-Sorokoumov.html} | 53 --
content/search-index.js| 2 +-
.../blog/inside-Cassandra-Aleksandr-Sorokoumov.png | Bin 0 -> 405151 bytes
site-content/source/modules/ROOT/pages/blog.adoc | 25 +
...h-Project-Contributor-Aleksandr-Sorokoumov.adoc | 59 +
site-ui/build/ui-bundle.zip| Bin 4740078 -> 4740078
bytes
8 files changed, 147 insertions(+), 16 deletions(-)
create mode 100644
content/_/_images/blog/inside-Cassandra-Aleksandr-Sorokoumov.png
copy
content/_/blog/{Inside-Cassandra-an-interview-with-Project-Contributor-Lorina-Poland.html
=>
Inside-Cassandra-an-interview-with-Project-Contributor-Aleksandr-Sorokoumov.html}
(66%)
create mode 100644
site-content/source/modules/ROOT/images/blog/inside-Cassandra-Aleksandr-Sorokoumov.png
create mode 100644
site-content/source/modules/ROOT/pages/blog/Inside-Cassandra-an-interview-with-Project-Contributor-Aleksandr-Sorokoumov.adoc
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17555) WEBSITE - April 2022 blog "Inside Cassandra: An Interview with Project Contributor, Aleksandr Sorokoumov"
[ https://issues.apache.org/jira/browse/CASSANDRA-17555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Ramirez updated CASSANDRA-17555: -- Attachment: c17555-02-blog-post.png c17555-01-blog-index.png > WEBSITE - April 2022 blog "Inside Cassandra: An Interview with Project > Contributor, Aleksandr Sorokoumov" > - > > Key: CASSANDRA-17555 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17555 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Diogenese Topper >Assignee: Erick Ramirez >Priority: Normal > Labels: pull-request-available > Fix For: 4.0.3 > > Attachments: c17555-01-blog-index.png, c17555-02-blog-post.png > > > This ticket is to capture the work associated with publishing the April 2022 > blog "Inside Cassandra: An Interview with Project Contributor, Aleksandr > Sorokoumov" > If this blog cannot be published by the *April 14, 2022 publish date*, please > contact me, suggest changes, or correct the date when possible in the pull > request for the appropriate time that the blog will go live (on both the > blog.adoc and the blog post's file). -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17555) WEBSITE - April 2022 blog "Inside Cassandra: An Interview with Project Contributor, Aleksandr Sorokoumov"
[
https://issues.apache.org/jira/browse/CASSANDRA-17555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Ramirez updated CASSANDRA-17555:
--
Fix Version/s: 4.0.3
(was: NA)
Source Control Link:
https://github.com/apache/cassandra-website/commit/8fd077a60165d991ce75cbde2726688a90d38ad0
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Committed:
||Branch||PR||Commit||
|{{trunk}}|[#124|https://github.com/apache/cassandra-website/pull/124]|[8fd077a|https://github.com/apache/cassandra-website/commit/8fd077a60165d991ce75cbde2726688a90d38ad0]|
> WEBSITE - April 2022 blog "Inside Cassandra: An Interview with Project
> Contributor, Aleksandr Sorokoumov"
> -
>
> Key: CASSANDRA-17555
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17555
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Blog
>Reporter: Diogenese Topper
>Assignee: Erick Ramirez
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.0.3
>
>
> This ticket is to capture the work associated with publishing the April 2022
> blog "Inside Cassandra: An Interview with Project Contributor, Aleksandr
> Sorokoumov"
> If this blog cannot be published by the *April 14, 2022 publish date*, please
> contact me, suggest changes, or correct the date when possible in the pull
> request for the appropriate time that the blog will go live (on both the
> blog.adoc and the blog post's file).
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17555) WEBSITE - April 2022 blog "Inside Cassandra: An Interview with Project Contributor, Aleksandr Sorokoumov"
[ https://issues.apache.org/jira/browse/CASSANDRA-17555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Ramirez updated CASSANDRA-17555: -- Status: Ready to Commit (was: Review In Progress) Made some minor formatting changes. Ready to commit. > WEBSITE - April 2022 blog "Inside Cassandra: An Interview with Project > Contributor, Aleksandr Sorokoumov" > - > > Key: CASSANDRA-17555 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17555 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Diogenese Topper >Assignee: Erick Ramirez >Priority: Normal > Labels: pull-request-available > Fix For: NA > > > This ticket is to capture the work associated with publishing the April 2022 > blog "Inside Cassandra: An Interview with Project Contributor, Aleksandr > Sorokoumov" > If this blog cannot be published by the *April 14, 2022 publish date*, please > contact me, suggest changes, or correct the date when possible in the pull > request for the appropriate time that the blog will go live (on both the > blog.adoc and the blog post's file). -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17555) WEBSITE - April 2022 blog "Inside Cassandra: An Interview with Project Contributor, Aleksandr Sorokoumov"
[ https://issues.apache.org/jira/browse/CASSANDRA-17555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Ramirez updated CASSANDRA-17555: -- Reviewers: Erick Ramirez Status: Review In Progress (was: Patch Available) > WEBSITE - April 2022 blog "Inside Cassandra: An Interview with Project > Contributor, Aleksandr Sorokoumov" > - > > Key: CASSANDRA-17555 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17555 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Diogenese Topper >Assignee: Erick Ramirez >Priority: Normal > Labels: pull-request-available > Fix For: NA > > > This ticket is to capture the work associated with publishing the April 2022 > blog "Inside Cassandra: An Interview with Project Contributor, Aleksandr > Sorokoumov" > If this blog cannot be published by the *April 14, 2022 publish date*, please > contact me, suggest changes, or correct the date when possible in the pull > request for the appropriate time that the blog will go live (on both the > blog.adoc and the blog post's file). -- This message was sent by Atlassian Jira (v8.20.7#820007) - 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 - Inside Cassandra: Interview with Aleksandr Sorokoumov
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 8fd077a6 BLOG - Inside Cassandra: Interview with Aleksandr Sorokoumov 8fd077a6 is described below commit 8fd077a60165d991ce75cbde2726688a90d38ad0 Author: Diogenese Topper AuthorDate: Wed Apr 13 19:47:50 2022 -0700 BLOG - Inside Cassandra: Interview with Aleksandr Sorokoumov patch by Chris Thornett, Diogenese Topper; reviewed by Erick Ramirez for CASSANDRA-17555 Co-authored by: Chris Thornett Co-authored by: Diogenese Topper --- .../blog/inside-Cassandra-Aleksandr-Sorokoumov.png | Bin 0 -> 405151 bytes site-content/source/modules/ROOT/pages/blog.adoc | 25 + ...h-Project-Contributor-Aleksandr-Sorokoumov.adoc | 59 + 3 files changed, 84 insertions(+) diff --git a/site-content/source/modules/ROOT/images/blog/inside-Cassandra-Aleksandr-Sorokoumov.png b/site-content/source/modules/ROOT/images/blog/inside-Cassandra-Aleksandr-Sorokoumov.png new file mode 100644 index ..5f533c6a Binary files /dev/null and b/site-content/source/modules/ROOT/images/blog/inside-Cassandra-Aleksandr-Sorokoumov.png differ diff --git a/site-content/source/modules/ROOT/pages/blog.adoc b/site-content/source/modules/ROOT/pages/blog.adoc index 89c4a792..f22a68e5 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] +=== Inside Cassandra: An Interview with Project Contributor, Aleksandr Sorokoumov +[discrete] + April 21, 2022 +-- +[openblock,card-content] +-- +We continue our Inside Cassandra series with a Q with Aleksandr Sorokoumov who recently accepted the committer position in recognition of his contributions. + +[openblock,card-btn card-btn--blog] + + +[.btn.btn--alt] +xref:blog/Inside-Cassandra-an-interview-with-Project-Contributor-Aleksandr-Sorokoumov.adoc[Read More] + + +-- + +//end card + //start card [openblock,card shadow relative test] diff --git a/site-content/source/modules/ROOT/pages/blog/Inside-Cassandra-an-interview-with-Project-Contributor-Aleksandr-Sorokoumov.adoc b/site-content/source/modules/ROOT/pages/blog/Inside-Cassandra-an-interview-with-Project-Contributor-Aleksandr-Sorokoumov.adoc new file mode 100644 index ..61d7cd87 --- /dev/null +++ b/site-content/source/modules/ROOT/pages/blog/Inside-Cassandra-an-interview-with-Project-Contributor-Aleksandr-Sorokoumov.adoc @@ -0,0 +1,59 @@ += Inside Cassandra: An Interview with Project Contributor, Aleksandr Sorokoumov +:page-layout: single-post +:page-role: blog-post +:page-post-date: April 21, 2022 +:page-post-author: The Apache Cassandra Community +:description: Interview with Aleksandr Sorokoumov +:keywords: + +If communities are the heart of a project, contributors are the lifeblood that keeps open source development pumping away. This time we introduce Aleksandr Sorokoumov. If his volunteer work on the Apache Cassandra project inspires you to get involved, try reading our guide xref:development/index.adoc[‘Contributing to Cassandra’]. + +image::blog/inside-Cassandra-Aleksandr-Sorokoumov.png[Aleksandr Sorokoumov] + +=== About Our Contributor + +Based in Germany, Aleksandr Sorokoumov is a software engineer at Confluent, where he works on ksqlDB, a database purpose-built for stream processing applications. Previously, he was employed at DataStax working on DSE storage engine and AstraDB, a cloud-native database built on top of Apache Cassandra. As well as contributing code to the project, he’s also begun contributing technical write-ups to share some of his hard-fought-for experience with users and contributors. + +=== Contributor Questions + +*Question:* What are you currently working on, or have worked on, in the past for the Apache Cassandra project? + +*Answer:* I am currently working on an article about the internals of CommitLog. This is a component in Apache Cassandra responsible for durability. I worked on several projects at my previous job that required an in-depth understanding of how CommitLog works. It took me some time to find out the details as I had to dig into old JIRA issues and ask experts clarifying questions. I believe this information will benefit DBAs and new contributors; therefore, I felt it would be good to share it. + +Previously, I worked on improving serialization efficiency (https://issues.apache.org/jira/browse/CASSANDRA-15215[CASSANDRA-15215^]). https://developers.google.com/protocol-buffers/docs/encoding#varints[VInt^] (or Varints) is an
[cassandra-website] branch asf-staging updated (71198120 -> 148922ea)
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 71198120 generate docs for b7ad0c5f new 148922ea generate docs for b7ad0c5f 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 (71198120) \ N -- N -- N refs/heads/asf-staging (148922ea) 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-17551) Allow 0 to be used in collection_size guardrails in order to prohibit collections
[ https://issues.apache.org/jira/browse/CASSANDRA-17551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17525339#comment-17525339 ] Ekaterina Dimitrova commented on CASSANDRA-17551: - I just updated the description. One side effect of having this: - if warn is o but fail is not - then we will warn every time but fail at the fail threshold - if warn and fail are 0 - we just prohibit them. > Allow 0 to be used in collection_size guardrails in order to prohibit > collections > - > > Key: CASSANDRA-17551 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17551 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Guardrails >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.x > > > Allow 0 to be used in collection_size guardrails in order to prohibit > collections -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17551) Allow 0 to be used in collection_size guardrails in order to prohibit collections
[ https://issues.apache.org/jira/browse/CASSANDRA-17551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-17551: Description: Allow 0 to be used in collection_size guardrails in order to prohibit collections (was: # The two thresholds default to 0KiB to disable. # collection_size_warn_threshold: 0KiB # collection_size_fail_threshold: 0KiB 0KiB should be used to prohibit collections and not to disable the guardrail. Disabled should be null as we moved to that as part of CASSANDRA-17431 while investigating other config corner cases. Old config which had -1 for disable will be converted internally to null with the new config types and new config should use null for disable. Of course, disabling 0 as a non-valid value is a different story which should be handled on per-case basis. ) > Allow 0 to be used in collection_size guardrails in order to prohibit > collections > - > > Key: CASSANDRA-17551 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17551 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Guardrails >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.x > > > Allow 0 to be used in collection_size guardrails in order to prohibit > collections -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17551) Allow 0 to be used in collection_size guardrails in order to prohibit collections
[ https://issues.apache.org/jira/browse/CASSANDRA-17551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-17551: Summary: Allow 0 to be used in collection_size guardrails in order to prohibit collections (was: 0KiB should be used to prohibit collections and not to disable the guardrails collection_size_warn_threshold and collection_size_fail_threshold) > Allow 0 to be used in collection_size guardrails in order to prohibit > collections > - > > Key: CASSANDRA-17551 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17551 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Guardrails >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.x > > > # The two thresholds default to 0KiB to disable. > # collection_size_warn_threshold: 0KiB > # collection_size_fail_threshold: 0KiB > 0KiB should be used to prohibit collections and not to disable the guardrail. > Disabled should be null as we moved to that as part of CASSANDRA-17431 while > investigating other config corner cases. > Old config which had -1 for disable will be converted internally to null with > the new config types and new config should use null for disable. Of course, > disabling 0 as a non-valid value is a different story which should be handled > on per-case basis. -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17551) 0KiB should be used to prohibit collections and not to disable the guardrails collection_size_warn_threshold and collection_size_fail_threshold
[ https://issues.apache.org/jira/browse/CASSANDRA-17551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-17551: Workflow: Copy of Cassandra Default Workflow (was: Copy of Cassandra Bug Workflow) Issue Type: Improvement (was: Bug) > 0KiB should be used to prohibit collections and not to disable the guardrails > collection_size_warn_threshold and collection_size_fail_threshold > --- > > Key: CASSANDRA-17551 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17551 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Guardrails >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.x > > > # The two thresholds default to 0KiB to disable. > # collection_size_warn_threshold: 0KiB > # collection_size_fail_threshold: 0KiB > 0KiB should be used to prohibit collections and not to disable the guardrail. > Disabled should be null as we moved to that as part of CASSANDRA-17431 while > investigating other config corner cases. > Old config which had -1 for disable will be converted internally to null with > the new config types and new config should use null for disable. Of course, > disabling 0 as a non-valid value is a different story which should be handled > on per-case basis. -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17551) 0KiB should be used to prohibit collections and not to disable the guardrails collection_size_warn_threshold and collection_size_fail_threshold
[
https://issues.apache.org/jira/browse/CASSANDRA-17551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17525327#comment-17525327
]
Ekaterina Dimitrova commented on CASSANDRA-17551:
-
{quote}The advantage of using 0 as disabled value is that config would be
briefer than adding separate properties. Maybe we could modify {{Threshold}}
guardrails to include the functionalities of {{{}DisableFlag{}}}, which are an
{{ensureEnabled}} method and a separate warn/error message for the particular
case of 0. That would be useful not only for size-based guardrails but also for
numeric guardrails such as, for example,
{{{}materialized_views_per_table_warn_threshold{}}}/{{{}materialized_views_per_table_fail_threshold{}}},
where 0 would disallow or warn about MV creation in general, independently of
the number of MVs. wdyt?
{quote}
I like this. I agree that it will be nice not to overwhelm more config but at
the same time additional check/method at the right places only for
_ensureEnabled_ sounds very reasonable to me. I will try to add it tomorrow
morning. Hope you can review these days :)
> 0KiB should be used to prohibit collections and not to disable the guardrails
> collection_size_warn_threshold and collection_size_fail_threshold
> ---
>
> Key: CASSANDRA-17551
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17551
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Guardrails
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.x
>
>
> # The two thresholds default to 0KiB to disable.
> # collection_size_warn_threshold: 0KiB
> # collection_size_fail_threshold: 0KiB
> 0KiB should be used to prohibit collections and not to disable the guardrail.
> Disabled should be null as we moved to that as part of CASSANDRA-17431 while
> investigating other config corner cases.
> Old config which had -1 for disable will be converted internally to null with
> the new config types and new config should use null for disable. Of course,
> disabling 0 as a non-valid value is a different story which should be handled
> on per-case basis.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17379) Fail starting when the same parameter exists more than once with different values in cassandra.yaml
[
https://issues.apache.org/jira/browse/CASSANDRA-17379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17525324#comment-17525324
]
Ekaterina Dimitrova commented on CASSANDRA-17379:
-
Thanks!
Overall LGTM, I left just one suggestion in regards to an exception message.
Otherwise, I believe we need only NEWS.txt, update of the doc similar to what I
suggested in the previous review and full CI.
I guess if you want second reviewer [~maedhroz] and [~dcapwell] are also very
well familiar with these things.
> Fail starting when the same parameter exists more than once with different
> values in cassandra.yaml
>
>
> Key: CASSANDRA-17379
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17379
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Ekaterina Dimitrova
>Assignee: Marcus Eriksson
>Priority: Low
> Fix For: 4.x
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The way that SnakeYAML works, if someone has added the same parameter more
> than once - the last occurrence will be the one that will take precedence.
> Now after CASSANDRA-15234 we can even add the parameter with the old name and
> with the new name and the occurrences will replace each other. Again,
> whatever is last in cassandra.yaml will take precedence. Example:
> If you add the following in cassandra.yaml
> {code:java}
> hinted_handoff_enabled: true
> enabled_hinted_handolff: false
> {code}
> you will get loaded in Config -
> {code:java}
> hinted_handoff_enabled: false{code}
> //there is backward compatibility from the old name to load into the new one
> Currently Cassandra prints in the logs what config was loaded but it is good
> also to detect the case mentioned and emit a warning for the user so they can
> verify that the value they wanted was loaded in config.
> To do that you might want to look at the PropertiesChecker and the way we
> emit other warnings in
> [check()|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/config/YamlConfigurationLoader.java#L376]
> in YamlConfigurationLoader.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17537) nodetool compact should support using a key string to find the range to avoid operators having to manually do this
[ https://issues.apache.org/jira/browse/CASSANDRA-17537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17525323#comment-17525323 ] David Capwell commented on CASSANDRA-17537: --- pushed feedback [~marcuse] > nodetool compact should support using a key string to find the range to avoid > operators having to manually do this > -- > > Key: CASSANDRA-17537 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17537 > Project: Cassandra > Issue Type: New Feature > Components: Local/Compaction, Tool/nodetool >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Time Spent: 40m > Remaining Estimate: 0h > > Its common that a single key needs to be compact, and operators need to do > the following > 1) go from key -> token > 2) generate range > 3) call nodetool compact with this range > We can simply this workflow by adding this to compact > nodetool compact ks.tbl -k “key1" -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17560) Migrate track_warnings to more standard naming conventions and use latest configuration types rather than long
[ https://issues.apache.org/jira/browse/CASSANDRA-17560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17525320#comment-17525320 ] David Capwell commented on CASSANDRA-17560: --- Starting commit CI Results (pending): ||Branch||Source||Circle CI||Jenkins|| |trunk|[branch|https://github.com/dcapwell/cassandra/tree/commit_remote_branch/CASSANDRA-17560-trunk-6A7EA9D8-40CC-4B50-BA2E-2F42559D8437]|[build|https://app.circleci.com/pipelines/github/dcapwell/cassandra?branch=commit_remote_branch%2FCASSANDRA-17560-trunk-6A7EA9D8-40CC-4B50-BA2E-2F42559D8437]|[build|https://ci-cassandra.apache.org/job/Cassandra-devbranch/1619/]| > Migrate track_warnings to more standard naming conventions and use latest > configuration types rather than long > -- > > Key: CASSANDRA-17560 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17560 > Project: Cassandra > Issue Type: Improvement > Components: Local/Config >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 4.1 > > Time Spent: 5h 20m > Remaining Estimate: 0h > > Track warnings currently is nested which is discouraged at the moment. It > also was before the config standards patch which moved storage typed longs to > a new DataStorageSpec type, we should migrate the configs there. -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17560) Migrate track_warnings to more standard naming conventions and use latest configuration types rather than long
[ https://issues.apache.org/jira/browse/CASSANDRA-17560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17525317#comment-17525317 ] David Capwell commented on CASSANDRA-17560: --- I believe I got [~adelapena] approval in slack, so starting merge; will hold off on the push up until I confirm > Migrate track_warnings to more standard naming conventions and use latest > configuration types rather than long > -- > > Key: CASSANDRA-17560 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17560 > Project: Cassandra > Issue Type: Improvement > Components: Local/Config >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 4.1 > > Time Spent: 5h 20m > Remaining Estimate: 0h > > Track warnings currently is nested which is discouraged at the moment. It > also was before the config standards patch which moved storage typed longs to > a new DataStorageSpec type, we should migrate the configs there. -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-17560) Migrate track_warnings to more standard naming conventions and use latest configuration types rather than long
[ https://issues.apache.org/jira/browse/CASSANDRA-17560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell reassigned CASSANDRA-17560: - Assignee: David Capwell > Migrate track_warnings to more standard naming conventions and use latest > configuration types rather than long > -- > > Key: CASSANDRA-17560 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17560 > Project: Cassandra > Issue Type: Improvement > Components: Local/Config >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 4.1 > > Time Spent: 5h 20m > Remaining Estimate: 0h > > Track warnings currently is nested which is discouraged at the moment. It > also was before the config standards patch which moved storage typed longs to > a new DataStorageSpec type, we should migrate the configs there. -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17180) Implement startup check to prevent Cassandra start to spread zombie data
[ https://issues.apache.org/jira/browse/CASSANDRA-17180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17525316#comment-17525316 ] Paulo Motta commented on CASSANDRA-17180: - I cannot review this today but I *hope* to follow-up this by tomorrow or Friday if nobody else gets to it before. > Implement startup check to prevent Cassandra start to spread zombie data > > > Key: CASSANDRA-17180 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17180 > Project: Cassandra > Issue Type: New Feature > Components: Legacy/Observability >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Time Spent: 9.5h > Remaining Estimate: 0h > > As already discussed on ML, it would be nice to have a service which would > periodically write timestamp to a file signalling it is up / running. > Then, on the startup, we would read this file and we would determine if there > is some table which gc grace is behind this time and we would fail the start > so we would prevent zombie data to be likely spread around a cluster. > https://lists.apache.org/thread/w4w5t2hlcrvqhgdwww61hgg58qz13glw -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17568) Tool to list data directories
[
https://issues.apache.org/jira/browse/CASSANDRA-17568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17525314#comment-17525314
]
Paulo Motta commented on CASSANDRA-17568:
-
Btw this can probably be worked in parallel with CASSANDRA-16843 given I don't
expect much changes on the published patch.
> Tool to list data directories
> -
>
> Key: CASSANDRA-17568
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17568
> Project: Cassandra
> Issue Type: New Feature
> Components: Tool/nodetool
>Reporter: Tibor Repasi
>Assignee: Tibor Repasi
>Priority: Normal
> Fix For: 4.x
>
>
> When a table is created, dropped and re-created with the same name,
> directories remain within data paths. Operators may be challenged finding out
> which directories belong to existing tables and which may be subject to
> removal. However, the information is available in CQL as well as in MBeans
> via JMX, a convenient access to this information is still missing.
> My proposal is a new nodetool subcommand allowing to list data paths of all
> existing tables.
> {code}
> % bin/nodetool datapaths -- example
> Keyspace : example
> Table : test
> Paths :
>
> /var/lib/cassandra/data/example/test-02f5b8d0c0e311ecb327ff24df5ab301
>
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17568) Tool to list data directories
[
https://issues.apache.org/jira/browse/CASSANDRA-17568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17525313#comment-17525313
]
Paulo Motta commented on CASSANDRA-17568:
-
{quote}I am not completely sure we manage to get this one in in forseeable
future.
{quote}
I don't see why we can't get this by 4.1 if [~rtib] addresses outstanding
review comments and does not conflict with CASSANDRA-16843.
Even though we have a feature freeze at May 1st we still have 10 days left to
get things in.
> Tool to list data directories
> -
>
> Key: CASSANDRA-17568
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17568
> Project: Cassandra
> Issue Type: New Feature
> Components: Tool/nodetool
>Reporter: Tibor Repasi
>Assignee: Tibor Repasi
>Priority: Normal
> Fix For: 4.x
>
>
> When a table is created, dropped and re-created with the same name,
> directories remain within data paths. Operators may be challenged finding out
> which directories belong to existing tables and which may be subject to
> removal. However, the information is available in CQL as well as in MBeans
> via JMX, a convenient access to this information is still missing.
> My proposal is a new nodetool subcommand allowing to list data paths of all
> existing tables.
> {code}
> % bin/nodetool datapaths -- example
> Keyspace : example
> Table : test
> Paths :
>
> /var/lib/cassandra/data/example/test-02f5b8d0c0e311ecb327ff24df5ab301
>
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17568) Tool to list data directories
[
https://issues.apache.org/jira/browse/CASSANDRA-17568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17525312#comment-17525312
]
Stefan Miklosovic commented on CASSANDRA-17568:
---
That would be great if you manage to ship it with 4.1 so we have something to
build on. The functionality required for 2) to happen is to basically get all
keyspace / table directories, even of dropped tables. Since it is possible,
your patch in, to list snapshots of dropped tables, I do not think it would be
any problem to get the list of such dropped tables in the first place.
I am not completely sure we manage to get this one in in forseeable future.
Maybe [~rtib] does not know it but we are having feature freeze at 1st May.
> Tool to list data directories
> -
>
> Key: CASSANDRA-17568
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17568
> Project: Cassandra
> Issue Type: New Feature
> Components: Tool/nodetool
>Reporter: Tibor Repasi
>Assignee: Tibor Repasi
>Priority: Normal
> Fix For: 4.x
>
>
> When a table is created, dropped and re-created with the same name,
> directories remain within data paths. Operators may be challenged finding out
> which directories belong to existing tables and which may be subject to
> removal. However, the information is available in CQL as well as in MBeans
> via JMX, a convenient access to this information is still missing.
> My proposal is a new nodetool subcommand allowing to list data paths of all
> existing tables.
> {code}
> % bin/nodetool datapaths -- example
> Keyspace : example
> Table : test
> Paths :
>
> /var/lib/cassandra/data/example/test-02f5b8d0c0e311ecb327ff24df5ab301
>
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17563) Fix CircleCI Midres config
[ https://issues.apache.org/jira/browse/CASSANDRA-17563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17525294#comment-17525294 ] David Capwell commented on CASSANDRA-17563: --- marking 4.1 as I broke trunk, so need to fix so CI works for everyone > Fix CircleCI Midres config > -- > > Key: CASSANDRA-17563 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17563 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.1 > > > During CircleCI addition of a new job to the config, the midres file got > messy. Two of the immediate issues (but we need to verify all jobs will use > the right executors and resources): > * the new job needs to use higher parallelism as the original in-jvm job > * j8_dtests_with_vnodes should get from midres 50 large but currently > midres makes it run with 25 and medium which fails around 100 tests -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17563) Fix CircleCI Midres config
[ https://issues.apache.org/jira/browse/CASSANDRA-17563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17525287#comment-17525287 ] David Capwell edited comment on CASSANDRA-17563 at 4/20/22 9:10 PM: [~e.dimitrova], [~Bereng], [~brandonwilliams] mind reviewing? You are all familiar with circle ci so value your feedback MIDRES: https://app.circleci.com/pipelines/github/dcapwell/cassandra/1372/workflows/942cf870-c90d-4a29-ab97-b335caf2d08f was (Author: dcapwell): [~e.dimitrova], [~Bereng], [~brandonwilliams] mind reviewing? You are all familiar with circle ci so value your feedback > Fix CircleCI Midres config > -- > > Key: CASSANDRA-17563 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17563 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Ekaterina Dimitrova >Priority: Normal > > During CircleCI addition of a new job to the config, the midres file got > messy. Two of the immediate issues (but we need to verify all jobs will use > the right executors and resources): > * the new job needs to use higher parallelism as the original in-jvm job > * j8_dtests_with_vnodes should get from midres 50 large but currently > midres makes it run with 25 and medium which fails around 100 tests -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17563) Fix CircleCI Midres config
[ https://issues.apache.org/jira/browse/CASSANDRA-17563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-17563: -- Fix Version/s: 4.1 > Fix CircleCI Midres config > -- > > Key: CASSANDRA-17563 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17563 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.1 > > > During CircleCI addition of a new job to the config, the midres file got > messy. Two of the immediate issues (but we need to verify all jobs will use > the right executors and resources): > * the new job needs to use higher parallelism as the original in-jvm job > * j8_dtests_with_vnodes should get from midres 50 large but currently > midres makes it run with 25 and medium which fails around 100 tests -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17563) Fix CircleCI Midres config
[ https://issues.apache.org/jira/browse/CASSANDRA-17563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17525292#comment-17525292 ] Brandon Williams commented on CASSANDRA-17563: -- cc [~adelapena] > Fix CircleCI Midres config > -- > > Key: CASSANDRA-17563 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17563 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Ekaterina Dimitrova >Priority: Normal > > During CircleCI addition of a new job to the config, the midres file got > messy. Two of the immediate issues (but we need to verify all jobs will use > the right executors and resources): > * the new job needs to use higher parallelism as the original in-jvm job > * j8_dtests_with_vnodes should get from midres 50 large but currently > midres makes it run with 25 and medium which fails around 100 tests -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17563) Fix CircleCI Midres config
[
https://issues.apache.org/jira/browse/CASSANDRA-17563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17525291#comment-17525291
]
David Capwell commented on CASSANDRA-17563:
---
Created a script to dump the resources (type + parallel) for each job, used
this to diff old configs to make sure they matched; below is the output as of
20175bf77e2c6f72c25240ee445b583805a37630 (before vnode patch)
{code}
$ diff midres.resources midres.resources.new
9a10
> j11_jvm_dtests_vnode medium 10
22a24
> j8_jvm_dtests_vnode large 10
(CASSANDRA-17563) $ diff higher.resources higher.resources.new
9a10
> j11_jvm_dtests_vnode xlarge 5
22a24
> j8_jvm_dtests_vnode xlarge 5
{code}
> Fix CircleCI Midres config
> --
>
> Key: CASSANDRA-17563
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17563
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Priority: Normal
>
> During CircleCI addition of a new job to the config, the midres file got
> messy. Two of the immediate issues (but we need to verify all jobs will use
> the right executors and resources):
> * the new job needs to use higher parallelism as the original in-jvm job
> * j8_dtests_with_vnodes should get from midres 50 large but currently
> midres makes it run with 25 and medium which fails around 100 tests
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17568) Tool to list data directories
[
https://issues.apache.org/jira/browse/CASSANDRA-17568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17525290#comment-17525290
]
Paulo Motta commented on CASSANDRA-17568:
-
bq. The refactorisation he was doing was also done due to the fact that right
now you can not list snapshots of dropped tables because Cassandra does not
"see" it anymore when they are dropped. Hence I think we need to first move
Paulo's work forward and once done, we would expose the information what tables
are not meant to be there anymore - which would be your list.
This logic is available on this [SnapshotFinder
class|https://github.com/apache/cassandra/blob/2b1ec31885908b1199a93127668b2a4fd422a2c6/src/java/org/apache/cassandra/service/snapshot/SnapshotFinder.java]
from CASSANDRA-16843 (planning to wrap this up soon for 4.1). Not sure if this
is a blocker to this ticket or if both efforts do not conflict with each other.
> Tool to list data directories
> -
>
> Key: CASSANDRA-17568
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17568
> Project: Cassandra
> Issue Type: New Feature
> Components: Tool/nodetool
>Reporter: Tibor Repasi
>Assignee: Tibor Repasi
>Priority: Normal
> Fix For: 4.x
>
>
> When a table is created, dropped and re-created with the same name,
> directories remain within data paths. Operators may be challenged finding out
> which directories belong to existing tables and which may be subject to
> removal. However, the information is available in CQL as well as in MBeans
> via JMX, a convenient access to this information is still missing.
> My proposal is a new nodetool subcommand allowing to list data paths of all
> existing tables.
> {code}
> % bin/nodetool datapaths -- example
> Keyspace : example
> Table : test
> Paths :
>
> /var/lib/cassandra/data/example/test-02f5b8d0c0e311ecb327ff24df5ab301
>
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17563) Fix CircleCI Midres config
[ https://issues.apache.org/jira/browse/CASSANDRA-17563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17525288#comment-17525288 ] David Capwell commented on CASSANDRA-17563: --- [~jmckenzie] cc > Fix CircleCI Midres config > -- > > Key: CASSANDRA-17563 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17563 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Ekaterina Dimitrova >Priority: Normal > > During CircleCI addition of a new job to the config, the midres file got > messy. Two of the immediate issues (but we need to verify all jobs will use > the right executors and resources): > * the new job needs to use higher parallelism as the original in-jvm job > * j8_dtests_with_vnodes should get from midres 50 large but currently > midres makes it run with 25 and medium which fails around 100 tests -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17563) Fix CircleCI Midres config
[ https://issues.apache.org/jira/browse/CASSANDRA-17563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17525287#comment-17525287 ] David Capwell commented on CASSANDRA-17563: --- [~e.dimitrova], [~Bereng], [~brandonwilliams] mind reviewing? You are all familiar with circle ci so value your feedback > Fix CircleCI Midres config > -- > > Key: CASSANDRA-17563 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17563 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Ekaterina Dimitrova >Priority: Normal > > During CircleCI addition of a new job to the config, the midres file got > messy. Two of the immediate issues (but we need to verify all jobs will use > the right executors and resources): > * the new job needs to use higher parallelism as the original in-jvm job > * j8_dtests_with_vnodes should get from midres 50 large but currently > midres makes it run with 25 and medium which fails around 100 tests -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17568) Tool to list data directories
[
https://issues.apache.org/jira/browse/CASSANDRA-17568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17525284#comment-17525284
]
Stefan Miklosovic commented on CASSANDRA-17568:
---
Hi [~rtib], thanks for the patch & idea. I think I was the one who added that
"getDataPaths" method to be able to retrieve this information and I am glad it
is useful and you are building on top of that.
I was briefly looking into the code. If we ever merge something like this, it
would be nice to have it more robust / prepared to other scenarios. The tool
should be able to:
1) return all data directories of a particular table(s).
2) return all data directories which are eligible to be deleted as the
respective keyspace / table (or both) does not exist anymore in Cassandra.
You implemented 1) but I miss 2). As I understand it, now you get the list of
1) and then you go over all the dirs and make "diff" to see which one you can
remove. Why not to do it in such a way that you would get the list of tables to
remove directly?
In order to do 2), I think that this is somehow tangential to what [~paulo] was
trying to do with his refactorisation of data dir parsing. I will link the JIRA
if I find it. The refactorisation he was doing was also done due to the fact
that right now you can not list snapshots of dropped tables because Cassandra
does not "see" it anymore when they are dropped. Hence I think we need to first
move Paulo's work forward and once done, we would expose the information what
tables are not meant to be there anymore - which would be your list.
> Tool to list data directories
> -
>
> Key: CASSANDRA-17568
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17568
> Project: Cassandra
> Issue Type: New Feature
> Components: Tool/nodetool
>Reporter: Tibor Repasi
>Assignee: Tibor Repasi
>Priority: Normal
> Fix For: 4.x
>
>
> When a table is created, dropped and re-created with the same name,
> directories remain within data paths. Operators may be challenged finding out
> which directories belong to existing tables and which may be subject to
> removal. However, the information is available in CQL as well as in MBeans
> via JMX, a convenient access to this information is still missing.
> My proposal is a new nodetool subcommand allowing to list data paths of all
> existing tables.
> {code}
> % bin/nodetool datapaths -- example
> Keyspace : example
> Table : test
> Paths :
>
> /var/lib/cassandra/data/example/test-02f5b8d0c0e311ecb327ff24df5ab301
>
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17568) Tool to list data directories
[
https://issues.apache.org/jira/browse/CASSANDRA-17568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-17568:
-
Change Category: Operability
Complexity: Normal
Fix Version/s: 4.x
Assignee: Tibor Repasi
Status: Open (was: Triage Needed)
> Tool to list data directories
> -
>
> Key: CASSANDRA-17568
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17568
> Project: Cassandra
> Issue Type: New Feature
> Components: Tool/nodetool
>Reporter: Tibor Repasi
>Assignee: Tibor Repasi
>Priority: Normal
> Fix For: 4.x
>
>
> When a table is created, dropped and re-created with the same name,
> directories remain within data paths. Operators may be challenged finding out
> which directories belong to existing tables and which may be subject to
> removal. However, the information is available in CQL as well as in MBeans
> via JMX, a convenient access to this information is still missing.
> My proposal is a new nodetool subcommand allowing to list data paths of all
> existing tables.
> {code}
> % bin/nodetool datapaths -- example
> Keyspace : example
> Table : test
> Paths :
>
> /var/lib/cassandra/data/example/test-02f5b8d0c0e311ecb327ff24df5ab301
>
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17370) Add flag enabling operators to restrict use of ALLOW FILTERING in queries
[ https://issues.apache.org/jira/browse/CASSANDRA-17370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17525265#comment-17525265 ] Savni Nagarkar edited comment on CASSANDRA-17370 at 4/20/22 8:24 PM: - ||patch||ci|| |[allow_filtering|https://github.com/apache/cassandra/pull/1453]|[j8|https://app.circleci.com/pipelines/github/thingtwin1/cassandra?branch=allow_filtering=all]| was (Author: JIRAUSER284678): ||patch||ci|| |[allow_filtering|https://github.com/apache/cassandra/pull/1453]|[j8\|https://app.circleci.com/pipelines/github/thingtwin1/cassandra?branch=allow_filtering=all]| > Add flag enabling operators to restrict use of ALLOW FILTERING in queries > - > > Key: CASSANDRA-17370 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17370 > Project: Cassandra > Issue Type: Improvement > Components: CQL/Semantics, Feature/Guardrails >Reporter: Savni Nagarkar >Assignee: Savni Nagarkar >Priority: Normal > Fix For: 4.x > > Time Spent: 3h 20m > Remaining Estimate: 0h > > This ticket adds the ability for operators to disallow use of ALLOW FILTERING > predicates in CQL SELECT statements. As queries that ALLOW FILTERING can > place additional load on the database, the flag enables operators to provide > tighter bounds on performance guarantees. The patch includes a new yaml > property, as well as a hot property enabling the value to be modified via JMX > at runtime. -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17370) Add flag enabling operators to restrict use of ALLOW FILTERING in queries
[ https://issues.apache.org/jira/browse/CASSANDRA-17370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17525265#comment-17525265 ] Savni Nagarkar commented on CASSANDRA-17370: ||patch||ci|| |[allow_filtering|https://github.com/apache/cassandra/pull/1453]|[j8\|https://app.circleci.com/pipelines/github/thingtwin1/cassandra?branch=allow_filtering=all]| > Add flag enabling operators to restrict use of ALLOW FILTERING in queries > - > > Key: CASSANDRA-17370 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17370 > Project: Cassandra > Issue Type: Improvement > Components: CQL/Semantics, Feature/Guardrails >Reporter: Savni Nagarkar >Assignee: Savni Nagarkar >Priority: Normal > Fix For: 4.x > > Time Spent: 3h 20m > Remaining Estimate: 0h > > This ticket adds the ability for operators to disallow use of ALLOW FILTERING > predicates in CQL SELECT statements. As queries that ALLOW FILTERING can > place additional load on the database, the flag enables operators to provide > tighter bounds on performance guarantees. The patch includes a new yaml > property, as well as a hot property enabling the value to be modified via JMX > at runtime. -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17565) Fix test_parallel_upgrade_with_internode_ssl
[ https://issues.apache.org/jira/browse/CASSANDRA-17565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17525261#comment-17525261 ] Brandon Williams edited comment on CASSANDRA-17565 at 4/20/22 8:19 PM: --- This is similar to CASSANDRA-16277 but the connection is further along. [Branch|https://github.com/driftx/cassandra/tree/CASSANDRA-17565] to silence the error and [4000 runs|https://app.circleci.com/pipelines/github/driftx/cassandra/443/workflows/f7abfc54-4f1d-4415-b4d3-0b00984be262/jobs/5182] in circle...but that didn't work, so ignore this. was (Author: brandon.williams): This is similar to CASSANDRA-16277 but the connection is further along. [Branch|https://github.com/driftx/cassandra/tree/CASSANDRA-17565] to silence the error and [4000 runs|https://app.circleci.com/pipelines/github/driftx/cassandra/443/workflows/f7abfc54-4f1d-4415-b4d3-0b00984be262/jobs/5182] in circle. > Fix test_parallel_upgrade_with_internode_ssl > > > Key: CASSANDRA-17565 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17565 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Brandon Williams >Priority: Normal > Fix For: 4.x > > > While working on CASSANDRA-17341 I hit this flaky test, very rarely failing > but it is failing on trunk. > More info in this CI run: > https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1563/workflows/61bda0b7-f699-4897-877f-c7d523a03127/jobs/10318 -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17565) Fix test_parallel_upgrade_with_internode_ssl
[ https://issues.apache.org/jira/browse/CASSANDRA-17565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17525261#comment-17525261 ] Brandon Williams commented on CASSANDRA-17565: -- This is similar to CASSANDRA-16277 but the connection is further along. [Branch|https://github.com/driftx/cassandra/tree/CASSANDRA-17565] to silence the error and [4000 runs|https://app.circleci.com/pipelines/github/driftx/cassandra/443/workflows/f7abfc54-4f1d-4415-b4d3-0b00984be262/jobs/5182] in circle. > Fix test_parallel_upgrade_with_internode_ssl > > > Key: CASSANDRA-17565 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17565 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Brandon Williams >Priority: Normal > Fix For: 4.x > > > While working on CASSANDRA-17341 I hit this flaky test, very rarely failing > but it is failing on trunk. > More info in this CI run: > https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1563/workflows/61bda0b7-f699-4897-877f-c7d523a03127/jobs/10318 -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17568) Tool to list data directories
[
https://issues.apache.org/jira/browse/CASSANDRA-17568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17525262#comment-17525262
]
Tibor Repasi commented on CASSANDRA-17568:
--
GitHub [PR#1580|https://github.com/apache/cassandra/pull/1580] is open with
request for comments.
> Tool to list data directories
> -
>
> Key: CASSANDRA-17568
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17568
> Project: Cassandra
> Issue Type: New Feature
> Components: Tool/nodetool
>Reporter: Tibor Repasi
>Priority: Normal
>
> When a table is created, dropped and re-created with the same name,
> directories remain within data paths. Operators may be challenged finding out
> which directories belong to existing tables and which may be subject to
> removal. However, the information is available in CQL as well as in MBeans
> via JMX, a convenient access to this information is still missing.
> My proposal is a new nodetool subcommand allowing to list data paths of all
> existing tables.
> {code}
> % bin/nodetool datapaths -- example
> Keyspace : example
> Table : test
> Paths :
>
> /var/lib/cassandra/data/example/test-02f5b8d0c0e311ecb327ff24df5ab301
>
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17568) Tool to list data directories
Tibor Repasi created CASSANDRA-17568:
Summary: Tool to list data directories
Key: CASSANDRA-17568
URL: https://issues.apache.org/jira/browse/CASSANDRA-17568
Project: Cassandra
Issue Type: New Feature
Components: Tool/nodetool
Reporter: Tibor Repasi
When a table is created, dropped and re-created with the same name, directories
remain within data paths. Operators may be challenged finding out which
directories belong to existing tables and which may be subject to removal.
However, the information is available in CQL as well as in MBeans via JMX, a
convenient access to this information is still missing.
My proposal is a new nodetool subcommand allowing to list data paths of all
existing tables.
{code}
% bin/nodetool datapaths -- example
Keyspace : example
Table : test
Paths :
/var/lib/cassandra/data/example/test-02f5b8d0c0e311ecb327ff24df5ab301
{code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17465) python unit tests don't cleanup test keyspace
[
https://issues.apache.org/jira/browse/CASSANDRA-17465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-17465:
-
Fix Version/s: 4.1
(was: 4.x)
Source Control Link:
https://github.com/apache/cassandra/commit/0d860ec662b0088ea7f77f98051121e198eb5692
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Committed, thanks.
> python unit tests don't cleanup test keyspace
> -
>
> Key: CASSANDRA-17465
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17465
> Project: Cassandra
> Issue Type: Task
> Components: CQL/Interpreter
>Reporter: Brad Schoening
>Assignee: Brad Schoening
>Priority: Normal
> Fix For: 4.1
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> The python unit tests in pylib/cqlshlib creates a temporary keyspace
> cqlshtests_, but does not drop it upon completion.
> To reproduce:
> {code:java}
> $ pytest
> $ cqlsh
> cassandra@cqlsh> describe keyspaces
> cqlshtests_oatjjlyyxh ...
> {code}
> The above keyspace, created with a 10 character random suffix, will remain
> after the tests are run. This will then cause subsequent runs of
> test_cqlsh_completion to fail.
>
> {code:java}
> cqlshlib/test/test_cqlsh_completion.py:138: in _trycompletions_inner
> E AssertionError: Items in the second set but not the first:
> E 'cqlshtests_oatjjlyyxh'
> {code}
> test/cassconnect.py;'s remove_db() has the code to perform this, but does not
> seem to be properly called.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16778) Jvm-dtest race on closing and log messages
[
https://issues.apache.org/jira/browse/CASSANDRA-16778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17525242#comment-17525242
]
Ekaterina Dimitrova commented on CASSANDRA-16778:
-
I saw this failure again today
https://jenkins-cm4.apache.org/job/Cassandra-trunk/1088/testReport/junit/org.apache.cassandra.distributed.test/IPMembershipTest/startupNewIP/
> Jvm-dtest race on closing and log messages
> --
>
> Key: CASSANDRA-16778
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16778
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: Berenguer Blasi
>Priority: Low
> Fix For: 4.0.x, 4.x
>
> Attachments: system.log
>
>
> Failure of
> [IPMembershipTest|https://ci-cassandra.apache.org/job/Cassandra-4.0.0/40/testReport/junit/org.apache.cassandra.distributed.test/IPMembershipTest/startupNewIP/]:
> {noformat}
> Uncaught exceptions were thrown during test
> {noformat}
> led me to investigate the
> [logs|https://nightlies.apache.org/cassandra/cassandra-4.0.0/Cassandra-4.0.0-jvm-dtest/37/Cassandra-4.0.0-jvm-dtest/jdk=jdk_11_latest,label=cassandra,split=6/build/test/logs/org.apache.cassandra.distributed.test.IPMembershipTest/%3cmain%3e/%3cmain%3e/]
> a bit where it seems we can be in a 'closed' state but trying to perform
> operations such as logging still
> {noformat}
> ERROR [RequestResponseStage-8] 2021-06-30 08:18:31,211 uncaught
> exception in thread Thread[RequestResponseStage-8,5,node3]
> java.lang.IllegalStateException: Can't load
> ch.qos.logback.core.status.ErrorStatus. Instance class loader is already
> closed.
> at
> org.apache.cassandra.distributed.shared.InstanceClassLoader.loadClassInternal(InstanceClassLoader.java:93)
> at
> org.apache.cassandra.distributed.shared.InstanceClassLoader.loadClass(InstanceClassLoader.java:87)
> at
> ch.qos.logback.core.spi.ContextAwareBase.addError(ContextAwareBase.java:105)
> at
> ch.qos.logback.core.UnsynchronizedAppenderBase.doAppend(UnsynchronizedAppenderBase.java:88)
> at
> ch.qos.logback.core.spi.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachableImpl.java:51)
> at ch.qos.logback.classic.Logger.appendLoopOnAppenders(Logger.java:270)
> at ch.qos.logback.classic.Logger.callAppenders(Logger.java:257)
> at
> ch.qos.logback.classic.Logger.buildLoggingEventAndAppend(Logger.java:421)
> at ch.qos.logback.classic.Logger.filterAndLog_0_Or3Plus(Logger.java:383)
> at ch.qos.logback.classic.Logger.log(Logger.java:765)
> at
> io.netty.util.internal.logging.LocationAwareSlf4JLogger.log(LocationAwareSlf4JLogger.java:50)
> at
> io.netty.util.internal.logging.LocationAwareSlf4JLogger.debug(LocationAwareSlf4JLogger.java:115)
> at io.netty.buffer.PoolThreadCache.free(PoolThreadCache.java:224)
> at
> io.netty.buffer.PooledByteBufAllocator$PoolThreadLocalCache.onRemoval(PooledByteBufAllocator.java:516)
> at
> io.netty.buffer.PooledByteBufAllocator$PoolThreadLocalCache.onRemoval(PooledByteBufAllocator.java:483)
> at
> io.netty.util.concurrent.FastThreadLocal.remove(FastThreadLocal.java:256)
> at
> io.netty.util.concurrent.FastThreadLocal.removeAll(FastThreadLocal.java:67)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:32)
> at java.base/java.lang.Thread.run(Thread.java:834)
> {noformat}
> Log attached
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17244) Fix org.apache.cassandra.distributed.test.trackwarnings.TombstoneCountWarningTest.failThresholdSinglePartition
[ https://issues.apache.org/jira/browse/CASSANDRA-17244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17525239#comment-17525239 ] Ekaterina Dimitrova commented on CASSANDRA-17244: - I saw it again today https://jenkins-cm4.apache.org/job/Cassandra-trunk/1088/testReport/junit/org.apache.cassandra.distributed.test.trackwarnings/TombstoneCountWarningTest/failThresholdSinglePartition/ > Fix > org.apache.cassandra.distributed.test.trackwarnings.TombstoneCountWarningTest.failThresholdSinglePartition > -- > > Key: CASSANDRA-17244 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17244 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.x > > > org.apache.cassandra.distributed.test.trackwarnings.TombstoneCountWarningTest.failThresholdSinglePartition > failed > [here|https://jenkins-cm4.apache.org/job/Cassandra-devbranch/1354/testReport/junit/org.apache.cassandra.distributed.test.trackwarnings/TombstoneCountWarningTest/failThresholdSinglePartition/] > I didn't find any other occurrences but seems to me legit failure. > CC [~dcapwell] as I think you were working on those and probably you will > make better assessment than me. :) -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated: Add teardown to test_cqlsh_completion
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git The following commit(s) were added to refs/heads/trunk by this push: new 0d860ec662 Add teardown to test_cqlsh_completion 0d860ec662 is described below commit 0d860ec662b0088ea7f77f98051121e198eb5692 Author: Brad Schoening <5796692+bschoen...@users.noreply.github.com> AuthorDate: Tue Mar 22 09:41:52 2022 -0400 Add teardown to test_cqlsh_completion Patch by Brad Schoening; reviewed by brandonwilliams and smiklosovic for CASSANDRA-17465 --- pylib/cqlshlib/test/test_unicode.py | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/pylib/cqlshlib/test/test_unicode.py b/pylib/cqlshlib/test/test_unicode.py index 7ec121e4ec..a1e842d437 100644 --- a/pylib/cqlshlib/test/test_unicode.py +++ b/pylib/cqlshlib/test/test_unicode.py @@ -18,7 +18,7 @@ import os from .basecase import BaseTestCase -from .cassconnect import (get_cassandra_connection, create_keyspace, testrun_cqlsh) +from .cassconnect import (get_cassandra_connection, create_keyspace, remove_db, testrun_cqlsh) class TestCqlshUnicode(BaseTestCase): @@ -34,6 +34,10 @@ class TestCqlshUnicode(BaseTestCase): env['LC_CTYPE'] = 'UTF-8' cls.default_env = env +@classmethod +def tearDownClass(cls): +remove_db() + def test_unicode_value_round_trip(self): with testrun_cqlsh(tty=True, env=self.default_env) as c: value = 'ϑΉӁװڜ' - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17465) python unit tests don't cleanup test keyspace
[
https://issues.apache.org/jira/browse/CASSANDRA-17465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17525227#comment-17525227
]
Stefan Miklosovic commented on CASSANDRA-17465:
---
+1.
> python unit tests don't cleanup test keyspace
> -
>
> Key: CASSANDRA-17465
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17465
> Project: Cassandra
> Issue Type: Task
> Components: CQL/Interpreter
>Reporter: Brad Schoening
>Assignee: Brad Schoening
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> The python unit tests in pylib/cqlshlib creates a temporary keyspace
> cqlshtests_, but does not drop it upon completion.
> To reproduce:
> {code:java}
> $ pytest
> $ cqlsh
> cassandra@cqlsh> describe keyspaces
> cqlshtests_oatjjlyyxh ...
> {code}
> The above keyspace, created with a 10 character random suffix, will remain
> after the tests are run. This will then cause subsequent runs of
> test_cqlsh_completion to fail.
>
> {code:java}
> cqlshlib/test/test_cqlsh_completion.py:138: in _trycompletions_inner
> E AssertionError: Items in the second set but not the first:
> E 'cqlshtests_oatjjlyyxh'
> {code}
> test/cassconnect.py;'s remove_db() has the code to perform this, but does not
> seem to be properly called.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17465) python unit tests don't cleanup test keyspace
[
https://issues.apache.org/jira/browse/CASSANDRA-17465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-17465:
--
Status: Ready to Commit (was: Review In Progress)
> python unit tests don't cleanup test keyspace
> -
>
> Key: CASSANDRA-17465
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17465
> Project: Cassandra
> Issue Type: Task
> Components: CQL/Interpreter
>Reporter: Brad Schoening
>Assignee: Brad Schoening
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> The python unit tests in pylib/cqlshlib creates a temporary keyspace
> cqlshtests_, but does not drop it upon completion.
> To reproduce:
> {code:java}
> $ pytest
> $ cqlsh
> cassandra@cqlsh> describe keyspaces
> cqlshtests_oatjjlyyxh ...
> {code}
> The above keyspace, created with a 10 character random suffix, will remain
> after the tests are run. This will then cause subsequent runs of
> test_cqlsh_completion to fail.
>
> {code:java}
> cqlshlib/test/test_cqlsh_completion.py:138: in _trycompletions_inner
> E AssertionError: Items in the second set but not the first:
> E 'cqlshtests_oatjjlyyxh'
> {code}
> test/cassconnect.py;'s remove_db() has the code to perform this, but does not
> seem to be properly called.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17465) python unit tests don't cleanup test keyspace
[
https://issues.apache.org/jira/browse/CASSANDRA-17465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17525216#comment-17525216
]
Stefan Miklosovic commented on CASSANDRA-17465:
---
Ah right I can use Brandon's branch he run the build for.
> python unit tests don't cleanup test keyspace
> -
>
> Key: CASSANDRA-17465
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17465
> Project: Cassandra
> Issue Type: Task
> Components: CQL/Interpreter
>Reporter: Brad Schoening
>Assignee: Brad Schoening
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> The python unit tests in pylib/cqlshlib creates a temporary keyspace
> cqlshtests_, but does not drop it upon completion.
> To reproduce:
> {code:java}
> $ pytest
> $ cqlsh
> cassandra@cqlsh> describe keyspaces
> cqlshtests_oatjjlyyxh ...
> {code}
> The above keyspace, created with a 10 character random suffix, will remain
> after the tests are run. This will then cause subsequent runs of
> test_cqlsh_completion to fail.
>
> {code:java}
> cqlshlib/test/test_cqlsh_completion.py:138: in _trycompletions_inner
> E AssertionError: Items in the second set but not the first:
> E 'cqlshtests_oatjjlyyxh'
> {code}
> test/cassconnect.py;'s remove_db() has the code to perform this, but does not
> seem to be properly called.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17465) python unit tests don't cleanup test keyspace
[
https://issues.apache.org/jira/browse/CASSANDRA-17465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17525215#comment-17525215
]
Stefan Miklosovic commented on CASSANDRA-17465:
---
I am not able to fetch Brad' branch as the repository that PR was created from
does not exist anymore and I think that is the reason why PR was automatically
closed as well.
> python unit tests don't cleanup test keyspace
> -
>
> Key: CASSANDRA-17465
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17465
> Project: Cassandra
> Issue Type: Task
> Components: CQL/Interpreter
>Reporter: Brad Schoening
>Assignee: Brad Schoening
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> The python unit tests in pylib/cqlshlib creates a temporary keyspace
> cqlshtests_, but does not drop it upon completion.
> To reproduce:
> {code:java}
> $ pytest
> $ cqlsh
> cassandra@cqlsh> describe keyspaces
> cqlshtests_oatjjlyyxh ...
> {code}
> The above keyspace, created with a 10 character random suffix, will remain
> after the tests are run. This will then cause subsequent runs of
> test_cqlsh_completion to fail.
>
> {code:java}
> cqlshlib/test/test_cqlsh_completion.py:138: in _trycompletions_inner
> E AssertionError: Items in the second set but not the first:
> E 'cqlshtests_oatjjlyyxh'
> {code}
> test/cassconnect.py;'s remove_db() has the code to perform this, but does not
> seem to be properly called.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16456) Add Plugin Support for CQLSH
[ https://issues.apache.org/jira/browse/CASSANDRA-16456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17525211#comment-17525211 ] Stefan Miklosovic commented on CASSANDRA-16456: --- Thanks [~bhouser]. [~Bowen Song] Would you have some time to look at the most recent state of Brian's branch, please? I would really appreciate it, I think we are almost at the end. > Add Plugin Support for CQLSH > > > Key: CASSANDRA-16456 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16456 > Project: Cassandra > Issue Type: New Feature > Components: Tool/cqlsh >Reporter: Brian Houser >Assignee: Brian Houser >Priority: Normal > Labels: gsoc2021, mentor > Time Spent: 2h 10m > Remaining Estimate: 0h > > Currently the Cassandra drivers offer a plugin authenticator architecture for > the support of different authentication methods. This has been leveraged to > provide support for LDAP, Kerberos, and Sigv4 authentication. Unfortunately, > cqlsh, the included CLI tool, does not offer such support. Switching to a new > enhanced authentication scheme thus means being cut off from using cqlsh in > normal operation. > We should have a means of using the same plugins and authentication providers > as the Python Cassandra driver. > Here's a link to an initial draft of > [CEP|https://docs.google.com/document/d/1_G-OZCAEmDyuQuAN2wQUYUtZBEJpMkHWnkYELLhqvKc/edit?usp=sharing]. -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17563) Fix CircleCI Midres config
[ https://issues.apache.org/jira/browse/CASSANDRA-17563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17525209#comment-17525209 ] David Capwell commented on CASSANDRA-17563: --- don't know why but attempt 2 wasn't on the updated commit, MIDRES attempt 3: https://app.circleci.com/pipelines/github/dcapwell/cassandra/1370/workflows/96cb49ae-1bad-4412-a04a-3431a66cd641 > Fix CircleCI Midres config > -- > > Key: CASSANDRA-17563 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17563 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Ekaterina Dimitrova >Priority: Normal > > During CircleCI addition of a new job to the config, the midres file got > messy. Two of the immediate issues (but we need to verify all jobs will use > the right executors and resources): > * the new job needs to use higher parallelism as the original in-jvm job > * j8_dtests_with_vnodes should get from midres 50 large but currently > midres makes it run with 25 and medium which fails around 100 tests -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17563) Fix CircleCI Midres config
[ https://issues.apache.org/jira/browse/CASSANDRA-17563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17525204#comment-17525204 ] Ekaterina Dimitrova commented on CASSANDRA-17563: - * "highers" should be "highres" everywhere, same "lowers" should be "lowres" * I believe there is some forgotten commented out code * we need to update readme * we need to verify all branches * we need to verify this works smoothly also with highres These are immediate comments. I will check in detail the midres config after CI shows good results. By the way the new link leads to a canceled CI run > Fix CircleCI Midres config > -- > > Key: CASSANDRA-17563 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17563 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Ekaterina Dimitrova >Priority: Normal > > During CircleCI addition of a new job to the config, the midres file got > messy. Two of the immediate issues (but we need to verify all jobs will use > the right executors and resources): > * the new job needs to use higher parallelism as the original in-jvm job > * j8_dtests_with_vnodes should get from midres 50 large but currently > midres makes it run with 25 and medium which fails around 100 tests -- This message was sent by Atlassian Jira (v8.20.7#820007) - 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 (731de59a -> 71198120)
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 731de59a generate docs for b7ad0c5f new 71198120 generate docs for b7ad0c5f 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 (731de59a) \ N -- N -- N refs/heads/asf-staging (71198120) 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/doc/4.1/cassandra/new/configuration.html | 30 ++--- .../doc/latest/cassandra/new/configuration.html| 30 ++--- content/doc/trunk/cassandra/new/configuration.html | 30 ++--- content/search-index.js| 2 +- site-ui/build/ui-bundle.zip| Bin 4740078 -> 4740078 bytes 5 files changed, 64 insertions(+), 28 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17563) Fix CircleCI Midres config
[ https://issues.apache.org/jira/browse/CASSANDRA-17563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-17563: Reviewers: Ekaterina Dimitrova, Ekaterina Dimitrova Ekaterina Dimitrova, Ekaterina Dimitrova (was: Ekaterina Dimitrova) Status: Review In Progress (was: Patch Available) > Fix CircleCI Midres config > -- > > Key: CASSANDRA-17563 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17563 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Ekaterina Dimitrova >Priority: Normal > > During CircleCI addition of a new job to the config, the midres file got > messy. Two of the immediate issues (but we need to verify all jobs will use > the right executors and resources): > * the new job needs to use higher parallelism as the original in-jvm job > * j8_dtests_with_vnodes should get from midres 50 large but currently > midres makes it run with 25 and medium which fails around 100 tests -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17563) Fix CircleCI Midres config
[ https://issues.apache.org/jira/browse/CASSANDRA-17563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17525173#comment-17525173 ] David Capwell commented on CASSANDRA-17563: --- MIDRES attempt 2 (missing new script): https://app.circleci.com/pipelines/github/dcapwell/cassandra/1368/workflows/41c514ca-1435-4e71-b808-f848b375b268 > Fix CircleCI Midres config > -- > > Key: CASSANDRA-17563 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17563 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Ekaterina Dimitrova >Priority: Normal > > During CircleCI addition of a new job to the config, the midres file got > messy. Two of the immediate issues (but we need to verify all jobs will use > the right executors and resources): > * the new job needs to use higher parallelism as the original in-jvm job > * j8_dtests_with_vnodes should get from midres 50 large but currently > midres makes it run with 25 and medium which fails around 100 tests -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17563) Fix CircleCI Midres config
[ https://issues.apache.org/jira/browse/CASSANDRA-17563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17525162#comment-17525162 ] David Capwell commented on CASSANDRA-17563: --- MIDRES: https://app.circleci.com/pipelines/github/dcapwell/cassandra/1367/workflows/43edfcf2-229f-4650-874b-bc1faccf77af > Fix CircleCI Midres config > -- > > Key: CASSANDRA-17563 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17563 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Ekaterina Dimitrova >Priority: Normal > > During CircleCI addition of a new job to the config, the midres file got > messy. Two of the immediate issues (but we need to verify all jobs will use > the right executors and resources): > * the new job needs to use higher parallelism as the original in-jvm job > * j8_dtests_with_vnodes should get from midres 50 large but currently > midres makes it run with 25 and medium which fails around 100 tests -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17563) Fix CircleCI Midres config
[ https://issues.apache.org/jira/browse/CASSANDRA-17563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-17563: -- Authors: David Capwell Test and Documentation Plan: validated the diff matches resources as of commit 20175bf77e2c6f72c25240ee445b583805a37630, before the vnode changes were merged Status: Patch Available (was: Open) > Fix CircleCI Midres config > -- > > Key: CASSANDRA-17563 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17563 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Ekaterina Dimitrova >Priority: Normal > > During CircleCI addition of a new job to the config, the midres file got > messy. Two of the immediate issues (but we need to verify all jobs will use > the right executors and resources): > * the new job needs to use higher parallelism as the original in-jvm job > * j8_dtests_with_vnodes should get from midres 50 large but currently > midres makes it run with 25 and medium which fails around 100 tests -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17544) Add EnableFlag to guardrails API
[
https://issues.apache.org/jira/browse/CASSANDRA-17544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bernardo Botella Corbi updated CASSANDRA-17544:
---
Test and Documentation Plan:
||PR||
|[trunk|https://github.com/apache/cassandra/pull/1573]|
Status: Patch Available (was: In Progress)
> Add EnableFlag to guardrails API
>
>
> Key: CASSANDRA-17544
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17544
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Guardrails
>Reporter: Josh McKenzie
>Assignee: Bernardo Botella Corbi
>Priority: Low
> Fix For: 4.1
>
>
> Currently we only have a DisableFlag which, for guardrails where we're
> enabling or disabling a feature, leads to some pretty odd ergonomics in the
> code. For example:
>
> {code:java}
> public static final DisableFlag compactTablesEnabled =
> new DisableFlag("compact_tables",
> state ->
> !CONFIG_PROVIDER.getOrCreate(state).getCompactTablesEnabled(),
> "Creation of new COMPACT STORAGE tables"); {code}
> So far, the usage of these toggle flags appears to be skewed heavily towards
> the inverse, or an EnableFlag that'd look something like this:
> {code:java}
> public static final EnableFlag featureEnabled = new
> EnableFlag("feature_name", state ->
> CONFIG_PROVIDER.getOrCreate(state).getCompactTablesEnabled(), "Text for
> feature"); {code}
> While it's a relatively small change it'll help tidy up some of the
> guardrails framework and make the logic clearer.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17544) Add EnableFlag to guardrails API
[
https://issues.apache.org/jira/browse/CASSANDRA-17544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bernardo Botella Corbi updated CASSANDRA-17544:
---
Change Category: Code Clarity
Complexity: Low Hanging Fruit
Component/s: Feature/Guardrails
Fix Version/s: 4.1
Mentor: Yifan Cai
Priority: Low (was: Normal)
Status: Open (was: Triage Needed)
> Add EnableFlag to guardrails API
>
>
> Key: CASSANDRA-17544
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17544
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Guardrails
>Reporter: Josh McKenzie
>Assignee: Bernardo Botella Corbi
>Priority: Low
> Fix For: 4.1
>
>
> Currently we only have a DisableFlag which, for guardrails where we're
> enabling or disabling a feature, leads to some pretty odd ergonomics in the
> code. For example:
>
> {code:java}
> public static final DisableFlag compactTablesEnabled =
> new DisableFlag("compact_tables",
> state ->
> !CONFIG_PROVIDER.getOrCreate(state).getCompactTablesEnabled(),
> "Creation of new COMPACT STORAGE tables"); {code}
> So far, the usage of these toggle flags appears to be skewed heavily towards
> the inverse, or an EnableFlag that'd look something like this:
> {code:java}
> public static final EnableFlag featureEnabled = new
> EnableFlag("feature_name", state ->
> CONFIG_PROVIDER.getOrCreate(state).getCompactTablesEnabled(), "Text for
> feature"); {code}
> While it's a relatively small change it'll help tidy up some of the
> guardrails framework and make the logic clearer.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17150) Guardrails for disk usage
[
https://issues.apache.org/jira/browse/CASSANDRA-17150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17525146#comment-17525146
]
Ekaterina Dimitrova edited comment on CASSANDRA-17150 at 4/20/22 5:40 PM:
--
I see my review comments addressed and I don't have any concerns about this
patch.
Thank you for your work!
Also, I saw you added system property for the min notifying interval, as we
talked. Thanks!
Left just two super small comments to be addressed on commit after green(no new
failures after this patch) CI of course :D
was (Author: e.dimitrova):
I see my review comments addressed and I don't have any concerns about this
patch.
Thank you for your work!
Also, I saw you added system property for the min notifying interval, as we
talked. Thanks!
Left just two super small comments to be addressed on commit after green(ish)
CI of course :D
> Guardrails for disk usage
> -
>
> Key: CASSANDRA-17150
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17150
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 7h 10m
> Remaining Estimate: 0h
>
> Add guardrails for disk usage establishing soft/hard limits on the percentage
> of used disk space. For example:
> {code}
> # Warning threshold to warn when local disk usage exceeds threshold. Valid
> values: (1, 100]
> # Defaults to -1 to disable.
> # disk_usage_percentage_warn_threshold: -1
> # Failure threshold to reject write requests if replica disk usage exceeds
> threshold. Valid values: (1, 100]
> # Defaults to -1 to disable.
> # disk_usage_percentage_failure_threshold: -1
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17150) Guardrails for disk usage
[
https://issues.apache.org/jira/browse/CASSANDRA-17150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17525146#comment-17525146
]
Ekaterina Dimitrova commented on CASSANDRA-17150:
-
I see my review comments addressed and I don't have any concerns about this
patch.
Thank you for your work!
Also, I saw you added system property for the min notifying interval, as we
talked. Thanks!
Left just two super small comments to be addressed on commit after green(ish)
CI of course :D
> Guardrails for disk usage
> -
>
> Key: CASSANDRA-17150
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17150
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 7h 10m
> Remaining Estimate: 0h
>
> Add guardrails for disk usage establishing soft/hard limits on the percentage
> of used disk space. For example:
> {code}
> # Warning threshold to warn when local disk usage exceeds threshold. Valid
> values: (1, 100]
> # Defaults to -1 to disable.
> # disk_usage_percentage_warn_threshold: -1
> # Failure threshold to reject write requests if replica disk usage exceeds
> threshold. Valid values: (1, 100]
> # Defaults to -1 to disable.
> # disk_usage_percentage_failure_threshold: -1
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-11871) Allow to aggregate by time intervals
[
https://issues.apache.org/jira/browse/CASSANDRA-11871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17525129#comment-17525129
]
Andres de la Peña commented on CASSANDRA-11871:
---
Oh, right, the CI run is the one in the edited comment above, I saw the
22/Mar/22 date and ignored it :)
> Allow to aggregate by time intervals
>
>
> Key: CASSANDRA-11871
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11871
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/CQL
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 3h 10m
> Remaining Estimate: 0h
>
> For time series data it can be usefull to aggregate by time intervals.
> The idea would be to add support for one or several functions in the {{GROUP
> BY}} clause.
> Regarding the implementation, even if in general I also prefer to follow the
> SQL syntax, I do not believe it will be a good fit for Cassandra.
> If we have a table like:
> {code}
> CREATE TABLE trades
> {
> symbol text,
> date date,
> time time,
> priceMantissa int,
> priceExponent tinyint,
> volume int,
> PRIMARY KEY ((symbol, date), time)
> };
> {code}
> The trades will be inserted with an increasing time and sorted in the same
> order. As we can have to process a large amount of data, we want to try to
> limit ourself to the cases where we can build the groups on the flight (which
> is not a requirement in the SQL world).
> If we want to get the number of trades per minutes with the SQL syntax we
> will have to write:
> {{SELECT hour(time), minute(time), count() FROM Trades WHERE symbol = 'AAPL'
> AND date = '2016-01-11' GROUP BY hour(time), minute(time);}}
> which is fine. The problem is that if the user invert by mistake the
> functions like that:
> {{SELECT hour(time), minute(time), count() FROM Trades WHERE symbol = 'AAPL'
> AND date = '2016-01-11' GROUP BY minute(time), hour(time);}}
> the query will return weird results.
> The only way to prevent that would be to check the function order and make
> sure that we do not allow to skip functions (e.g. {{GROUP BY hour(time),
> second(time)}}).
> In my opinion a function like {{floor(, )}} will be
> much better as it does not allow for this type of mistakes and is much more
> flexible (you can create 5 minutes buckets if you want to).
> {{SELECT floor(time, m), count() FROM Trades WHERE symbol = 'AAPL' AND date =
> '2016-01-11' GROUP BY floor(time, m);}}
> An important aspect to keep in mind with a function like {{floor}} is the
> starting point. For a query like: {{SELECT floor(time, m), count() FROM
> Trades WHERE symbol = 'AAPL' AND date = '2016-01-11' AND time >= '01:30:00'
> AND time =< '07:30:00' GROUP BY floor(time, 2h);}}, I think that ideally the
> result should return 3 groups: {{01:30:00}}, {{03:30:00}} and {{05:30:00}}.
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17567) Add Documentation for new CQLSH Auth_provider functionality
Brian Houser created CASSANDRA-17567: Summary: Add Documentation for new CQLSH Auth_provider functionality Key: CASSANDRA-17567 URL: https://issues.apache.org/jira/browse/CASSANDRA-17567 Project: Cassandra Issue Type: Sub-task Components: Documentation, Documentation/Website Reporter: Brian Houser There is now new functionality to support loading auth providers dynamically from CQLSH. see https://issues.apache.org/jira/browse/CASSANDRA-16456 Add documentation to detail this in the website / asciidoc. -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-11871) Allow to aggregate by time intervals
[
https://issues.apache.org/jira/browse/CASSANDRA-11871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17525126#comment-17525126
]
Andres de la Peña commented on CASSANDRA-11871:
---
The last changes look good to me, do we have a CI run? I have started repeated
runs on the new dtest
[here|https://app.circleci.com/pipelines/github/adelapena/cassandra/1489/workflows/69aa3811-676c-42e9-9aba-b5b2b2be0d06]
and
[here|https://app.circleci.com/pipelines/github/adelapena/cassandra/1489/workflows/c4d9bcbb-8d9b-4b44-8c75-eb2bfe2c2231].
> Allow to aggregate by time intervals
>
>
> Key: CASSANDRA-11871
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11871
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/CQL
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 3h 10m
> Remaining Estimate: 0h
>
> For time series data it can be usefull to aggregate by time intervals.
> The idea would be to add support for one or several functions in the {{GROUP
> BY}} clause.
> Regarding the implementation, even if in general I also prefer to follow the
> SQL syntax, I do not believe it will be a good fit for Cassandra.
> If we have a table like:
> {code}
> CREATE TABLE trades
> {
> symbol text,
> date date,
> time time,
> priceMantissa int,
> priceExponent tinyint,
> volume int,
> PRIMARY KEY ((symbol, date), time)
> };
> {code}
> The trades will be inserted with an increasing time and sorted in the same
> order. As we can have to process a large amount of data, we want to try to
> limit ourself to the cases where we can build the groups on the flight (which
> is not a requirement in the SQL world).
> If we want to get the number of trades per minutes with the SQL syntax we
> will have to write:
> {{SELECT hour(time), minute(time), count() FROM Trades WHERE symbol = 'AAPL'
> AND date = '2016-01-11' GROUP BY hour(time), minute(time);}}
> which is fine. The problem is that if the user invert by mistake the
> functions like that:
> {{SELECT hour(time), minute(time), count() FROM Trades WHERE symbol = 'AAPL'
> AND date = '2016-01-11' GROUP BY minute(time), hour(time);}}
> the query will return weird results.
> The only way to prevent that would be to check the function order and make
> sure that we do not allow to skip functions (e.g. {{GROUP BY hour(time),
> second(time)}}).
> In my opinion a function like {{floor(, )}} will be
> much better as it does not allow for this type of mistakes and is much more
> flexible (you can create 5 minutes buckets if you want to).
> {{SELECT floor(time, m), count() FROM Trades WHERE symbol = 'AAPL' AND date =
> '2016-01-11' GROUP BY floor(time, m);}}
> An important aspect to keep in mind with a function like {{floor}} is the
> starting point. For a query like: {{SELECT floor(time, m), count() FROM
> Trades WHERE symbol = 'AAPL' AND date = '2016-01-11' AND time >= '01:30:00'
> AND time =< '07:30:00' GROUP BY floor(time, 2h);}}, I think that ideally the
> result should return 3 groups: {{01:30:00}}, {{03:30:00}} and {{05:30:00}}.
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17465) python unit tests don't cleanup test keyspace
[
https://issues.apache.org/jira/browse/CASSANDRA-17465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17525099#comment-17525099
]
Brad Schoening commented on CASSANDRA-17465:
Note: Other tests, test_cqlsh_completion.py and test_cqlsh_output.py properly
call remove_db in tearDownClass. This test is simply missing it.
> python unit tests don't cleanup test keyspace
> -
>
> Key: CASSANDRA-17465
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17465
> Project: Cassandra
> Issue Type: Task
> Components: CQL/Interpreter
>Reporter: Brad Schoening
>Assignee: Brad Schoening
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> The python unit tests in pylib/cqlshlib creates a temporary keyspace
> cqlshtests_, but does not drop it upon completion.
> To reproduce:
> {code:java}
> $ pytest
> $ cqlsh
> cassandra@cqlsh> describe keyspaces
> cqlshtests_oatjjlyyxh ...
> {code}
> The above keyspace, created with a 10 character random suffix, will remain
> after the tests are run. This will then cause subsequent runs of
> test_cqlsh_completion to fail.
>
> {code:java}
> cqlshlib/test/test_cqlsh_completion.py:138: in _trycompletions_inner
> E AssertionError: Items in the second set but not the first:
> E 'cqlshtests_oatjjlyyxh'
> {code}
> test/cassconnect.py;'s remove_db() has the code to perform this, but does not
> seem to be properly called.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17212) Migrate threshold for minimum keyspace replication factor to guardrails
[
https://issues.apache.org/jira/browse/CASSANDRA-17212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17525098#comment-17525098
]
Josh McKenzie commented on CASSANDRA-17212:
---
{quote}system key spaces are included in this check
{quote}
[~adelapena] - similar to how we exclude superusers from guardrails applying to
them, maybe we should consider excluding all system keyspaces from their
application by default as well?
> Migrate threshold for minimum keyspace replication factor to guardrails
> ---
>
> Key: CASSANDRA-17212
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17212
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Assignee: Savni Nagarkar
>Priority: Normal
> Fix For: 4.x
>
>
> The config property
> [{{minimum_keyspace_rf}}|https://github.com/apache/cassandra/blob/5fdadb25f95099b8945d9d9ee11d3e380d3867f4/conf/cassandra.yaml]
> that was added by CASSANDRA-14557 can be migrated to guardrails, for example:
> {code}
> guardrails:
> ...
> replication_factor:
> warn_threshold: 2
> abort_threshold: 3
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17465) python unit tests don't cleanup test keyspace
[
https://issues.apache.org/jira/browse/CASSANDRA-17465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17525079#comment-17525079
]
Brandon Williams commented on CASSANDRA-17465:
--
LGTM, +1
> python unit tests don't cleanup test keyspace
> -
>
> Key: CASSANDRA-17465
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17465
> Project: Cassandra
> Issue Type: Task
> Components: CQL/Interpreter
>Reporter: Brad Schoening
>Assignee: Brad Schoening
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> The python unit tests in pylib/cqlshlib creates a temporary keyspace
> cqlshtests_, but does not drop it upon completion.
> To reproduce:
> {code:java}
> $ pytest
> $ cqlsh
> cassandra@cqlsh> describe keyspaces
> cqlshtests_oatjjlyyxh ...
> {code}
> The above keyspace, created with a 10 character random suffix, will remain
> after the tests are run. This will then cause subsequent runs of
> test_cqlsh_completion to fail.
>
> {code:java}
> cqlshlib/test/test_cqlsh_completion.py:138: in _trycompletions_inner
> E AssertionError: Items in the second set but not the first:
> E 'cqlshtests_oatjjlyyxh'
> {code}
> test/cassconnect.py;'s remove_db() has the code to perform this, but does not
> seem to be properly called.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17566) Fix flaky test - org.apache.cassandra.distributed.test.repair.ForceRepairTest.force
[ https://issues.apache.org/jira/browse/CASSANDRA-17566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-17566: - Bug Category: Parent values: Correctness(12982)Level 1 values: Test Failure(12990) Complexity: Normal Component/s: Test/dtest/java Discovered By: DTest Fix Version/s: 4.x Severity: Normal Status: Open (was: Triage Needed) > Fix flaky test - > org.apache.cassandra.distributed.test.repair.ForceRepairTest.force > --- > > Key: CASSANDRA-17566 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17566 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest/java >Reporter: Brandon Williams >Priority: Normal > Fix For: 4.x > > > Seen on jenkins here: > [https://ci-cassandra.apache.org/job/Cassandra-trunk/1083/testReport/org.apache.cassandra.distributed.test.repair/ForceRepairTest/force_2/] > > and circle here: > https://app.circleci.com/pipelines/github/driftx/cassandra/440/workflows/42f936c7-2ede-4fbf-957c-5fb4e461dd90/jobs/5160/tests#failed-test-1 -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17566) Fix flaky test - org.apache.cassandra.distributed.test.repair.ForceRepairTest.force
[
https://issues.apache.org/jira/browse/CASSANDRA-17566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-17566:
-
Description:
Seen on jenkins here:
[https://ci-cassandra.apache.org/job/Cassandra-trunk/1083/testReport/org.apache.cassandra.distributed.test.repair/ForceRepairTest/force_2/]
and circle here:
https://app.circleci.com/pipelines/github/driftx/cassandra/440/workflows/42f936c7-2ede-4fbf-957c-5fb4e461dd90/jobs/5160/tests#failed-test-1
{noformat}
junit.framework.AssertionFailedError: nodetool command [repair,
distributed_test_keyspace, --force, --full] was not successful
stdout:
[2022-04-20 15:11:01,402] Starting repair command #2
(1701a090-c0bc-11ec-9898-07c796ce6a49), repairing keyspace
distributed_test_keyspace with repair options (parallelism: parallel, primary
range: false, incremental: false, job threads: 1, ColumnFamilies: [],
dataCenters: [], hosts: [], previewKind: NONE, # of ranges: 3, pull repair:
false, force repair: true, optimise streams: false, ignore unreplicated
keyspaces: false, repairPaxos: true, paxosOnly: false)
[2022-04-20 15:11:11,406] Repair command #2 failed with error Did not get
replies from all endpoints.
[2022-04-20 15:11:11,408] Repair command #2 finished with error
stderr:
error: Repair job has failed with the error message: Repair command #2 failed
with error Did not get replies from all endpoints.. Check the logs on the
repair participants for further details
-- StackTrace --
java.lang.RuntimeException: Repair job has failed with the error message:
Repair command #2 failed with error Did not get replies from all endpoints..
Check the logs on the repair participants for further details
at
org.apache.cassandra.tools.RepairRunner.progress(RepairRunner.java:137)
at
org.apache.cassandra.utils.progress.jmx.JMXNotificationProgressListener.handleNotification(JMXNotificationProgressListener.java:77)
at
javax.management.NotificationBroadcasterSupport.handleNotification(NotificationBroadcasterSupport.java:275)
at
javax.management.NotificationBroadcasterSupport$SendNotifJob.run(NotificationBroadcasterSupport.java:352)
at
org.apache.cassandra.concurrent.ExecutionFailure$1.run(ExecutionFailure.java:124)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at
io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
at java.lang.Thread.run(Thread.java:748)
{noformat}
was:
Seen on jenkins here:
[https://ci-cassandra.apache.org/job/Cassandra-trunk/1083/testReport/org.apache.cassandra.distributed.test.repair/ForceRepairTest/force_2/]
and circle here:
https://app.circleci.com/pipelines/github/driftx/cassandra/440/workflows/42f936c7-2ede-4fbf-957c-5fb4e461dd90/jobs/5160/tests#failed-test-1
> Fix flaky test -
> org.apache.cassandra.distributed.test.repair.ForceRepairTest.force
> ---
>
> Key: CASSANDRA-17566
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17566
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: Brandon Williams
>Priority: Normal
> Fix For: 4.x
>
>
> Seen on jenkins here:
> [https://ci-cassandra.apache.org/job/Cassandra-trunk/1083/testReport/org.apache.cassandra.distributed.test.repair/ForceRepairTest/force_2/]
>
> and circle here:
> https://app.circleci.com/pipelines/github/driftx/cassandra/440/workflows/42f936c7-2ede-4fbf-957c-5fb4e461dd90/jobs/5160/tests#failed-test-1
> {noformat}
> junit.framework.AssertionFailedError: nodetool command [repair,
> distributed_test_keyspace, --force, --full] was not successful
> stdout:
> [2022-04-20 15:11:01,402] Starting repair command #2
> (1701a090-c0bc-11ec-9898-07c796ce6a49), repairing keyspace
> distributed_test_keyspace with repair options (parallelism: parallel, primary
> range: false, incremental: false, job threads: 1, ColumnFamilies: [],
> dataCenters: [], hosts: [], previewKind: NONE, # of ranges: 3, pull repair:
> false, force repair: true, optimise streams: false, ignore unreplicated
> keyspaces: false, repairPaxos: true, paxosOnly: false)
> [2022-04-20 15:11:11,406] Repair command #2 failed with error Did not get
> replies from all endpoints.
> [2022-04-20 15:11:11,408] Repair command #2 finished with error
> stderr:
> error: Repair job has failed with the error message: Repair command #2 failed
> with error Did not get replies from all endpoints.. Check the logs on the
> repair participants for further details
> -- StackTrace --
> java.lang.RuntimeException: Repair job has failed with the error message:
> Repair command #2 failed with error
[jira] [Created] (CASSANDRA-17566) Fix flaky test - org.apache.cassandra.distributed.test.repair.ForceRepairTest.force
Brandon Williams created CASSANDRA-17566: Summary: Fix flaky test - org.apache.cassandra.distributed.test.repair.ForceRepairTest.force Key: CASSANDRA-17566 URL: https://issues.apache.org/jira/browse/CASSANDRA-17566 Project: Cassandra Issue Type: Bug Reporter: Brandon Williams Seen on jenkins here: [https://ci-cassandra.apache.org/job/Cassandra-trunk/1083/testReport/org.apache.cassandra.distributed.test.repair/ForceRepairTest/force_2/] and circle here: https://app.circleci.com/pipelines/github/driftx/cassandra/440/workflows/42f936c7-2ede-4fbf-957c-5fb4e461dd90/jobs/5160/tests#failed-test-1 -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17431) Move the rest of the Config parameters to the new Config framework
[ https://issues.apache.org/jira/browse/CASSANDRA-17431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17525065#comment-17525065 ] Ekaterina Dimitrova commented on CASSANDRA-17431: - Ticket for the flaky test was opened CASSANDRA-17565 > Move the rest of the Config parameters to the new Config framework > -- > > Key: CASSANDRA-17431 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17431 > Project: Cassandra > Issue Type: Task > Components: Local/Config >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.1 > > > Migrate also all Config parameters that are in Config, but not presented in > cassandra.yaml to the new config framework. Not presented in the yaml as they > are considered advanced only for advanced users. -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-17565) Fix test_parallel_upgrade_with_internode_ssl
[ https://issues.apache.org/jira/browse/CASSANDRA-17565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams reassigned CASSANDRA-17565: Assignee: Brandon Williams > Fix test_parallel_upgrade_with_internode_ssl > > > Key: CASSANDRA-17565 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17565 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Brandon Williams >Priority: Normal > Fix For: 4.x > > > While working on CASSANDRA-17341 I hit this flaky test, very rarely failing > but it is failing on trunk. > More info in this CI run: > https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1563/workflows/61bda0b7-f699-4897-877f-c7d523a03127/jobs/10318 -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17565) Fix test_parallel_upgrade_with_internode_ssl
[ https://issues.apache.org/jira/browse/CASSANDRA-17565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17525063#comment-17525063 ] Ekaterina Dimitrova commented on CASSANDRA-17565: - CC [~brandon.williams] :) > Fix test_parallel_upgrade_with_internode_ssl > > > Key: CASSANDRA-17565 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17565 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.x > > > While working on CASSANDRA-17341 I hit this flaky test, very rarely failing > but it is failing on trunk. > More info in this CI run: > https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1563/workflows/61bda0b7-f699-4897-877f-c7d523a03127/jobs/10318 -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17565) Fix test_parallel_upgrade_with_internode_ssl
[ https://issues.apache.org/jira/browse/CASSANDRA-17565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-17565: Fix Version/s: 4.x > Fix test_parallel_upgrade_with_internode_ssl > > > Key: CASSANDRA-17565 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17565 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.x > > > While working on CASSANDRA-17341 I hit this flaky test, very rarely failing > but it is failing on trunk. > More info in this CI run: > https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1563/workflows/61bda0b7-f699-4897-877f-c7d523a03127/jobs/10318 -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17565) Fix test_parallel_upgrade_with_internode_ssl
Ekaterina Dimitrova created CASSANDRA-17565: --- Summary: Fix test_parallel_upgrade_with_internode_ssl Key: CASSANDRA-17565 URL: https://issues.apache.org/jira/browse/CASSANDRA-17565 Project: Cassandra Issue Type: Bug Reporter: Ekaterina Dimitrova While working on CASSANDRA-17341 I hit this flaky test, very rarely failing but it is failing on trunk. More info in this CI run: https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1563/workflows/61bda0b7-f699-4897-877f-c7d523a03127/jobs/10318 -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17565) Fix test_parallel_upgrade_with_internode_ssl
[ https://issues.apache.org/jira/browse/CASSANDRA-17565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-17565: Bug Category: Parent values: Correctness(12982) Complexity: Normal Component/s: CI Discovered By: User Report Severity: Normal Status: Open (was: Triage Needed) > Fix test_parallel_upgrade_with_internode_ssl > > > Key: CASSANDRA-17565 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17565 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Ekaterina Dimitrova >Priority: Normal > > While working on CASSANDRA-17341 I hit this flaky test, very rarely failing > but it is failing on trunk. > More info in this CI run: > https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1563/workflows/61bda0b7-f699-4897-877f-c7d523a03127/jobs/10318 -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17180) Implement startup check to prevent Cassandra start to spread zombie data
[ https://issues.apache.org/jira/browse/CASSANDRA-17180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-17180: -- Status: Patch Available (was: In Progress) > Implement startup check to prevent Cassandra start to spread zombie data > > > Key: CASSANDRA-17180 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17180 > Project: Cassandra > Issue Type: New Feature > Components: Legacy/Observability >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Time Spent: 9.5h > Remaining Estimate: 0h > > As already discussed on ML, it would be nice to have a service which would > periodically write timestamp to a file signalling it is up / running. > Then, on the startup, we would read this file and we would determine if there > is some table which gc grace is behind this time and we would fail the start > so we would prevent zombie data to be likely spread around a cluster. > https://lists.apache.org/thread/w4w5t2hlcrvqhgdwww61hgg58qz13glw -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17180) Implement startup check to prevent Cassandra start to spread zombie data
[ https://issues.apache.org/jira/browse/CASSANDRA-17180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17525057#comment-17525057 ] Stefan Miklosovic edited comment on CASSANDRA-17180 at 4/20/22 3:05 PM: Changes from the last review: 1) added prefix "check_" to checks in the configuration 2) updated documentation in cassandra.yaml 3) fixed retrieval of table metadata 4) ignoring tables which have gc = 0 (system_traces have conveniently gc = 0 so ignoring 0 in general will ignore this too). 5) moved heartbeating scheduling after checks are done 6) renamed default name of heartbeat file from ".cassandra-heartbeat" to "cassandra-heartbeat" (it is not hidden anymore). I did no modification when calling of SchemaKeyspace#fetchNonSystemKeyspaces expect making it public. This method will not return "system" and "system_schema" keyspaces. The logic will filter "system_traces". On the other hand, it will check tables in "system_distributed" as well as "system_auth". These tables do not have gc = 0 and they are not excluded from fetchNonSystemKeyspaces call. I am not operationally strong enough to evaluate if we should exclude other system keyspaces I have mentioned above. was (Author: smiklosovic): Changes from the last review: 1) added prefix "check_" to checks in the configuration 2) updated documentation in cassandra.yaml 3) fixed retrieval of table metadata 4) ignoring tables which have gc = 0 5) moved heartbeating scheduling after checks are done 6) renamed default name of heartbeat file from ".cassandra-heartbeat" to "cassandra-heartbeat" (it is not hidden anymore). > Implement startup check to prevent Cassandra start to spread zombie data > > > Key: CASSANDRA-17180 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17180 > Project: Cassandra > Issue Type: New Feature > Components: Legacy/Observability >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Time Spent: 9.5h > Remaining Estimate: 0h > > As already discussed on ML, it would be nice to have a service which would > periodically write timestamp to a file signalling it is up / running. > Then, on the startup, we would read this file and we would determine if there > is some table which gc grace is behind this time and we would fail the start > so we would prevent zombie data to be likely spread around a cluster. > https://lists.apache.org/thread/w4w5t2hlcrvqhgdwww61hgg58qz13glw -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17564) Add synchronization to wait for outstanding tasks in the compaction executor and nonPeriodicTasks during CassandraDaemon setup
[
https://issues.apache.org/jira/browse/CASSANDRA-17564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-17564:
-
Change Category: Operability
Complexity: Normal
Fix Version/s: 3.11.x
4.0.x
Status: Open (was: Triage Needed)
> Add synchronization to wait for outstanding tasks in the compaction executor
> and nonPeriodicTasks during CassandraDaemon setup
> --
>
> Key: CASSANDRA-17564
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17564
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Compaction
>Reporter: Haoze Wu
>Priority: Normal
> Fix For: 3.11.x, 4.0.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We have been testing Cassandra 3.11.10 for a while. During a node start, we
> found that a synchronization guarantee implied by the code comments is not
> enforced. Specifically, in the `invalidate` method called in this call stack
> (in version 3.11.10):
> {code:java}
> org.apache.cassandra.service.CassandraDaemon#main:786
> org.apache.cassandra.service.CassandraDaemon#activate:633
> org.apache.cassandra.service.CassandraDaemon#setup:261
> org.apache.cassandra.schema.LegacySchemaMigrator#migrate:83
> org.apache.cassandra.schema.LegacySchemaMigrator#unloadLegacySchemaTables:137
> java.lang.Iterable#forEach:75
> org.apache.cassandra.schema.LegacySchemaMigrator#lambda$unloadLegacySchemaTables$1:137
> org.apache.cassandra.db.ColumnFamilyStore#invalidate:542 {code}
> In line 564~570 within `public void invalidate(boolean expectMBean)`:
> {code:java}
> latencyCalculator.cancel(false);
> compactionStrategyManager.shutdown();
> SystemKeyspace.removeTruncationRecord(metadata.cfId); // line 566
> data.dropSSTables(); // line 568
> LifecycleTransaction.waitForDeletions(); // line 569
> indexManager.invalidateAllIndexesBlocking();
> {code}
> According to the code and the comments, we suppose `data.dropSSTables()` in
> line 568 will submit some tidier tasks to the `nonPeriodicTasks` thread pool.
> Call stack in version 3.11.10:
> {code:java}
> org.apache.cassandra.db.lifecycle.Tracker#dropSSTables:233
> org.apache.cassandra.db.lifecycle.Tracker#dropSSTables:238
> org.apache.cassandra.db.lifecycle.Tracker#dropSSTables:267
> org.apache.cassandra.utils.concurrent.Refs#release:241
> org.apache.cassandra.utils.concurrent.Ref#release:119
> org.apache.cassandra.utils.concurrent.Ref#release:225
> org.apache.cassandra.utils.concurrent.Ref#release:326
> org.apache.cassandra.io.sstable.format.SSTableReader$InstanceTidier#tidy:2205
> {code}
> Then, `LifecycleTransaction.waitForDeletions()` in line 569 is
> {code:java}
> /**
> * Deletions run on the nonPeriodicTasks executor, (both failedDeletions
> or global tidiers in SSTableReader)
> * so by scheduling a new empty task and waiting for it we ensure any
> prior deletion has completed.
> */
> public static void waitForDeletions()
> {
> LogTransaction.waitForDeletions();
> }
> {code}
> And then call `waitForDeletions` in `LogTransaction`:
> {code:java}
> static void waitForDeletions()
> {
>
> FBUtilities.waitOnFuture(ScheduledExecutors.nonPeriodicTasks.schedule(Runnables.doNothing(),
> 0, TimeUnit.MILLISECONDS));
> }
> {code}
> From the comments, we think it ensures that all existing tasks in
> `nonPeriodicTasks` are drained. However, we found some tidier tasks are still
> running in `nonPeriodicTasks` thread pool.
> We suspect that those tidier tasks should be guaranteed to finish during
> server setup, because of its exception handling. In version 3.11.10, these
> tidier tasks are submitted to `nonPeriodicTasks` in
> `SSTableReader$InstanceTidier#tidy:2205`, and have the exception handling
> `FileUtils.handleFSErrorAndPropagate(new FSWriteError(e, file))` (within the
> call stack `SSTableReader$InstanceTidier$1#run:2223` =>
> `LogTransaction$SSTableTidier#run:386` => `LogTransaction#delete:261`).
> The `FileUtils.handleFSErrorAndPropagate` handles this `FSWriteError`. We
> found that it checks the `CassandraDaemon.setupCompleted` flag in call stack
> within (`FileUtils#handleFSErrorAndPropagate:507` =>
> `JVMStabilityInspector#inspectThrowable:60` =>
> `JVMStabilityInspector#inspectThrowable:106` =>
> `JVMStabilityInspector#inspectDiskError:73` => `FileUtils#handleFSError:494`
> => `DefaultFSErrorHandler:handleFSError:58`)
> {code:java}
> if (!StorageService.instance.isDaemonSetupCompleted()) // line 58
> handleStartupFSError(e); // line 59
>
[jira] [Commented] (CASSANDRA-17431) Move the rest of the Config parameters to the new Config framework
[
https://issues.apache.org/jira/browse/CASSANDRA-17431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17525058#comment-17525058
]
Ekaterina Dimitrova commented on CASSANDRA-17431:
-
CCM patch
[committed|https://github.com/riptano/ccm/commit/4609ac46beccd3ab86463a345ed59e998d664d04]
and CCM [retagged|https://github.com/riptano/ccm/tags]
trunk patch
[committed|https://github.com/apache/cassandra/commit/dac738d2eba8629d4f482d7cbfd855d2c5b9df47]
second so that the CI acknowledges the CCM changes:
To https://github.com/apache/cassandra.git
03ef67c9d5..dac738d2eb trunk -> trunk
*I had a mistake in the 3 setters({_}setPermissionsUpdateInterval{_},
_setCredentialsUpdateInterval_ and _setRolesUpdateInterval_), was ignoring to
throw the exception on negative values (which we do currently on trunk). I
didn't rerun the CI as this just mimics the current trunk. Please let me know
if you have any concerns.*
> Move the rest of the Config parameters to the new Config framework
> --
>
> Key: CASSANDRA-17431
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17431
> Project: Cassandra
> Issue Type: Task
> Components: Local/Config
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.x
>
>
> Migrate also all Config parameters that are in Config, but not presented in
> cassandra.yaml to the new config framework. Not presented in the yaml as they
> are considered advanced only for advanced users.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17431) Move the rest of the Config parameters to the new Config framework
[ https://issues.apache.org/jira/browse/CASSANDRA-17431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-17431: Source Control Link: https://github.com/apache/cassandra/commit/dac738d2eba8629d4f482d7cbfd855d2c5b9df47 Resolution: Fixed Status: Resolved (was: Ready to Commit) > Move the rest of the Config parameters to the new Config framework > -- > > Key: CASSANDRA-17431 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17431 > Project: Cassandra > Issue Type: Task > Components: Local/Config >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.x > > > Migrate also all Config parameters that are in Config, but not presented in > cassandra.yaml to the new config framework. Not presented in the yaml as they > are considered advanced only for advanced users. -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17431) Move the rest of the Config parameters to the new Config framework
[ https://issues.apache.org/jira/browse/CASSANDRA-17431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-17431: Fix Version/s: 4.1 (was: 4.x) > Move the rest of the Config parameters to the new Config framework > -- > > Key: CASSANDRA-17431 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17431 > Project: Cassandra > Issue Type: Task > Components: Local/Config >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.1 > > > Migrate also all Config parameters that are in Config, but not presented in > cassandra.yaml to the new config framework. Not presented in the yaml as they > are considered advanced only for advanced users. -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17180) Implement startup check to prevent Cassandra start to spread zombie data
[ https://issues.apache.org/jira/browse/CASSANDRA-17180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17525057#comment-17525057 ] Stefan Miklosovic commented on CASSANDRA-17180: --- Changes from the last review: 1) added prefix "check_" to checks in the configuration 2) updated documentation in cassandra.yaml 3) fixed retrieval of table metadata 4) ignoring tables which have gc = 0 5) moved heartbeating scheduling after checks are done 6) renamed default name of heartbeat file from ".cassandra-heartbeat" to "cassandra-heartbeat" (it is not hidden anymore). > Implement startup check to prevent Cassandra start to spread zombie data > > > Key: CASSANDRA-17180 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17180 > Project: Cassandra > Issue Type: New Feature > Components: Legacy/Observability >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Time Spent: 9.5h > Remaining Estimate: 0h > > As already discussed on ML, it would be nice to have a service which would > periodically write timestamp to a file signalling it is up / running. > Then, on the startup, we would read this file and we would determine if there > is some table which gc grace is behind this time and we would fail the start > so we would prevent zombie data to be likely spread around a cluster. > https://lists.apache.org/thread/w4w5t2hlcrvqhgdwww61hgg58qz13glw -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17465) python unit tests don't cleanup test keyspace
[
https://issues.apache.org/jira/browse/CASSANDRA-17465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17525055#comment-17525055
]
Brandon Williams commented on CASSANDRA-17465:
--
Not sure where we are with this ticket, but here's a
[branch|https://github.com/driftx/cassandra/tree/CASSANDRA-17465] and circle:
[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/440/workflows/42f936c7-2ede-4fbf-957c-5fb4e461dd90],
[j11|https://app.circleci.com/pipelines/github/driftx/cassandra/440/workflows/ef78eb31-000f-47c6-b894-c7879d83b0be].
> python unit tests don't cleanup test keyspace
> -
>
> Key: CASSANDRA-17465
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17465
> Project: Cassandra
> Issue Type: Task
> Components: CQL/Interpreter
>Reporter: Brad Schoening
>Assignee: Brad Schoening
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> The python unit tests in pylib/cqlshlib creates a temporary keyspace
> cqlshtests_, but does not drop it upon completion.
> To reproduce:
> {code:java}
> $ pytest
> $ cqlsh
> cassandra@cqlsh> describe keyspaces
> cqlshtests_oatjjlyyxh ...
> {code}
> The above keyspace, created with a 10 character random suffix, will remain
> after the tests are run. This will then cause subsequent runs of
> test_cqlsh_completion to fail.
>
> {code:java}
> cqlshlib/test/test_cqlsh_completion.py:138: in _trycompletions_inner
> E AssertionError: Items in the second set but not the first:
> E 'cqlshtests_oatjjlyyxh'
> {code}
> test/cassconnect.py;'s remove_db() has the code to perform this, but does not
> seem to be properly called.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-11871) Allow to aggregate by time intervals
[
https://issues.apache.org/jira/browse/CASSANDRA-11871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17510792#comment-17510792
]
Benjamin Lerer edited comment on CASSANDRA-11871 at 4/20/22 2:55 PM:
-
[PR|https://github.com/apache/cassandra/pull/1510]
[CI|https://app.circleci.com/pipelines/github/blerer/cassandra/281/workflows/8155592d-70d1-4e2e-9086-1ae542873ebb]
The patch refactors the code to allow the use of native monotonic scalar
functions on the last element of the GROUP BY clause.
It also introduces a new floor function that can be use to group rows by time
intervals
was (Author: blerer):
[PR|https://github.com/apache/cassandra/pull/1510]
[CI|https://app.circleci.com/pipelines/github/blerer/cassandra/275/workflows/2214fd4c-c6aa-412e-ab3a-bd89f451bc5b]
The patch refactors the code to allow the use of native monotonic scalar
functions on the last element of the GROUP BY clause.
It also introduces a new floor function that can be use to group rows by time
intervals
> Allow to aggregate by time intervals
>
>
> Key: CASSANDRA-11871
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11871
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/CQL
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 3h 10m
> Remaining Estimate: 0h
>
> For time series data it can be usefull to aggregate by time intervals.
> The idea would be to add support for one or several functions in the {{GROUP
> BY}} clause.
> Regarding the implementation, even if in general I also prefer to follow the
> SQL syntax, I do not believe it will be a good fit for Cassandra.
> If we have a table like:
> {code}
> CREATE TABLE trades
> {
> symbol text,
> date date,
> time time,
> priceMantissa int,
> priceExponent tinyint,
> volume int,
> PRIMARY KEY ((symbol, date), time)
> };
> {code}
> The trades will be inserted with an increasing time and sorted in the same
> order. As we can have to process a large amount of data, we want to try to
> limit ourself to the cases where we can build the groups on the flight (which
> is not a requirement in the SQL world).
> If we want to get the number of trades per minutes with the SQL syntax we
> will have to write:
> {{SELECT hour(time), minute(time), count() FROM Trades WHERE symbol = 'AAPL'
> AND date = '2016-01-11' GROUP BY hour(time), minute(time);}}
> which is fine. The problem is that if the user invert by mistake the
> functions like that:
> {{SELECT hour(time), minute(time), count() FROM Trades WHERE symbol = 'AAPL'
> AND date = '2016-01-11' GROUP BY minute(time), hour(time);}}
> the query will return weird results.
> The only way to prevent that would be to check the function order and make
> sure that we do not allow to skip functions (e.g. {{GROUP BY hour(time),
> second(time)}}).
> In my opinion a function like {{floor(, )}} will be
> much better as it does not allow for this type of mistakes and is much more
> flexible (you can create 5 minutes buckets if you want to).
> {{SELECT floor(time, m), count() FROM Trades WHERE symbol = 'AAPL' AND date =
> '2016-01-11' GROUP BY floor(time, m);}}
> An important aspect to keep in mind with a function like {{floor}} is the
> starting point. For a query like: {{SELECT floor(time, m), count() FROM
> Trades WHERE symbol = 'AAPL' AND date = '2016-01-11' AND time >= '01:30:00'
> AND time =< '07:30:00' GROUP BY floor(time, 2h);}}, I think that ideally the
> result should return 3 groups: {{01:30:00}}, {{03:30:00}} and {{05:30:00}}.
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17465) python unit tests don't cleanup test keyspace
[
https://issues.apache.org/jira/browse/CASSANDRA-17465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-17465:
-
Reviewers: Brandon Williams, Stefan Miklosovic (was: Stefan Miklosovic)
> python unit tests don't cleanup test keyspace
> -
>
> Key: CASSANDRA-17465
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17465
> Project: Cassandra
> Issue Type: Task
> Components: CQL/Interpreter
>Reporter: Brad Schoening
>Assignee: Brad Schoening
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> The python unit tests in pylib/cqlshlib creates a temporary keyspace
> cqlshtests_, but does not drop it upon completion.
> To reproduce:
> {code:java}
> $ pytest
> $ cqlsh
> cassandra@cqlsh> describe keyspaces
> cqlshtests_oatjjlyyxh ...
> {code}
> The above keyspace, created with a 10 character random suffix, will remain
> after the tests are run. This will then cause subsequent runs of
> test_cqlsh_completion to fail.
>
> {code:java}
> cqlshlib/test/test_cqlsh_completion.py:138: in _trycompletions_inner
> E AssertionError: Items in the second set but not the first:
> E 'cqlshtests_oatjjlyyxh'
> {code}
> test/cassconnect.py;'s remove_db() has the code to perform this, but does not
> seem to be properly called.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated: Transfer config parameters to the new types; Fix corner case for permissions_update_interval, roles_update_interval, credentials_update_interval;Fix typo in Config an
This is an automated email from the ASF dual-hosted git repository. edimitrova pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git The following commit(s) were added to refs/heads/trunk by this push: new dac738d2eb Transfer config parameters to the new types; Fix corner case for permissions_update_interval, roles_update_interval, credentials_update_interval;Fix typo in Config annotation; Made Converters type safe and fixed a few cases where converters used the wrong type; o should be provided with unit to DataStorageSpec and DurationStorageSpec; Fix null bug in DataStorageSpec and DurationSpec patch by Ekaterina Dimitrova, David Capwell; reviewed by David Capwell and Caleb Rackli [...] dac738d2eb is described below commit dac738d2eba8629d4f482d7cbfd855d2c5b9df47 Author: Ekaterina Dimitrova AuthorDate: Tue Mar 22 19:56:52 2022 -0400 Transfer config parameters to the new types; Fix corner case for permissions_update_interval, roles_update_interval, credentials_update_interval;Fix typo in Config annotation; Made Converters type safe and fixed a few cases where converters used the wrong type; o should be provided with unit to DataStorageSpec and DurationStorageSpec; Fix null bug in DataStorageSpec and DurationSpec patch by Ekaterina Dimitrova, David Capwell; reviewed by David Capwell and Caleb Rackliffe for CASSANDRA-17431 Co-authored-by: Ekaterina Dimitrova Co-authored-by: David Capwell --- CHANGES.txt| 5 + NEWS.txt | 11 +- doc/modules/cassandra/pages/new/configuration.adoc | 14 ++- src/java/org/apache/cassandra/auth/AuthConfig.java | 2 +- src/java/org/apache/cassandra/config/Config.java | 38 --- .../org/apache/cassandra/config/Converters.java| 106 +++--- .../org/apache/cassandra/config/DataRateSpec.java | 2 +- .../apache/cassandra/config/DataStorageSpec.java | 14 --- .../cassandra/config/DatabaseDescriptor.java | 122 +++-- .../org/apache/cassandra/config/DurationSpec.java | 19 +--- .../config/SmallestDurationMilliseconds.java | 12 ++ .../cassandra/config/YamlConfigurationLoader.java | 7 +- .../apache/cassandra/db/virtual/SettingsTable.java | 2 +- .../cassandra/transport/ClientResourceLimits.java | 10 +- test/conf/cassandra-old.yaml | 1 + .../distributed/test/PaxosRepairTest.java | 22 ++-- .../LoadOldYAMLBackwardCompatibilityTest.java | 7 +- .../cassandra/config/ParseAndConvertUnitsTest.java | 55 ++ .../config/YamlConfigurationLoaderTest.java| 112 +++ .../tools/nodetool/SetAuthCacheConfigTest.java | 35 ++ .../tools/nodetool/SetGetColumnIndexSizeTest.java | 2 +- .../transport/ClientResourceLimitsTest.java| 18 +-- 22 files changed, 421 insertions(+), 195 deletions(-) diff --git a/CHANGES.txt b/CHANGES.txt index ed00f8bca7..414164181d 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -1,4 +1,9 @@ 4.1 + * Migrate advanced config parameters to the new Config types (CASSANDRA-17431) + * Make null to be meaning disabled and leave 0 as a valid value for permissions_update_interval, roles_update_interval, credentials_update_interval (CASSANDRA-17431) + * Fix typo in Config annotation (CASSANDRA-17431) + * Made Converters type safe and fixed a few cases where converters used the wrong type (CASSANDRA-17431) + * Fix null bug in DataStorageSpec and DurationSpec and require units to be added when providing 0 value (CASSANDRA-17431) * Shutdown ScheduledExecutors as part of node drainage (CASSANDRA-17493) * Provide JMX endpoint to allow transient logging of blocking read repairs (CASSANDRA-17471) * Add guardrail for GROUP BY queries (CASSANDRA-17509) diff --git a/NEWS.txt b/NEWS.txt index 10a5e30356..992c291115 100644 --- a/NEWS.txt +++ b/NEWS.txt @@ -136,10 +136,15 @@ Upgrading will be removed in a future major release. - There is a new cassandra.yaml version 2. Units suffixes should be provided for all rates(B/s|MiB/s|KiB/s|MiB/s), memory (KiB|MiB|GiB|B) and duration(d|h|s|ms|us|µs|ns|m) - parameters. (CASSANDRA-15234) + parameters. List of changed parameters and details to consider during configuration setup can be + found at https://cassandra.apache.org/doc/latest/cassandra/new/configuration.html. (CASSANDRA-15234) Backward compatibility with the old cassandra.yaml file will be in place until at least the next major version. -- Many cassandra.yaml parameters' names have been changed. Full list can be found on .. (ADD LINK LATER WHEN PAGE - IS CREATED) (CASSANDRA-15234) +- Many cassandra.yaml parameters' names have been changed. Full list and details to consider during configuration setup + when installing/upgrading Cassandra can be found at
[jira] [Commented] (CASSANDRA-17176) Introduce TimeUUID
[ https://issues.apache.org/jira/browse/CASSANDRA-17176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17525048#comment-17525048 ] Brandon Williams commented on CASSANDRA-17176: -- Note that this broke compatibility with 4.0, which caused CASSANDRA-17451. > Introduce TimeUUID > -- > > Key: CASSANDRA-17176 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17176 > Project: Cassandra > Issue Type: Sub-task > Components: Local/Other >Reporter: Benedict Elliott Smith >Assignee: Benedict Elliott Smith >Priority: Normal > Fix For: 4.1 > > > Introduce a dedicated class to represent UUID version 2, to ensure correct > usage within Cassandra -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17451) Flaky upgrade_tests.cql_tests.TestCQLNodes2RF1_Upgrade_current_4_0_x_To_indev_trunk.test_noncomposite_static_cf
[
https://issues.apache.org/jira/browse/CASSANDRA-17451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17525045#comment-17525045
]
Brandon Williams commented on CASSANDRA-17451:
--
This bisects to CASSANDRA-17176, which makes sense from the log:
{noformat}
ERROR [Native-Transport-Requests-1] 2022-04-19 19:25:24,360
StorageProxy.java:1631 - Failed to apply mutation locally :
java.lang.ClassCastException: org.apache.cassandra.utils.TimeUUID cannot be
cast to java.util.UUID
at
org.apache.cassandra.utils.UUIDSerializer.serializedSize(UUIDSerializer.java:28)
at
org.apache.cassandra.net.Message$Serializer.payloadSize(Message.java:1396)
at
org.apache.cassandra.net.Message$Serializer.access$1500(Message.java:691)
at org.apache.cassandra.net.Message.payloadSize(Message.java:1462)
at org.apache.cassandra.net.Message.access$900(Message.java:71)
at
org.apache.cassandra.net.Message$Serializer.serializedSizePost40(Message.java:867)
at
org.apache.cassandra.net.Message$Serializer.serializedSize(Message.java:724)
at
org.apache.cassandra.net.Message$Serializer.access$1400(Message.java:691)
at org.apache.cassandra.net.Message.serializedSize(Message.java:1437)
at
org.apache.cassandra.net.OutboundConnections.connectionTypeFor(OutboundConnections.java:212)
at
org.apache.cassandra.net.OutboundConnections.connectionFor(OutboundConnections.java:204)
at
org.apache.cassandra.net.OutboundConnections.enqueue(OutboundConnections.java:93)
at
org.apache.cassandra.net.MessagingService.doSend(MessagingService.java:416)
at org.apache.cassandra.net.OutboundSink.accept(OutboundSink.java:70)
at
org.apache.cassandra.net.MessagingService.send(MessagingService.java:405)
at
org.apache.cassandra.net.MessagingService.send(MessagingService.java:375)
...
{noformat}
> Flaky
> upgrade_tests.cql_tests.TestCQLNodes2RF1_Upgrade_current_4_0_x_To_indev_trunk.test_noncomposite_static_cf
> ---
>
> Key: CASSANDRA-17451
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17451
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Stefan Miklosovic
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.x
>
>
> dtest-upgrade.upgrade_tests.cql_tests
> TestCQLNodes2RF1_Upgrade_current_4_0_x_To_indev_trunk
> test_noncomposite_static_cf is flaky.
> {code}
> Error Message
> cassandra.WriteFailure: Error from server: code=1500 [Replica(s) failed to
> execute write] message="Operation failed - received 1 responses and 1
> failures: UNKNOWN from /127.0.0.1:7000" info={'consistency': 'ONE',
> 'required_responses': 1, 'received_responses': 1, 'failures': 1,
> 'error_code_map': {'127.0.0.1': '0x'}}
> Stacktrace
> self = 0x7fc77ceb7d00>
> def test_noncomposite_static_cf(self):
> """ Test non-composite static CF syntax """
> cursor = self.prepare()
>
> # Create
> cursor.execute("""
> CREATE TABLE users (
> userid uuid PRIMARY KEY,
> firstname ascii,
> lastname ascii,
> age int
> ) WITH COMPACT STORAGE;
> """)
>
> for is_upgraded, cursor in self.do_upgrade(cursor):
> logger.debug("Querying {} node".format("upgraded" if is_upgraded
> else "old"))
> cursor.execute("TRUNCATE users")
>
> # Inserts
> cursor.execute("INSERT INTO users (userid, firstname, lastname,
> age) VALUES (550e8400-e29b-41d4-a716-44665544, 'Frodo', 'Baggins', 32)")
> cursor.execute("UPDATE users SET firstname = 'Samwise', lastname
> = 'Gamgee', age = 33 WHERE userid = f47ac10b-58cc-4372-a567-0e02b2c3d479")
>
> # Queries
> assert_one(cursor, "SELECT firstname, lastname FROM users WHERE
> userid = 550e8400-e29b-41d4-a716-44665544", ['Frodo', 'Baggins'])
>
> assert_one(cursor, "SELECT * FROM users WHERE userid =
> 550e8400-e29b-41d4-a716-44665544",
>[UUID('550e8400-e29b-41d4-a716-44665544'), 32,
> 'Frodo', 'Baggins'])
> # FIXME There appears to be some sort of problem with reusable
> cells
> # when executing this query. It's likely that CASSANDRA-9705 will
> # fix this, but I'm not 100% sure.
> assert_one(cursor, "SELECT * FROM users WHERE userid =
> f47ac10b-58cc-4372-a567-0e02b2c3d479",
>[UUID('f47ac10b-58cc-4372-a567-0e02b2c3d479'), 33,
> 'Samwise', 'Gamgee'])
> assert_all(cursor, "SELECT * FROM users",
>
[jira] [Updated] (CASSANDRA-17454) flaky dtest-upgrade.upgrade_tests.cql_tests TestCQLNodes2RF1_Upgrade_indev_4_0_x_To_indev_trunk test_static_cf
[
https://issues.apache.org/jira/browse/CASSANDRA-17454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-17454:
-
Resolution: Duplicate
Status: Resolved (was: Open)
Resolving as a duplicate of CASSANDRA-17451, both have the same root cause.
> flaky dtest-upgrade.upgrade_tests.cql_tests
> TestCQLNodes2RF1_Upgrade_indev_4_0_x_To_indev_trunk test_static_cf
> --
>
> Key: CASSANDRA-17454
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17454
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Stefan Miklosovic
>Assignee: Brandon Williams
>Priority: Normal
>
> {code:java}
> Error Messagecassandra.WriteFailure: Error from server: code=1500 [Replica(s)
> failed to execute write] message="Operation failed - received 1 responses and
> 1 failures: UNKNOWN from /127.0.0.1:7000" info={'consistency': 'ONE',
> 'required_responses': 1, 'received_responses': 1, 'failures': 1,
> 'error_code_map': {'127.0.0.1': '0x'}}Stacktraceself =
> 0x7f36e8ae1a60>
> def test_static_cf(self):
> """ Test static CF syntax """
> cursor = self.prepare()
>
> # Create
> cursor.execute("""
> CREATE TABLE users (
> userid uuid PRIMARY KEY,
> firstname text,
> lastname text,
> age int
> );
> """)
>
> for is_upgraded, cursor in self.do_upgrade(cursor):
> logger.debug("Querying {} node".format("upgraded" if is_upgraded
> else "old"))
> cursor.execute("TRUNCATE users")
>
> # Inserts
> cursor.execute("INSERT INTO users (userid, firstname, lastname,
> age) VALUES (550e8400-e29b-41d4-a716-44665544, 'Frodo', 'Baggins', 32)")
> cursor.execute("UPDATE users SET firstname = 'Samwise', lastname
> = 'Gamgee', age = 33 WHERE userid = f47ac10b-58cc-4372-a567-0e02b2c3d479")
>
> # Queries
> assert_one(cursor, "SELECT firstname, lastname FROM users WHERE
> userid = 550e8400-e29b-41d4-a716-44665544", ['Frodo', 'Baggins'])
>
> assert_one(cursor, "SELECT * FROM users WHERE userid =
> 550e8400-e29b-41d4-a716-44665544",
> [UUID('550e8400-e29b-41d4-a716-44665544'), 32, 'Frodo', 'Baggins'])
>
> assert_all(cursor, "SELECT * FROM users",
> [[UUID('f47ac10b-58cc-4372-a567-0e02b2c3d479'), 33, 'Samwise', 'Gamgee'],
>
> [UUID('550e8400-e29b-41d4-a716-44665544'), 32, 'Frodo', 'Baggins']])
>
> # Test batch inserts
> > cursor.execute("""
> BEGIN BATCH
> INSERT INTO users (userid, age) VALUES
> (550e8400-e29b-41d4-a716-44665544, 36)
> UPDATE users SET age = 37 WHERE userid =
> f47ac10b-58cc-4372-a567-0e02b2c3d479
> DELETE firstname, lastname FROM users WHERE userid =
> 550e8400-e29b-41d4-a716-44665544
> DELETE firstname, lastname FROM users WHERE userid =
> f47ac10b-58cc-4372-a567-0e02b2c3d479
> APPLY BATCH
> """)
> upgrade_tests/cql_tests.py:74:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> ../venv/src/cassandra-driver/cassandra/cluster.py:2618: in execute
> return self.execute_async(query, parameters, trace, custom_payload,
> timeout, execution_profile, paging_state, host, execute_as).result() {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-11871) Allow to aggregate by time intervals
[
https://issues.apache.org/jira/browse/CASSANDRA-11871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17510792#comment-17510792
]
Benjamin Lerer edited comment on CASSANDRA-11871 at 4/20/22 2:07 PM:
-
[PR|https://github.com/apache/cassandra/pull/1510]
[CI|https://app.circleci.com/pipelines/github/blerer/cassandra/275/workflows/2214fd4c-c6aa-412e-ab3a-bd89f451bc5b]
The patch refactors the code to allow the use of native monotonic scalar
functions on the last element of the GROUP BY clause.
It also introduces a new floor function that can be use to group rows by time
intervals
was (Author: blerer):
[PR|https://github.com/apache/cassandra/pull/1510]
[DTest PR|https://github.com/apache/cassandra-dtest/pull/178]
[CI|https://app.circleci.com/pipelines/github/blerer/cassandra/275/workflows/2214fd4c-c6aa-412e-ab3a-bd89f451bc5b]
The patch refactors the code to allow the use of native monotonic scalar
functions on the last element of the GROUP BY clause.
It also introduces a new floor function that can be use to group rows by time
intervals
> Allow to aggregate by time intervals
>
>
> Key: CASSANDRA-11871
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11871
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/CQL
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 3h 10m
> Remaining Estimate: 0h
>
> For time series data it can be usefull to aggregate by time intervals.
> The idea would be to add support for one or several functions in the {{GROUP
> BY}} clause.
> Regarding the implementation, even if in general I also prefer to follow the
> SQL syntax, I do not believe it will be a good fit for Cassandra.
> If we have a table like:
> {code}
> CREATE TABLE trades
> {
> symbol text,
> date date,
> time time,
> priceMantissa int,
> priceExponent tinyint,
> volume int,
> PRIMARY KEY ((symbol, date), time)
> };
> {code}
> The trades will be inserted with an increasing time and sorted in the same
> order. As we can have to process a large amount of data, we want to try to
> limit ourself to the cases where we can build the groups on the flight (which
> is not a requirement in the SQL world).
> If we want to get the number of trades per minutes with the SQL syntax we
> will have to write:
> {{SELECT hour(time), minute(time), count() FROM Trades WHERE symbol = 'AAPL'
> AND date = '2016-01-11' GROUP BY hour(time), minute(time);}}
> which is fine. The problem is that if the user invert by mistake the
> functions like that:
> {{SELECT hour(time), minute(time), count() FROM Trades WHERE symbol = 'AAPL'
> AND date = '2016-01-11' GROUP BY minute(time), hour(time);}}
> the query will return weird results.
> The only way to prevent that would be to check the function order and make
> sure that we do not allow to skip functions (e.g. {{GROUP BY hour(time),
> second(time)}}).
> In my opinion a function like {{floor(, )}} will be
> much better as it does not allow for this type of mistakes and is much more
> flexible (you can create 5 minutes buckets if you want to).
> {{SELECT floor(time, m), count() FROM Trades WHERE symbol = 'AAPL' AND date =
> '2016-01-11' GROUP BY floor(time, m);}}
> An important aspect to keep in mind with a function like {{floor}} is the
> starting point. For a query like: {{SELECT floor(time, m), count() FROM
> Trades WHERE symbol = 'AAPL' AND date = '2016-01-11' AND time >= '01:30:00'
> AND time =< '07:30:00' GROUP BY floor(time, 2h);}}, I think that ideally the
> result should return 3 groups: {{01:30:00}}, {{03:30:00}} and {{05:30:00}}.
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17180) Implement startup check to prevent Cassandra start to spread zombie data
[ https://issues.apache.org/jira/browse/CASSANDRA-17180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17524999#comment-17524999 ] Stefan Miklosovic edited comment on CASSANDRA-17180 at 4/20/22 2:01 PM: I think it is viable to do via "SchemaKeyspace.fetchNonSystemKeyspaces()". It will make a query and it will return Keyspaces with all metadata etc. However, I identified that this method has a bug in it. It will not return only user keyspaces but it will return also system_traces so SchemaConstants#LOCAL_SYSTEM_KEYSPACE_NAMES is likely missing it. I ll take a look. One more detail to mention is that SchemaKeyspace.fetchNonSystemKeyspaces is package protected, I had to make it public. There are other methods of the similar fashion which are private too. I am not sure I can make this method publicly visible without any conseqencies yet. was (Author: smiklosovic): I think it is viable to do via "SchemaKeyspace.fetchNonSystemKeyspaces()". It will make a query and it will return Keyspaces with all metadata etc. However, I identified that this method has a bug in it. It will not return only user keyspaces but it will return also system_traces.events and system_traces.sessions so SchemaConstants#LOCAL_SYSTEM_KEYSPACE_NAMES is likely missing these two. I ll take a look. One more detail to mention is that SchemaKeyspace.fetchNonSystemKeyspaces is package protected, I had to make it public. There are other methods of the similar fashion which are private too. I am not sure I can make this method publicly visible without any conseqencies yet. > Implement startup check to prevent Cassandra start to spread zombie data > > > Key: CASSANDRA-17180 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17180 > Project: Cassandra > Issue Type: New Feature > Components: Legacy/Observability >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Time Spent: 9.5h > Remaining Estimate: 0h > > As already discussed on ML, it would be nice to have a service which would > periodically write timestamp to a file signalling it is up / running. > Then, on the startup, we would read this file and we would determine if there > is some table which gc grace is behind this time and we would fail the start > so we would prevent zombie data to be likely spread around a cluster. > https://lists.apache.org/thread/w4w5t2hlcrvqhgdwww61hgg58qz13glw -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17551) 0KiB should be used to prohibit collections and not to disable the guardrails collection_size_warn_threshold and collection_size_fail_threshold
[
https://issues.apache.org/jira/browse/CASSANDRA-17551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17525005#comment-17525005
]
Andres de la Peña edited comment on CASSANDRA-17551 at 4/20/22 2:00 PM:
The current guardrails for collection size are checked during write queries and
on sstable write (flush and compaction). The error message has the form
{{{}Detected collection %s of size %s, this exceeds the warning/failure
threshold of %s{}}}.
I think that the check for disabled collections should probably be done when
creating/altering a table, probably with a different warning/error message,
such as {{{}Collections are not enabled{}}}. That could done in an easier way
with a {{DisableFlag}} guardrail and new \{{collections_enabled}} property.
The advantage of using 0 as disabled value is that config would be briefer than
adding separate properties. Maybe we could modify {{Threshold}} guardrails to
include the functionalities of {{{}DisableFlag{}}}, which are an
{{ensureEnabled}} method and a separate warn/error message for the particular
case of 0. That would be useful not only for size-based guardrails but also for
numeric guardrails such as, for example,
{{{}materialized_views_per_table_warn_threshold{}}}/{{{}materialized_views_per_table_fail_threshold{}}},
where 0 would disallow or warn about MV creation in general, independently of
the number of MVs. wdyt?
was (Author: adelapena):
The current guardrails for collection size are checked during write queries and
on sstable write (flush and compaction). The error message has the form
{{{}Detected collection %s of size %s, this exceeds the warning/failure
threshold of %s{}}}.
I think that the check for disabled collections should probably be checked when
creating/altering a table, probably with a different warning/error message,
such as {{{}Collections are not enabled{}}}. That could probably be better done
with a {{DisableFlag}} guardrail.
The advantage of using 0 as disabled value is that config would be briefer than
adding separate properties. Maybe we could modify {{Threshold}} guardrails to
include the functionalities of {{{}DisableFlag{}}}, which are an
{{ensureEnabled}} method and a separate warn/error message for the particular
case of 0. That would be useful not only for size-based guardrails but also for
numeric guardrails such as, for example,
{{materialized_views_per_table_warn_threshold}}/{{materialized_views_per_table_fail_threshold}},
where 0 would disallow or warn about MV creation in general, independently of
the number of MVs. wdyt?
> 0KiB should be used to prohibit collections and not to disable the guardrails
> collection_size_warn_threshold and collection_size_fail_threshold
> ---
>
> Key: CASSANDRA-17551
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17551
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Guardrails
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.x
>
>
> # The two thresholds default to 0KiB to disable.
> # collection_size_warn_threshold: 0KiB
> # collection_size_fail_threshold: 0KiB
> 0KiB should be used to prohibit collections and not to disable the guardrail.
> Disabled should be null as we moved to that as part of CASSANDRA-17431 while
> investigating other config corner cases.
> Old config which had -1 for disable will be converted internally to null with
> the new config types and new config should use null for disable. Of course,
> disabling 0 as a non-valid value is a different story which should be handled
> on per-case basis.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17551) 0KiB should be used to prohibit collections and not to disable the guardrails collection_size_warn_threshold and collection_size_fail_threshold
[
https://issues.apache.org/jira/browse/CASSANDRA-17551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17525005#comment-17525005
]
Andres de la Peña commented on CASSANDRA-17551:
---
The current guardrails for collection size are checked during write queries and
on sstable write (flush and compaction). The error message has the form
{{{}Detected collection %s of size %s, this exceeds the warning/failure
threshold of %s{}}}.
I think that the check for disabled collections should probably be checked when
creating/altering a table, probably with a different warning/error message,
such as {{{}Collections are not enabled{}}}. That could probably be better done
with a {{DisableFlag}} guardrail.
The advantage of using 0 as disabled value is that config would be briefer than
adding separate properties. Maybe we could modify {{Threshold}} guardrails to
include the functionalities of {{{}DisableFlag{}}}, which are an
{{ensureEnabled}} method and a separate warn/error message for the particular
case of 0. That would be useful not only for size-based guardrails but also for
numeric guardrails such as, for example,
{{materialized_views_per_table_warn_threshold}}/{{materialized_views_per_table_fail_threshold}},
where 0 would disallow or warn about MV creation in general, independently of
the number of MVs. wdyt?
> 0KiB should be used to prohibit collections and not to disable the guardrails
> collection_size_warn_threshold and collection_size_fail_threshold
> ---
>
> Key: CASSANDRA-17551
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17551
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Guardrails
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.x
>
>
> # The two thresholds default to 0KiB to disable.
> # collection_size_warn_threshold: 0KiB
> # collection_size_fail_threshold: 0KiB
> 0KiB should be used to prohibit collections and not to disable the guardrail.
> Disabled should be null as we moved to that as part of CASSANDRA-17431 while
> investigating other config corner cases.
> Old config which had -1 for disable will be converted internally to null with
> the new config types and new config should use null for disable. Of course,
> disabling 0 as a non-valid value is a different story which should be handled
> on per-case basis.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17180) Implement startup check to prevent Cassandra start to spread zombie data
[ https://issues.apache.org/jira/browse/CASSANDRA-17180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17524999#comment-17524999 ] Stefan Miklosovic commented on CASSANDRA-17180: --- I think it is viable to do via "SchemaKeyspace.fetchNonSystemKeyspaces()". It will make a query and it will return Keyspaces with all metadata etc. However, I identified that this method has a bug in it. It will not return only user keyspaces but it will return also system_traces.events and system_traces.sessions so SchemaConstants#LOCAL_SYSTEM_KEYSPACE_NAMES is likely missing these two. I ll take a look. One more detail to mention is that SchemaKeyspace.fetchNonSystemKeyspaces is package protected, I had to make it public. There are other methods of the similar fashion which are private too. I am not sure I can make this method publicly visible without any conseqencies yet. > Implement startup check to prevent Cassandra start to spread zombie data > > > Key: CASSANDRA-17180 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17180 > Project: Cassandra > Issue Type: New Feature > Components: Legacy/Observability >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Time Spent: 9.5h > Remaining Estimate: 0h > > As already discussed on ML, it would be nice to have a service which would > periodically write timestamp to a file signalling it is up / running. > Then, on the startup, we would read this file and we would determine if there > is some table which gc grace is behind this time and we would fail the start > so we would prevent zombie data to be likely spread around a cluster. > https://lists.apache.org/thread/w4w5t2hlcrvqhgdwww61hgg58qz13glw -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
