[jira] [Commented] (CASSANDRA-17433) Revise use of pytz in Python >= 3.9
[ https://issues.apache.org/jira/browse/CASSANDRA-17433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17727791#comment-17727791 ] Leonard Ma commented on CASSANDRA-17433: Ok, I updated the documentation. I also made a note mentioning that they pytz library should only be necessary now on Python 3.8 or lower - hopefully that is ok. If not, let me know. > Revise use of pytz in Python >= 3.9 > > > Key: CASSANDRA-17433 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17433 > Project: Cassandra > Issue Type: Task > Components: CQL/Interpreter >Reporter: Brad Schoening >Assignee: Leonard Ma >Priority: Low > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > PEP 615 – Support for the IANA Time Zone Database in the Standard Library > class ZoneInfo > PEP 615 (Python 3.9) has obsoleted the 3rd party Olsen tz library 'pytz' with > support for the IANA Time Zone Database. The code which imports this in > cqlshmain.py and tests in > [test_cqlsh_output.py|https://github.com/apache/cassandra/pull/1493/files/9c658a20c669d11a54ecc6b42ba083da13de0103#diff-f5a3955faadf50a1292df481044b83cefc44b2dac46676022c80bad076491a50] > should be updated accordingly. > This can be done with something like: > if sys.version_info >= (3,9): > try: > import zoneinfo > else: > try: > import pytz > ... -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-staging updated (ae0eb680 -> c1fa74af)
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 ae0eb680 generate docs for 1b144e50 new c1fa74af generate docs for 1b144e50 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 (ae0eb680) \ N -- N -- N refs/heads/asf-staging (c1fa74af) 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: .../cassandra/managing/tools/cassandra_stress.html | 4 .../cassandra/managing/tools/cassandra_stress.html | 4 content/search-index.js| 2 +- site-ui/build/ui-bundle.zip| Bin 4796900 -> 4796900 bytes 4 files changed, 9 insertions(+), 1 deletion(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-18557) CEP-30 ANN Vector Search with SAI
Jonathan Ellis created CASSANDRA-18557: -- Summary: CEP-30 ANN Vector Search with SAI Key: CASSANDRA-18557 URL: https://issues.apache.org/jira/browse/CASSANDRA-18557 Project: Cassandra Issue Type: Epic Reporter: Jonathan Ellis [CEP-30|https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-30%3A+Approximate+Nearest+Neighbor%28ANN%29+Vector+Search+via+Storage-Attached+Indexes] # Implement approximate nearest neighbor (ANN) vector search capability in Apache Cassandra using storage-attached indexes (SAI). # Support a vector of float32 embeddings as a new CQL type. # Add ANN search to work with normal Cassandra data flow (insertion, updating, and deleting rows). The implementation should support adding a new vector in log(N) time, and ANN queries in M log(N) time where N is the number of vectors and M is the number of sstables. # Compose with other SAI predicates. # Scatter/gather across replicas, combining topK from each to get global topK. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17194) Migrate thresholds for compaction to guardrails
[
https://issues.apache.org/jira/browse/CASSANDRA-17194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxwell Guo updated CASSANDRA-17194:
Reviewers: Berenguer Blasi, Maxwell Guo (was: Maxwell Guo)
> Migrate thresholds for compaction to guardrails
> ---
>
> Key: CASSANDRA-17194
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17194
> 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: 5.x
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> Migrate the existing thresholds for compaction:
> {code:java}
> compaction_large_partition_warning_threshold_mb: 100
> compaction_tombstone_warning_threshold: 10
> {code}
> To a new set of guardrails under the {{guardrails}} section, for example:
> {code:java}
> partition_size_warn_threshold: 50MiB
> partition_size_fail_threshold: 100MiB
> partition_tombstones_fail_threshold: 5
> partition_tombstones_fail_threshold: 10
> {code}
> Note that since these guardrails would be attached to a background process
> there wouldn't be abort/fail thresholds because we don't want to stop
> compaction.
> At the moment these thresholds are enabled by default, while guardrails are
> globally disabled by default, so we should consider whether we want to
> globally enable guardrails, or change these thresholds to disabled by
> default, or don't migrate the thresholds.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17194) Migrate thresholds for compaction to guardrails
[
https://issues.apache.org/jira/browse/CASSANDRA-17194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxwell Guo updated CASSANDRA-17194:
Test and Documentation Plan: ut
Status: Patch Available (was: In Progress)
> Migrate thresholds for compaction to guardrails
> ---
>
> Key: CASSANDRA-17194
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17194
> 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: 5.x
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> Migrate the existing thresholds for compaction:
> {code:java}
> compaction_large_partition_warning_threshold_mb: 100
> compaction_tombstone_warning_threshold: 10
> {code}
> To a new set of guardrails under the {{guardrails}} section, for example:
> {code:java}
> partition_size_warn_threshold: 50MiB
> partition_size_fail_threshold: 100MiB
> partition_tombstones_fail_threshold: 5
> partition_tombstones_fail_threshold: 10
> {code}
> Note that since these guardrails would be attached to a background process
> there wouldn't be abort/fail thresholds because we don't want to stop
> compaction.
> At the moment these thresholds are enabled by default, while guardrails are
> globally disabled by default, so we should consider whether we want to
> globally enable guardrails, or change these thresholds to disabled by
> default, or don't migrate the thresholds.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17194) Migrate thresholds for compaction to guardrails
[
https://issues.apache.org/jira/browse/CASSANDRA-17194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxwell Guo updated CASSANDRA-17194:
Status: Review In Progress (was: Patch Available)
> Migrate thresholds for compaction to guardrails
> ---
>
> Key: CASSANDRA-17194
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17194
> 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: 5.x
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> Migrate the existing thresholds for compaction:
> {code:java}
> compaction_large_partition_warning_threshold_mb: 100
> compaction_tombstone_warning_threshold: 10
> {code}
> To a new set of guardrails under the {{guardrails}} section, for example:
> {code:java}
> partition_size_warn_threshold: 50MiB
> partition_size_fail_threshold: 100MiB
> partition_tombstones_fail_threshold: 5
> partition_tombstones_fail_threshold: 10
> {code}
> Note that since these guardrails would be attached to a background process
> there wouldn't be abort/fail thresholds because we don't want to stop
> compaction.
> At the moment these thresholds are enabled by default, while guardrails are
> globally disabled by default, so we should consider whether we want to
> globally enable guardrails, or change these thresholds to disabled by
> default, or don't migrate the thresholds.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17194) Migrate thresholds for compaction to guardrails
[
https://issues.apache.org/jira/browse/CASSANDRA-17194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17727755#comment-17727755
]
Maxwell Guo commented on CASSANDRA-17194:
-
oh,I see, thank you [~adelapena]
> Migrate thresholds for compaction to guardrails
> ---
>
> Key: CASSANDRA-17194
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17194
> 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: 5.x
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> Migrate the existing thresholds for compaction:
> {code:java}
> compaction_large_partition_warning_threshold_mb: 100
> compaction_tombstone_warning_threshold: 10
> {code}
> To a new set of guardrails under the {{guardrails}} section, for example:
> {code:java}
> partition_size_warn_threshold: 50MiB
> partition_size_fail_threshold: 100MiB
> partition_tombstones_fail_threshold: 5
> partition_tombstones_fail_threshold: 10
> {code}
> Note that since these guardrails would be attached to a background process
> there wouldn't be abort/fail thresholds because we don't want to stop
> compaction.
> At the moment these thresholds are enabled by default, while guardrails are
> globally disabled by default, so we should consider whether we want to
> globally enable guardrails, or change these thresholds to disabled by
> default, or don't migrate the thresholds.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18511) Add support for JMX in the in-jvm dtest framework
[ https://issues.apache.org/jira/browse/CASSANDRA-18511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17727713#comment-17727713 ] Jon Meredith commented on CASSANDRA-18511: -- Starting over after pausing during the release vote. Starting commit CI Results (pending): ||Branch||Source||Circle CI||Jenkins|| |cassandra-3.11|[branch|https://github.com/jonmeredith/cassandra/tree/commit_remote_branch/CASSANDRA-18511-cassandra-3.11-FBBC1B68-F894-4605-A0BA-A4CA6F9BA47D]|[build|https://app.circleci.com/pipelines/github/jonmeredith/cassandra?branch=commit_remote_branch%2FCASSANDRA-18511-cassandra-3.11-FBBC1B68-F894-4605-A0BA-A4CA6F9BA47D]|[build|https://ci-cassandra.apache.org/job/Cassandra-devbranch/2495/]| |cassandra-4.0|[branch|https://github.com/jonmeredith/cassandra/tree/commit_remote_branch/CASSANDRA-18511-cassandra-4.0-FBBC1B68-F894-4605-A0BA-A4CA6F9BA47D]|[build|https://app.circleci.com/pipelines/github/jonmeredith/cassandra?branch=commit_remote_branch%2FCASSANDRA-18511-cassandra-4.0-FBBC1B68-F894-4605-A0BA-A4CA6F9BA47D]|[build|https://ci-cassandra.apache.org/job/Cassandra-devbranch/2496/]| |cassandra-4.1|[branch|https://github.com/jonmeredith/cassandra/tree/commit_remote_branch/CASSANDRA-18511-cassandra-4.1-FBBC1B68-F894-4605-A0BA-A4CA6F9BA47D]|[build|https://app.circleci.com/pipelines/github/jonmeredith/cassandra?branch=commit_remote_branch%2FCASSANDRA-18511-cassandra-4.1-FBBC1B68-F894-4605-A0BA-A4CA6F9BA47D]|[build|https://ci-cassandra.apache.org/job/Cassandra-devbranch/2497/]| |trunk|[branch|https://github.com/jonmeredith/cassandra/tree/commit_remote_branch/CASSANDRA-18511-trunk-FBBC1B68-F894-4605-A0BA-A4CA6F9BA47D]|[build|https://app.circleci.com/pipelines/github/jonmeredith/cassandra?branch=commit_remote_branch%2FCASSANDRA-18511-trunk-FBBC1B68-F894-4605-A0BA-A4CA6F9BA47D]|[build|unknown]| > Add support for JMX in the in-jvm dtest framework > - > > Key: CASSANDRA-18511 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18511 > Project: Cassandra > Issue Type: Improvement > Components: Test/dtest/java >Reporter: Doug Rohrer >Assignee: Doug Rohrer >Priority: Normal > Labels: pull-request-available > Fix For: 3.11.x, 4.0.x, 4.1.x, 5.0 > > Time Spent: 5h 10m > Remaining Estimate: 0h > > In many cases, it would be useful to be able to enable JMX endpoints within > the in-jvm dtest framework, including the existing JMX Getter test, which > used to simply spin up a JMX registry and then leave it running. There are > quite a few JMX-related functions that don’t have tests today, and some > external usages of the in-jvm dtest framework could also benefit from > exposing JMX like we did Native before. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18546) Remove unnecessary shuffling of GossipDigests in Gossiper#makeRandomGossipDigest
[
https://issues.apache.org/jira/browse/CASSANDRA-18546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-18546:
--
Fix Version/s: 4.0.11
4.1.3
5.0
(was: 5.x)
(was: 4.0.x)
(was: 4.1.x)
Source Control Link:
https://github.com/apache/cassandra/commit/f66adb0278aa56e8c2696db6f3fe24d311bf7b44
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
> Remove unnecessary shuffling of GossipDigests in
> Gossiper#makeRandomGossipDigest
>
>
> Key: CASSANDRA-18546
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18546
> Project: Cassandra
> Issue Type: Improvement
> Components: Cluster/Gossip
>Reporter: Cameron Zemek
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.0.11, 4.1.3, 5.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In going through trying to understand the Gossiper code I come across:
> {code:java}
> /**
> * The gossip digest is built based on randomization
> * rather than just looping through the collection of live endpoints.
> *
> * @param gDigests list of Gossip Digests.
> */
> private void makeRandomGossipDigest(List gDigests) {code}
> But I couldn't see what purpose randomization had. In fact in 3.11 it will
> call:
> {code:java}
> doSort(gDigestList); {code}
> On the receiving end, negating the purpose of the randomization.
>
> In discussion with [~stefan.miklosovic] he found this ticket CASSANDRA-14174
> So it seems to me this randomization may have been to allow for limited sizes
> of SYN messages. But this feature doesn't exist and as such by randomizing it
> is:
> * creating more garbage
> * using more CPU (sure its mostly trival; see next point)
> * more time spent on unnecessary functionality on the *single threaded*
> gossip stage.
> * complicating the code and making it more difficult to understand
> In fact there is a bug in the implementation:
> {code:java}
> int generation = 0;
> int maxVersion = 0; // local epstate will be part of
> endpointStateMap
> List endpoints = new
> ArrayList(endpointStateMap.keySet());
> Collections.shuffle(endpoints, random);
> for (InetAddress endpoint : endpoints)
> {
> epState = endpointStateMap.get(endpoint);
> if (epState != null)
> {
> generation = epState.getHeartBeatState().getGeneration();
> maxVersion = getMaxEndpointStateVersion(epState);
> }
> gDigests.add(new GossipDigest(endpoint, generation, maxVersion));
> } {code}
> If epState is null and we already had a non-null epState, then the next
> digest will use the generation and maxVersion of the previous iterated
> epState.
>
> Here is change to remove this randomization and fix the above bug,
> [https://github.com/apache/cassandra/pull/2357/commits/1ba422ab5de35f7057c7621ec3607dcbca19768c]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-12972) Print header and statistics for cassandra-stress output with arbitrary frequency
[ https://issues.apache.org/jira/browse/CASSANDRA-12972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-12972: -- Fix Version/s: 5.0 (was: 5.x) Source Control Link: https://github.com/apache/cassandra/commit/18cc821e302582766ca773ad06cf7db0dce85ec0 Resolution: Fixed Status: Resolved (was: Ready to Commit) > Print header and statistics for cassandra-stress output with arbitrary > frequency > > > Key: CASSANDRA-12972 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12972 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Tools, Tool/stress >Reporter: Vovodroid >Assignee: Stefan Miklosovic >Priority: Low > Labels: lhf > Fix For: 5.0 > > Attachments: 3.11.patch, signature.asc > > Time Spent: 20m > Remaining Estimate: 0h > > Currently header with columns meaning is printed only on test beginning. If > test is long it's not handy to interpret rows with numbers only. > I propose to repeatably print headers each half-minute or so. > Patch is available, is this improvement needed? > Thanks. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated (fad1f74570 -> cccc46cb23)
This is an automated email from the ASF dual-hosted git repository. smiklosovic pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git from fad1f74570 Rename the byte-comparable translation version to OSS50 add 18cc821e30 Print header and statistics for cassandra-stress output with arbitrary frequency add f66adb0278 Remove unnecessary shuffling of GossipDigests in Gossiper#makeRandomGossipDigest add 441285d58e Merge branch 'cassandra-4.0' into cassandra-4.1 add 46cb23 Merge branch 'cassandra-4.1' into trunk No new revisions were added by this update. Summary of changes: CHANGES.txt| 8 ++ .../pages/managing/tools/cassandra_stress.adoc | 2 + src/java/org/apache/cassandra/gms/Gossiper.java| 28 ++--- .../cassandra/stress/report/StressMetrics.java | 14 ++- .../cassandra/stress/settings/CliOption.java | 3 +- .../stress/settings/SettingsReporting.java | 116 + .../cassandra/stress/settings/StressSettings.java | 10 +- 7 files changed, 162 insertions(+), 19 deletions(-) create mode 100644 tools/stress/src/org/apache/cassandra/stress/settings/SettingsReporting.java - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-4.1 updated (2101ce947e -> 441285d58e)
This is an automated email from the ASF dual-hosted git repository. smiklosovic pushed a change to branch cassandra-4.1 in repository https://gitbox.apache.org/repos/asf/cassandra.git from 2101ce947e Merge branch 'cassandra-4.0' into cassandra-4.1 add f66adb0278 Remove unnecessary shuffling of GossipDigests in Gossiper#makeRandomGossipDigest add 441285d58e Merge branch 'cassandra-4.0' into cassandra-4.1 No new revisions were added by this update. Summary of changes: CHANGES.txt | 1 + src/java/org/apache/cassandra/gms/Gossiper.java | 28 - 2 files changed, 15 insertions(+), 14 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-4.0 updated (71b79cfbe3 -> f66adb0278)
This is an automated email from the ASF dual-hosted git repository. smiklosovic pushed a change to branch cassandra-4.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git from 71b79cfbe3 Increment version to 4.0.11 and 4.1.3 add f66adb0278 Remove unnecessary shuffling of GossipDigests in Gossiper#makeRandomGossipDigest No new revisions were added by this update. Summary of changes: CHANGES.txt | 1 + src/java/org/apache/cassandra/gms/Gossiper.java | 33 ++--- 2 files changed, 14 insertions(+), 20 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18546) Remove unnecessary shuffling of GossipDigests in Gossiper#makeRandomGossipDigest
[
https://issues.apache.org/jira/browse/CASSANDRA-18546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-18546:
--
Summary: Remove unnecessary shuffling of GossipDigests in
Gossiper#makeRandomGossipDigest (was: Remove Gossiper#makeRandomGossipDigest)
> Remove unnecessary shuffling of GossipDigests in
> Gossiper#makeRandomGossipDigest
>
>
> Key: CASSANDRA-18546
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18546
> Project: Cassandra
> Issue Type: Improvement
> Components: Cluster/Gossip
>Reporter: Cameron Zemek
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In going through trying to understand the Gossiper code I come across:
> {code:java}
> /**
> * The gossip digest is built based on randomization
> * rather than just looping through the collection of live endpoints.
> *
> * @param gDigests list of Gossip Digests.
> */
> private void makeRandomGossipDigest(List gDigests) {code}
> But I couldn't see what purpose randomization had. In fact in 3.11 it will
> call:
> {code:java}
> doSort(gDigestList); {code}
> On the receiving end, negating the purpose of the randomization.
>
> In discussion with [~stefan.miklosovic] he found this ticket CASSANDRA-14174
> So it seems to me this randomization may have been to allow for limited sizes
> of SYN messages. But this feature doesn't exist and as such by randomizing it
> is:
> * creating more garbage
> * using more CPU (sure its mostly trival; see next point)
> * more time spent on unnecessary functionality on the *single threaded*
> gossip stage.
> * complicating the code and making it more difficult to understand
> In fact there is a bug in the implementation:
> {code:java}
> int generation = 0;
> int maxVersion = 0; // local epstate will be part of
> endpointStateMap
> List endpoints = new
> ArrayList(endpointStateMap.keySet());
> Collections.shuffle(endpoints, random);
> for (InetAddress endpoint : endpoints)
> {
> epState = endpointStateMap.get(endpoint);
> if (epState != null)
> {
> generation = epState.getHeartBeatState().getGeneration();
> maxVersion = getMaxEndpointStateVersion(epState);
> }
> gDigests.add(new GossipDigest(endpoint, generation, maxVersion));
> } {code}
> If epState is null and we already had a non-null epState, then the next
> digest will use the generation and maxVersion of the previous iterated
> epState.
>
> Here is change to remove this randomization and fix the above bug,
> [https://github.com/apache/cassandra/pull/2357/commits/1ba422ab5de35f7057c7621ec3607dcbca19768c]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-8686) Introduce Latency Target for Stress
[ https://issues.apache.org/jira/browse/CASSANDRA-8686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17727673#comment-17727673 ] Stefan Miklosovic commented on CASSANDRA-8686: -- [~Bereng] what do you think about this feature? > Introduce Latency Target for Stress > --- > > Key: CASSANDRA-8686 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8686 > Project: Cassandra > Issue Type: Improvement > Components: Tool/stress >Reporter: jonathan lacefield >Assignee: Stefan Miklosovic >Priority: Low > Labels: stress > Time Spent: 40m > Remaining Estimate: 0h > > This item is a request to add a latency target to the rate option for the new > stress tool. The goal of the latency target would be to provide a guideline > for SLAs to the stress tool so the stress tool can determine threads and > throughputs that can be sustained while meeting the SLA targets. > For example: > cassandra-stress [options/commands] -rate latency p90=5 p95=10 p99=100 > The outcome of this command would be a stress execution that would gradually > increase threads, and hence throughput (trans/sec), until the latency profile > can no longer be satisfied with the current workload (yaml file definition) > and/or cluster. This would provide a ceiling for throughput and connections > for the given cluster, workload, and SLA profile. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-12972) Print header and statistics for cassandra-stress output with arbitrary frequency
[ https://issues.apache.org/jira/browse/CASSANDRA-12972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-12972: -- Summary: Print header and statistics for cassandra-stress output with arbitrary frequency (was: Print stress-tool header for statistics with arbitrary frequency) > Print header and statistics for cassandra-stress output with arbitrary > frequency > > > Key: CASSANDRA-12972 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12972 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Tools, Tool/stress >Reporter: Vovodroid >Assignee: Stefan Miklosovic >Priority: Low > Labels: lhf > Fix For: 5.x > > Attachments: 3.11.patch, signature.asc > > Time Spent: 20m > Remaining Estimate: 0h > > Currently header with columns meaning is printed only on test beginning. If > test is long it's not handy to interpret rows with numbers only. > I propose to repeatably print headers each half-minute or so. > Patch is available, is this improvement needed? > Thanks. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-12972) Print stress-tool header for statistics with arbitrary frequency
[ https://issues.apache.org/jira/browse/CASSANDRA-12972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-12972: -- Reviewers: Berenguer Blasi, Brandon Williams Status: Review In Progress (was: Needs Committer) > Print stress-tool header for statistics with arbitrary frequency > > > Key: CASSANDRA-12972 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12972 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Tools, Tool/stress >Reporter: Vovodroid >Assignee: Stefan Miklosovic >Priority: Low > Labels: lhf > Fix For: 5.x > > Attachments: 3.11.patch, signature.asc > > Time Spent: 20m > Remaining Estimate: 0h > > Currently header with columns meaning is printed only on test beginning. If > test is long it's not handy to interpret rows with numbers only. > I propose to repeatably print headers each half-minute or so. > Patch is available, is this improvement needed? > Thanks. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-12972) Print stress-tool header for statistics with arbitrary frequency
[ https://issues.apache.org/jira/browse/CASSANDRA-12972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-12972: -- Status: Ready to Commit (was: Review In Progress) > Print stress-tool header for statistics with arbitrary frequency > > > Key: CASSANDRA-12972 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12972 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Tools, Tool/stress >Reporter: Vovodroid >Assignee: Stefan Miklosovic >Priority: Low > Labels: lhf > Fix For: 5.x > > Attachments: 3.11.patch, signature.asc > > Time Spent: 20m > Remaining Estimate: 0h > > Currently header with columns meaning is printed only on test beginning. If > test is long it's not handy to interpret rows with numbers only. > I propose to repeatably print headers each half-minute or so. > Patch is available, is this improvement needed? > Thanks. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17194) Migrate thresholds for compaction to guardrails
[
https://issues.apache.org/jira/browse/CASSANDRA-17194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17727634#comment-17727634
]
Andres de la Peña commented on CASSANDRA-17194:
---
Thanks for the reviews :)
{quote}The CI are not all green, can you take a look ? Thanks.
{quote}
[~maxwellguo] There is an explanation for the test failures in my last comment.
> Migrate thresholds for compaction to guardrails
> ---
>
> Key: CASSANDRA-17194
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17194
> 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: 5.x
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> Migrate the existing thresholds for compaction:
> {code:java}
> compaction_large_partition_warning_threshold_mb: 100
> compaction_tombstone_warning_threshold: 10
> {code}
> To a new set of guardrails under the {{guardrails}} section, for example:
> {code:java}
> partition_size_warn_threshold: 50MiB
> partition_size_fail_threshold: 100MiB
> partition_tombstones_fail_threshold: 5
> partition_tombstones_fail_threshold: 10
> {code}
> Note that since these guardrails would be attached to a background process
> there wouldn't be abort/fail thresholds because we don't want to stop
> compaction.
> At the moment these thresholds are enabled by default, while guardrails are
> globally disabled by default, so we should consider whether we want to
> globally enable guardrails, or change these thresholds to disabled by
> default, or don't migrate the thresholds.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17194) Migrate thresholds for compaction to guardrails
[
https://issues.apache.org/jira/browse/CASSANDRA-17194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-17194:
--
Description:
Migrate the existing thresholds for compaction:
{code:java}
compaction_large_partition_warning_threshold_mb: 100
compaction_tombstone_warning_threshold: 10
{code}
To a new set of guardrails under the {{guardrails}} section, for example:
{code:java}
partition_size_warn_threshold: 50MiB
partition_size_fail_threshold: 100MiB
partition_tombstones_fail_threshold: 5
partition_tombstones_fail_threshold: 10
{code}
Note that since these guardrails would be attached to a background process
there wouldn't be abort/fail thresholds because we don't want to stop
compaction.
At the moment these thresholds are enabled by default, while guardrails are
globally disabled by default, so we should consider whether we want to globally
enable guardrails, or change these thresholds to disabled by default, or don't
migrate the thresholds.
was:
Migrate the existing thresholds for compaction:
{code:java}
compaction_large_partition_warning_threshold_mb: 100
compaction_tombstone_warning_threshold: 10
{code}
To a new guardrail under the {{guardrails}} section, for example:
{code:java}
guardrails:
...
compacted_partition_size_warn_threshold_mb: 100
compacted_partition_tombstone_warn_threshold: 10
{code}
Or maybe:
{code:java}
guardrails:
...
compacted_partition_size:
warn_threshold_mb: 100
compacted_partition_tombstones:
warn_threshold: 10
{code}
Note that since these guardrails would be attached to a background process
there wouldn't be abort/fail thresholds because we don't want to stop
compaction.
At the moment these thresholds are enabled by default, while guardrails are
globally disabled by default, so we should consider whether we want to globally
enable guardrails, or change these thresholds to disabled by default, or don't
migrate the thresholds.
> Migrate thresholds for compaction to guardrails
> ---
>
> Key: CASSANDRA-17194
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17194
> 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: 5.x
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> Migrate the existing thresholds for compaction:
> {code:java}
> compaction_large_partition_warning_threshold_mb: 100
> compaction_tombstone_warning_threshold: 10
> {code}
> To a new set of guardrails under the {{guardrails}} section, for example:
> {code:java}
> partition_size_warn_threshold: 50MiB
> partition_size_fail_threshold: 100MiB
> partition_tombstones_fail_threshold: 5
> partition_tombstones_fail_threshold: 10
> {code}
> Note that since these guardrails would be attached to a background process
> there wouldn't be abort/fail thresholds because we don't want to stop
> compaction.
> At the moment these thresholds are enabled by default, while guardrails are
> globally disabled by default, so we should consider whether we want to
> globally enable guardrails, or change these thresholds to disabled by
> default, or don't migrate the thresholds.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18504) Added support for type VECTOR
[ https://issues.apache.org/jira/browse/CASSANDRA-18504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17727613#comment-17727613 ] Bret McGuire commented on CASSANDRA-18504: -- A note on the serialization format: right now we're serializing vectors as just a sequence of the underlying subtypes. So if we have a vector of floats of dimension 3 we just write three serialized floats one after another on the wire; there's no size information included for either the number of elements in the list or the size of any one element. This differs from how other collections (such as lists and maps) and UDTs are handled. In those cases we send along (a) the element size of a given collection and (b) the size of each element (included in the bytes structure). Such a change isn't unreasonable, at least not for fixed size types (and perhaps the variable types as well) since hypothetically the codecs should be aware of how big a given type might be. But that's not what, say, the Java driver does at the moment. Let's take the example of a float type; when decoding a ByteBuffer expected to contain an instance of this type we expect that ByteBuffer to contain precisely four bytes. The assumption is that something upstream has pulled off exactly the expected number of bytes from some larger ByteBuffer. I certainly can take steps to expose the expected number of bytes for a given codec. But it did seem worthwhile to highlight the difference and make sure that this difference in serialization formats represents an explicit choice. > Added support for type VECTOR > -- > > Key: CASSANDRA-18504 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18504 > Project: Cassandra > Issue Type: Improvement > Components: Cluster/Schema, CQL/Syntax >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 5.x > > Time Spent: 5.5h > Remaining Estimate: 0h > > Based off several mailing list threads (see "[POLL] Vector type for ML”, > "[DISCUSS] New data type for vector search”, and "Adding vector search to SAI > with heirarchical navigable small world graph index”), its desirable to add a > new type “VECTOR” that has the following properties > 1) fixed length array > 2) elements may not be null > 3) flatten array (aka multi-cell = false) -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17433) Revise use of pytz in Python >= 3.9
[ https://issues.apache.org/jira/browse/CASSANDRA-17433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-17433: - Status: Open (was: Patch Available) > Revise use of pytz in Python >= 3.9 > > > Key: CASSANDRA-17433 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17433 > Project: Cassandra > Issue Type: Task > Components: CQL/Interpreter >Reporter: Brad Schoening >Assignee: Leonard Ma >Priority: Low > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > PEP 615 – Support for the IANA Time Zone Database in the Standard Library > class ZoneInfo > PEP 615 (Python 3.9) has obsoleted the 3rd party Olsen tz library 'pytz' with > support for the IANA Time Zone Database. The code which imports this in > cqlshmain.py and tests in > [test_cqlsh_output.py|https://github.com/apache/cassandra/pull/1493/files/9c658a20c669d11a54ecc6b42ba083da13de0103#diff-f5a3955faadf50a1292df481044b83cefc44b2dac46676022c80bad076491a50] > should be updated accordingly. > This can be done with something like: > if sys.version_info >= (3,9): > try: > import zoneinfo > else: > try: > import pytz > ... -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-11745) Add bytes limit to queries and paging
[ https://issues.apache.org/jira/browse/CASSANDRA-11745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh McKenzie updated CASSANDRA-11745: -- Reviewers: Josh McKenzie > Add bytes limit to queries and paging > - > > Key: CASSANDRA-11745 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11745 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Core >Reporter: Richard Low >Assignee: Jacek Lewandowski >Priority: Normal > Fix For: 5.0 > > > For some data models, values may be of very different sizes. When querying > data, limit by count doesn’t work well and leads to timeouts. It would be > much better to limit by size of the response, probably by stopping at the > first row that goes above the limit. This applies to paging too so you can > safely page through such data without timeout worries. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18546) Remove Gossiper#makeRandomGossipDigest
[
https://issues.apache.org/jira/browse/CASSANDRA-18546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-18546:
-
Status: Ready to Commit (was: Review In Progress)
> Remove Gossiper#makeRandomGossipDigest
> --
>
> Key: CASSANDRA-18546
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18546
> Project: Cassandra
> Issue Type: Improvement
> Components: Cluster/Gossip
>Reporter: Cameron Zemek
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In going through trying to understand the Gossiper code I come across:
> {code:java}
> /**
> * The gossip digest is built based on randomization
> * rather than just looping through the collection of live endpoints.
> *
> * @param gDigests list of Gossip Digests.
> */
> private void makeRandomGossipDigest(List gDigests) {code}
> But I couldn't see what purpose randomization had. In fact in 3.11 it will
> call:
> {code:java}
> doSort(gDigestList); {code}
> On the receiving end, negating the purpose of the randomization.
>
> In discussion with [~stefan.miklosovic] he found this ticket CASSANDRA-14174
> So it seems to me this randomization may have been to allow for limited sizes
> of SYN messages. But this feature doesn't exist and as such by randomizing it
> is:
> * creating more garbage
> * using more CPU (sure its mostly trival; see next point)
> * more time spent on unnecessary functionality on the *single threaded*
> gossip stage.
> * complicating the code and making it more difficult to understand
> In fact there is a bug in the implementation:
> {code:java}
> int generation = 0;
> int maxVersion = 0; // local epstate will be part of
> endpointStateMap
> List endpoints = new
> ArrayList(endpointStateMap.keySet());
> Collections.shuffle(endpoints, random);
> for (InetAddress endpoint : endpoints)
> {
> epState = endpointStateMap.get(endpoint);
> if (epState != null)
> {
> generation = epState.getHeartBeatState().getGeneration();
> maxVersion = getMaxEndpointStateVersion(epState);
> }
> gDigests.add(new GossipDigest(endpoint, generation, maxVersion));
> } {code}
> If epState is null and we already had a non-null epState, then the next
> digest will use the generation and maxVersion of the previous iterated
> epState.
>
> Here is change to remove this randomization and fix the above bug,
> [https://github.com/apache/cassandra/pull/2357/commits/1ba422ab5de35f7057c7621ec3607dcbca19768c]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18546) Remove Gossiper#makeRandomGossipDigest
[
https://issues.apache.org/jira/browse/CASSANDRA-18546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17727568#comment-17727568
]
Brandon Williams commented on CASSANDRA-18546:
--
+1
> Remove Gossiper#makeRandomGossipDigest
> --
>
> Key: CASSANDRA-18546
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18546
> Project: Cassandra
> Issue Type: Improvement
> Components: Cluster/Gossip
>Reporter: Cameron Zemek
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In going through trying to understand the Gossiper code I come across:
> {code:java}
> /**
> * The gossip digest is built based on randomization
> * rather than just looping through the collection of live endpoints.
> *
> * @param gDigests list of Gossip Digests.
> */
> private void makeRandomGossipDigest(List gDigests) {code}
> But I couldn't see what purpose randomization had. In fact in 3.11 it will
> call:
> {code:java}
> doSort(gDigestList); {code}
> On the receiving end, negating the purpose of the randomization.
>
> In discussion with [~stefan.miklosovic] he found this ticket CASSANDRA-14174
> So it seems to me this randomization may have been to allow for limited sizes
> of SYN messages. But this feature doesn't exist and as such by randomizing it
> is:
> * creating more garbage
> * using more CPU (sure its mostly trival; see next point)
> * more time spent on unnecessary functionality on the *single threaded*
> gossip stage.
> * complicating the code and making it more difficult to understand
> In fact there is a bug in the implementation:
> {code:java}
> int generation = 0;
> int maxVersion = 0; // local epstate will be part of
> endpointStateMap
> List endpoints = new
> ArrayList(endpointStateMap.keySet());
> Collections.shuffle(endpoints, random);
> for (InetAddress endpoint : endpoints)
> {
> epState = endpointStateMap.get(endpoint);
> if (epState != null)
> {
> generation = epState.getHeartBeatState().getGeneration();
> maxVersion = getMaxEndpointStateVersion(epState);
> }
> gDigests.add(new GossipDigest(endpoint, generation, maxVersion));
> } {code}
> If epState is null and we already had a non-null epState, then the next
> digest will use the generation and maxVersion of the previous iterated
> epState.
>
> Here is change to remove this randomization and fix the above bug,
> [https://github.com/apache/cassandra/pull/2357/commits/1ba422ab5de35f7057c7621ec3607dcbca19768c]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18556) Leak detected issue in cassandra 3.11.1
[
https://issues.apache.org/jira/browse/CASSANDRA-18556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-18556:
-
Resolution: Invalid
Status: Resolved (was: Triage Needed)
This jira is for the development of Apache Cassandra, and as such makes for a
poor vehicle for support. For support I recommend contacting the community on
the ML or slack: https://cassandra.apache.org/_/community.html
Also note that 3.11.1 is nearly 6 years old at this point; you should probably
upgrade to the latest 3.11 release and see if your problems persist.
> Leak detected issue in cassandra 3.11.1
> ---
>
> Key: CASSANDRA-18556
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18556
> Project: Cassandra
> Issue Type: Bug
>Reporter: Purushottam baghel
>Priority: Normal
> Attachments: Screenshot 2023-05-30 at 10.50.32 AM.png
>
>
> We are running 36 nodes Cassandra cluster. All nodes have the some config,
> Cassandra version is 3.11.1. Suddenly, we are seeing fluctuation in storage
> available graphs for the 2 nodes. Attaching the last 7 days used storage
> graph for the Cassandra nodes.
> Further investigation, we saw errors in the logs of these 2 Cassandra node
> logs.
> {code:java}
> ERROR [CompactionExecutor:164360] 2023-05-04 00:30:58,094
> CassandraDaemon.java:228 - Exception in thread
> Thread[CompactionExecutor:164360,1,main]
> java.lang.IllegalArgumentException: null
> at java.nio.Buffer.position(Buffer.java:244) ~[na:1.8.0_131]
> at
> org.apache.cassandra.io.util.SafeMemoryWriter.reallocate(SafeMemoryWriter.java:59)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.io.util.SafeMemoryWriter.setCapacity(SafeMemoryWriter.java:68)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.io.sstable.IndexSummaryBuilder.prepareToCommit(IndexSummaryBuilder.java:250)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.io.sstable.format.big.BigTableWriter$IndexWriter.doPrepare(BigTableWriter.java:524)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.utils.concurrent.Transactional$AbstractTransactional.prepareToCommit(Transactional.java:173)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.io.sstable.format.big.BigTableWriter$TransactionalProxy.doPrepare(BigTableWriter.java:364)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.utils.concurrent.Transactional$AbstractTransactional.prepareToCommit(Transactional.java:173)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.io.sstable.format.SSTableWriter.prepareToCommit(SSTableWriter.java:281)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.io.sstable.SSTableRewriter.doPrepare(SSTableRewriter.java:379)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.utils.concurrent.Transactional$AbstractTransactional.prepareToCommit(Transactional.java:173)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.db.compaction.writers.CompactionAwareWriter.doPrepare(CompactionAwareWriter.java:111)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.utils.concurrent.Transactional$AbstractTransactional.prepareToCommit(Transactional.java:173)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.utils.concurrent.Transactional$AbstractTransactional.finish(Transactional.java:184)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.db.compaction.writers.CompactionAwareWriter.finish(CompactionAwareWriter.java:121)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.db.compaction.CompactionTask.runMayThrow(CompactionTask.java:220)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:85)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:61)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.db.compaction.CompactionManager$BackgroundCompactionCandidate.run(CompactionManager.java:268)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> ~[na:1.8.0_131]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> ~[na:1.8.0_131]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> ~[na:1.8.0_131]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>
[jira] [Commented] (CASSANDRA-14227) Extend maximum expiration date
[
https://issues.apache.org/jira/browse/CASSANDRA-14227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17727560#comment-17727560
]
Berenguer Blasi commented on CASSANDRA-14227:
-
[~benedict] Everything looks good as far as we can see. Do you think you could
find a gap see if we can +1 and merge :-) You're probably most interested in
the yaml feature flag commit
[here|https://github.com/apache/cassandra/pull/1891/commits/159eabbc7a0dec932864447ecffbaae5ffe66c4c]
> Extend maximum expiration date
> --
>
> Key: CASSANDRA-14227
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14227
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Local Write-Read Paths
>Reporter: Paulo Motta (Deprecated)
>Assignee: Berenguer Blasi
>Priority: Urgent
> Fix For: 5.x
>
> Attachments: C14227 Perf check 2023.03.21.pdf, C14227 Perf check
> 2023.05.26.pdf, screenshot-1.png, screenshot-2.png, screenshot-3.png,
> screenshot-4.png, unnamed-1.png
>
>
> The maximum expiration timestamp that can be represented by the storage
> engine is
> 2038-01-19T03:14:06+00:00 due to the encoding of {{localExpirationTime}} as
> an int32.
> On CASSANDRA-14092 we added an overflow policy which rejects requests with
> expiration above the maximum date as a temporary measure, but we should
> remove this limitation by updating the storage engine to support at least the
> maximum allowed TTL of 20 years.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14227) Extend maximum expiration date
[
https://issues.apache.org/jira/browse/CASSANDRA-14227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17727558#comment-17727558
]
Andres de la Peña commented on CASSANDRA-14227:
---
Looks good to me after rebase, and CI also looks good. +1 from me. The few
remaining, trivial suggestions about comments can be addressed on commit.
> Extend maximum expiration date
> --
>
> Key: CASSANDRA-14227
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14227
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Local Write-Read Paths
>Reporter: Paulo Motta (Deprecated)
>Assignee: Berenguer Blasi
>Priority: Urgent
> Fix For: 5.x
>
> Attachments: C14227 Perf check 2023.03.21.pdf, C14227 Perf check
> 2023.05.26.pdf, screenshot-1.png, screenshot-2.png, screenshot-3.png,
> screenshot-4.png, unnamed-1.png
>
>
> The maximum expiration timestamp that can be represented by the storage
> engine is
> 2038-01-19T03:14:06+00:00 due to the encoding of {{localExpirationTime}} as
> an int32.
> On CASSANDRA-14092 we added an overflow policy which rejects requests with
> expiration above the maximum date as a temporary measure, but we should
> remove this limitation by updating the storage engine to support at least the
> maximum allowed TTL of 20 years.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-12937) Default setting (yaml) for SSTable compression
[
https://issues.apache.org/jira/browse/CASSANDRA-12937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic reassigned CASSANDRA-12937:
-
Assignee: Stefan Miklosovic (was: Claude Warren)
> Default setting (yaml) for SSTable compression
> --
>
> Key: CASSANDRA-12937
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12937
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Michael Semb Wever
>Assignee: Stefan Miklosovic
>Priority: Low
> Labels: AdventCalendar2021, lhf
> Fix For: 5.x
>
> Time Spent: 3.5h
> Remaining Estimate: 0h
>
> In many situations the choice of compression for sstables is more relevant to
> the disks attached than to the schema and data.
> This issue is to add to cassandra.yaml a default value for sstable
> compression that new tables will inherit (instead of the defaults found in
> {{CompressionParams.DEFAULT}}.
> Examples where this can be relevant are filesystems that do on-the-fly
> compression (btrfs, zfs) or specific disk configurations or even specific C*
> versions (see CASSANDRA-10995 ).
> +Additional information for newcomers+
> Some new fields need to be added to {{cassandra.yaml}} to allow specifying
> the field required for defining the default compression parameters. In
> {{DatabaseDescriptor}} a new {{CompressionParams}} field should be added for
> the default compression. This field should be initialized in
> {{DatabaseDescriptor.applySimpleConfig()}}. At the different places where
> {{CompressionParams.DEFAULT}} was used the code should call
> {{DatabaseDescriptor#getDefaultCompressionParams}} that should return some
> copy of configured {{CompressionParams}}.
> Some unit test using {{OverrideConfigurationLoader}} should be used to test
> that the table schema use the new default when a new table is created (see
> CreateTest for some example).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-12937) Default setting (yaml) for SSTable compression
[
https://issues.apache.org/jira/browse/CASSANDRA-12937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17727539#comment-17727539
]
Stefan Miklosovic commented on CASSANDRA-12937:
---
[~claude] I will assign this to myself temporarily to reflect my progress on
fixing the tests. I am pretty close to finish it.
> Default setting (yaml) for SSTable compression
> --
>
> Key: CASSANDRA-12937
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12937
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Michael Semb Wever
>Assignee: Claude Warren
>Priority: Low
> Labels: AdventCalendar2021, lhf
> Fix For: 5.x
>
> Time Spent: 3.5h
> Remaining Estimate: 0h
>
> In many situations the choice of compression for sstables is more relevant to
> the disks attached than to the schema and data.
> This issue is to add to cassandra.yaml a default value for sstable
> compression that new tables will inherit (instead of the defaults found in
> {{CompressionParams.DEFAULT}}.
> Examples where this can be relevant are filesystems that do on-the-fly
> compression (btrfs, zfs) or specific disk configurations or even specific C*
> versions (see CASSANDRA-10995 ).
> +Additional information for newcomers+
> Some new fields need to be added to {{cassandra.yaml}} to allow specifying
> the field required for defining the default compression parameters. In
> {{DatabaseDescriptor}} a new {{CompressionParams}} field should be added for
> the default compression. This field should be initialized in
> {{DatabaseDescriptor.applySimpleConfig()}}. At the different places where
> {{CompressionParams.DEFAULT}} was used the code should call
> {{DatabaseDescriptor#getDefaultCompressionParams}} that should return some
> copy of configured {{CompressionParams}}.
> Some unit test using {{OverrideConfigurationLoader}} should be used to test
> that the table schema use the new default when a new table is created (see
> CreateTest for some example).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-12937) Default setting (yaml) for SSTable compression
[
https://issues.apache.org/jira/browse/CASSANDRA-12937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-12937:
--
Status: In Progress (was: Patch Available)
> Default setting (yaml) for SSTable compression
> --
>
> Key: CASSANDRA-12937
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12937
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Michael Semb Wever
>Assignee: Claude Warren
>Priority: Low
> Labels: AdventCalendar2021, lhf
> Fix For: 5.x
>
> Time Spent: 3.5h
> Remaining Estimate: 0h
>
> In many situations the choice of compression for sstables is more relevant to
> the disks attached than to the schema and data.
> This issue is to add to cassandra.yaml a default value for sstable
> compression that new tables will inherit (instead of the defaults found in
> {{CompressionParams.DEFAULT}}.
> Examples where this can be relevant are filesystems that do on-the-fly
> compression (btrfs, zfs) or specific disk configurations or even specific C*
> versions (see CASSANDRA-10995 ).
> +Additional information for newcomers+
> Some new fields need to be added to {{cassandra.yaml}} to allow specifying
> the field required for defining the default compression parameters. In
> {{DatabaseDescriptor}} a new {{CompressionParams}} field should be added for
> the default compression. This field should be initialized in
> {{DatabaseDescriptor.applySimpleConfig()}}. At the different places where
> {{CompressionParams.DEFAULT}} was used the code should call
> {{DatabaseDescriptor#getDefaultCompressionParams}} that should return some
> copy of configured {{CompressionParams}}.
> Some unit test using {{OverrideConfigurationLoader}} should be used to test
> that the table schema use the new default when a new table is created (see
> CreateTest for some example).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18546) Remove Gossiper#makeRandomGossipDigest
[
https://issues.apache.org/jira/browse/CASSANDRA-18546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-18546:
-
Reviewers: Brandon Williams
Status: Review In Progress (was: Needs Committer)
> Remove Gossiper#makeRandomGossipDigest
> --
>
> Key: CASSANDRA-18546
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18546
> Project: Cassandra
> Issue Type: Improvement
> Components: Cluster/Gossip
>Reporter: Cameron Zemek
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In going through trying to understand the Gossiper code I come across:
> {code:java}
> /**
> * The gossip digest is built based on randomization
> * rather than just looping through the collection of live endpoints.
> *
> * @param gDigests list of Gossip Digests.
> */
> private void makeRandomGossipDigest(List gDigests) {code}
> But I couldn't see what purpose randomization had. In fact in 3.11 it will
> call:
> {code:java}
> doSort(gDigestList); {code}
> On the receiving end, negating the purpose of the randomization.
>
> In discussion with [~stefan.miklosovic] he found this ticket CASSANDRA-14174
> So it seems to me this randomization may have been to allow for limited sizes
> of SYN messages. But this feature doesn't exist and as such by randomizing it
> is:
> * creating more garbage
> * using more CPU (sure its mostly trival; see next point)
> * more time spent on unnecessary functionality on the *single threaded*
> gossip stage.
> * complicating the code and making it more difficult to understand
> In fact there is a bug in the implementation:
> {code:java}
> int generation = 0;
> int maxVersion = 0; // local epstate will be part of
> endpointStateMap
> List endpoints = new
> ArrayList(endpointStateMap.keySet());
> Collections.shuffle(endpoints, random);
> for (InetAddress endpoint : endpoints)
> {
> epState = endpointStateMap.get(endpoint);
> if (epState != null)
> {
> generation = epState.getHeartBeatState().getGeneration();
> maxVersion = getMaxEndpointStateVersion(epState);
> }
> gDigests.add(new GossipDigest(endpoint, generation, maxVersion));
> } {code}
> If epState is null and we already had a non-null epState, then the next
> digest will use the generation and maxVersion of the previous iterated
> epState.
>
> Here is change to remove this randomization and fix the above bug,
> [https://github.com/apache/cassandra/pull/2357/commits/1ba422ab5de35f7057c7621ec3607dcbca19768c]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-12972) Print stress-tool header for statistics with arbitrary frequency
[ https://issues.apache.org/jira/browse/CASSANDRA-12972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17727531#comment-17727531 ] Brandon Williams commented on CASSANDRA-12972: -- LGTM too, +1. > Print stress-tool header for statistics with arbitrary frequency > > > Key: CASSANDRA-12972 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12972 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Tools, Tool/stress >Reporter: Vovodroid >Assignee: Stefan Miklosovic >Priority: Low > Labels: lhf > Fix For: 5.x > > Attachments: 3.11.patch, signature.asc > > Time Spent: 20m > Remaining Estimate: 0h > > Currently header with columns meaning is printed only on test beginning. If > test is long it's not handy to interpret rows with numbers only. > I propose to repeatably print headers each half-minute or so. > Patch is available, is this improvement needed? > Thanks. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-staging updated (3b0623b4 -> ae0eb680)
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 3b0623b4 generate docs for 1b144e50 new ae0eb680 generate docs for 1b144e50 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 (3b0623b4) \ N -- N -- N refs/heads/asf-staging (ae0eb680) 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 4796900 -> 4796900 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-18150) Prefer snakeyaml's SafeConstructor over Constructor
[ https://issues.apache.org/jira/browse/CASSANDRA-18150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17727495#comment-17727495 ] Brandon Williams commented on CASSANDRA-18150: -- Please open a new ticket, thanks. > Prefer snakeyaml's SafeConstructor over Constructor > --- > > Key: CASSANDRA-18150 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18150 > Project: Cassandra > Issue Type: Improvement > Components: Local/Config >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.0.29, 3.11.15, 4.0.8, 4.1.1, 5.0 > > > CVE-2022-1471 allows RCE through the Constructor class. While this isn't a > concern since yaml is only used for configuration, it is simple enough to > switch to SafeConstructor and harden the server a little more. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17997) Improve git branch handling for CircleCI generate.sh
[ https://issues.apache.org/jira/browse/CASSANDRA-17997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17727423#comment-17727423 ] Berenguer Blasi commented on CASSANDRA-17997: - BTW I am working on a similar ticket, let me know if you prefer I take over if you're busy... > Improve git branch handling for CircleCI generate.sh > > > Key: CASSANDRA-17997 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17997 > Project: Cassandra > Issue Type: Improvement > Components: CI >Reporter: Derek Chen-Becker >Assignee: Derek Chen-Becker >Priority: Normal > Fix For: 3.0.x, 4.0.x, 4.1.x, 5.x > > > The generate.sh script assumes a base git branch that is local and named > after the official repo branch (e.g. `cassandra-3.11`). This may not be a > local branch if the developer has recently cloned the repo and is creating a > work branch, and will lead to the git commands in generate.sh failing: > > ``` > fatal: ambiguous argument 'cassandra-3.11...HEAD': unknown revision or path > not in the working tree. > Use '--' to separate paths from revisions, like this: > 'git [...] -- [...]' > ``` > We should be able to make some sanity checks to better guide or warn the > developer if things aren't set up properly to check against git. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18150) Prefer snakeyaml's SafeConstructor over Constructor
[ https://issues.apache.org/jira/browse/CASSANDRA-18150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17727385#comment-17727385 ] Arnout Engelen commented on CASSANDRA-18150: The change in [https://github.com/apache/cassandra/commit/e7f55ab8c3bd6bac4c87354afec231d7237c35b8] might not be effective: it seems that, confusingly, while the 'CustomConstructor' class extends the 'SafeConstructor' one, not every 'Custom' constructor is actually necessarily 'Safe' :(. Should we reopen this issue or create a new one? > Prefer snakeyaml's SafeConstructor over Constructor > --- > > Key: CASSANDRA-18150 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18150 > Project: Cassandra > Issue Type: Improvement > Components: Local/Config >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.0.29, 3.11.15, 4.0.8, 4.1.1, 5.0 > > > CVE-2022-1471 allows RCE through the Constructor class. While this isn't a > concern since yaml is only used for configuration, it is simple enough to > switch to SafeConstructor and harden the server a little more. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17194) Migrate thresholds for compaction to guardrails
[
https://issues.apache.org/jira/browse/CASSANDRA-17194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17727356#comment-17727356
]
Berenguer Blasi commented on CASSANDRA-17194:
-
Very similar to CASSANDRA-18550 indeed. It needs a rebase and new CI runs bc of
the recent trunk failures but approach LGTM
> Migrate thresholds for compaction to guardrails
> ---
>
> Key: CASSANDRA-17194
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17194
> 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: 5.x
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Migrate the existing thresholds for compaction:
> {code:java}
> compaction_large_partition_warning_threshold_mb: 100
> compaction_tombstone_warning_threshold: 10
> {code}
> To a new guardrail under the {{guardrails}} section, for example:
> {code:java}
> guardrails:
> ...
> compacted_partition_size_warn_threshold_mb: 100
> compacted_partition_tombstone_warn_threshold: 10
> {code}
> Or maybe:
> {code:java}
> guardrails:
> ...
> compacted_partition_size:
> warn_threshold_mb: 100
> compacted_partition_tombstones:
> warn_threshold: 10
> {code}
> Note that since these guardrails would be attached to a background process
> there wouldn't be abort/fail thresholds because we don't want to stop
> compaction.
> At the moment these thresholds are enabled by default, while guardrails are
> globally disabled by default, so we should consider whether we want to
> globally enable guardrails, or change these thresholds to disabled by
> default, or don't migrate the thresholds.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-12972) Print stress-tool header for statistics with arbitrary frequency
[ https://issues.apache.org/jira/browse/CASSANDRA-12972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17727347#comment-17727347 ] Berenguer Blasi commented on CASSANDRA-12972: - LGTM +1. I would wait for [~brandon.williams]'s input before merging though as he might have further comments > Print stress-tool header for statistics with arbitrary frequency > > > Key: CASSANDRA-12972 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12972 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Tools, Tool/stress >Reporter: Vovodroid >Assignee: Stefan Miklosovic >Priority: Low > Labels: lhf > Fix For: 5.x > > Attachments: 3.11.patch, signature.asc > > Time Spent: 20m > Remaining Estimate: 0h > > Currently header with columns meaning is printed only on test beginning. If > test is long it's not handy to interpret rows with numbers only. > I propose to repeatably print headers each half-minute or so. > Patch is available, is this improvement needed? > Thanks. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17997) Improve git branch handling for CircleCI generate.sh
[ https://issues.apache.org/jira/browse/CASSANDRA-17997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17727337#comment-17727337 ] Berenguer Blasi commented on CASSANDRA-17997: - Hi, sorry I am bit lost. Why is there no trunk PR? In any case the approach looks good but we'd need a rebase imo. > Improve git branch handling for CircleCI generate.sh > > > Key: CASSANDRA-17997 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17997 > Project: Cassandra > Issue Type: Improvement > Components: CI >Reporter: Derek Chen-Becker >Assignee: Derek Chen-Becker >Priority: Normal > Fix For: 3.0.x, 4.0.x, 4.1.x, 5.x > > > The generate.sh script assumes a base git branch that is local and named > after the official repo branch (e.g. `cassandra-3.11`). This may not be a > local branch if the developer has recently cloned the repo and is creating a > work branch, and will lead to the git commands in generate.sh failing: > > ``` > fatal: ambiguous argument 'cassandra-3.11...HEAD': unknown revision or path > not in the working tree. > Use '--' to separate paths from revisions, like this: > 'git [...] -- [...]' > ``` > We should be able to make some sanity checks to better guide or warn the > developer if things aren't set up properly to check against git. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17433) Revise use of pytz in Python >= 3.9
[ https://issues.apache.org/jira/browse/CASSANDRA-17433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17727336#comment-17727336 ] Leonard Ma commented on CASSANDRA-17433: Ok thanks, I'll take a look at updating that tomorrow > Revise use of pytz in Python >= 3.9 > > > Key: CASSANDRA-17433 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17433 > Project: Cassandra > Issue Type: Task > Components: CQL/Interpreter >Reporter: Brad Schoening >Assignee: Leonard Ma >Priority: Low > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > PEP 615 – Support for the IANA Time Zone Database in the Standard Library > class ZoneInfo > PEP 615 (Python 3.9) has obsoleted the 3rd party Olsen tz library 'pytz' with > support for the IANA Time Zone Database. The code which imports this in > cqlshmain.py and tests in > [test_cqlsh_output.py|https://github.com/apache/cassandra/pull/1493/files/9c658a20c669d11a54ecc6b42ba083da13de0103#diff-f5a3955faadf50a1292df481044b83cefc44b2dac46676022c80bad076491a50] > should be updated accordingly. > This can be done with something like: > if sys.version_info >= (3,9): > try: > import zoneinfo > else: > try: > import pytz > ... -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
