[jira] [Commented] (CASSANDRA-18305) Enhance nodetool compactionstats with existing MBean metrics
[
https://issues.apache.org/jira/browse/CASSANDRA-18305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17728916#comment-17728916
]
Manish Ghildiyal commented on CASSANDRA-18305:
--
Backported test to 4.0.
> Enhance nodetool compactionstats with existing MBean metrics
>
>
> Key: CASSANDRA-18305
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18305
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Brad Schoening
>Assignee: Manish Ghildiyal
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Nodetool compactionstats reports only on active compactions, if nothing is
> active, you see only:
> {quote}$nodetool compactionstats
> pending tasks: 0
> {quote}
> but in the MBean Compaction/TotalCompactionsCompleted there are recent
> statistic in events/second for:
> * Count
> * FifteenMinueRate
> * FiveMinueRate
> * MeanRate
> * OneMinuteRate
> 1) It would be useful to see in addition:
> {quote}pending tasks: 0
> compactions completed: 20
> 1 minute rate: 0/second
> 5 minute rate: 2.3/second
> 15 minute rate: 4.6/second
> {quote}
> 2) Since compaction_throughput_mb_per_sec is a throttling parameter in
> cassandra.yaml (default 64 MBps), it would be nice to show the actual
> compaction throughput and be able to observe if you're close to the limit.
> I.e.,
> {quote}compaction throughput 13.2 MBps / 16 MBps (82.5%)
> {quote}
> 3) for completness, compactionstats should list the number of concurrent
> compactors configured, perhaps simply add to existing 'pending tasks' line:
> {quote}4 concurrent compactors, 0 pending tasks
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-staging updated (ab9e58a2 -> 567d797a)
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 ab9e58a2 generate docs for 1b144e50 new 567d797a 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 (ab9e58a2) \ N -- N -- N refs/heads/asf-staging (567d797a) 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
[cassandra-website] branch asf-staging updated (a809e683 -> ab9e58a2)
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 a809e683 generate docs for 1b144e50 new ab9e58a2 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 (a809e683) \ N -- N -- N refs/heads/asf-staging (ab9e58a2) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: site-ui/build/ui-bundle.zip | Bin 4796900 -> 4796900 bytes 1 file changed, 0 insertions(+), 0 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [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&focusedCommentId=17728889#comment-17728889 ] David Capwell commented on CASSANDRA-18504: --- all types are now generated using the type builder > 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: 7h 40m > 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
[cassandra-website] branch asf-staging updated (04e2d5e4 -> a809e683)
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 04e2d5e4 generate docs for 1b144e50 new a809e683 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 (04e2d5e4) \ N -- N -- N refs/heads/asf-staging (a809e683) 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
[cassandra] branch trunk updated: Ninja fix missing IDEA sun.rmi.transport.tcp compiler export after CASSANDRA-18511
This is an automated email from the ASF dual-hosted git repository. jonmeredith 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 914484dfd8 Ninja fix missing IDEA sun.rmi.transport.tcp compiler export after CASSANDRA-18511 914484dfd8 is described below commit 914484dfd86d5145118032a61c04bc3cdb632fb3 Author: Jon Meredith AuthorDate: Fri Jun 2 13:50:21 2023 -0600 Ninja fix missing IDEA sun.rmi.transport.tcp compiler export after CASSANDRA-18511 --- build.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/build.xml b/build.xml index 3e0a8e981d..3eaf723f69 100644 --- a/build.xml +++ b/build.xml @@ -1811,7 +1811,7 @@ "IDE configuration updated for use with JDK11" - 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 (66ba22e7 -> 04e2d5e4)
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 66ba22e7 generate docs for 1b144e50 new 04e2d5e4 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 (66ba22e7) \ N -- N -- N refs/heads/asf-staging (04e2d5e4) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: site-ui/build/ui-bundle.zip | Bin 4796900 -> 4796900 bytes 1 file changed, 0 insertions(+), 0 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18423) Test failure: org.apache.cassandra.io.sstable.indexsummary.IndexSummaryTest.testLargeIndexSummary
[
https://issues.apache.org/jira/browse/CASSANDRA-18423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17728842#comment-17728842
]
Brandon Williams commented on CASSANDRA-18423:
--
bq. We still need to fix and run checkstyle with 11 to drop 8.
Here it is with only j11:
||Branch||CI||
|[trunk|https://github.com/driftx/cassandra/tree/CASSANDRA-18423-trunk-j11]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/1045/workflows/f9a80079-a191-4307-8398-3939b5b18d19],
[j11|https://app.circleci.com/pipelines/github/driftx/cassandra/1045/workflows/1eae97ea-6dd8-4fa8-875b-062cc992c7c2],
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/2504/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/2504/pipeline]
|
> Test failure:
> org.apache.cassandra.io.sstable.indexsummary.IndexSummaryTest.testLargeIndexSummary
> -
>
> Key: CASSANDRA-18423
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18423
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/2i Index
>Reporter: Brandon Williams
>Assignee: Maxim Muzafarov
>Priority: Normal
> Fix For: 5.x
>
> Attachments: image-1.png, image.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Failed 6 times in the last 6 runs. Flakiness: 0%, Stability: 0%
> {noformat}
> unit.framework.AssertionFailedError: Forked Java VM exited abnormally. Please
> note the time in the report does not reflect the time until the VM exit.
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.util.Vector.forEach(Vector.java:1394)
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.util.Vector.forEach(Vector.java:1394)
> {noformat}
> Note that only the 'default' version of this test is failing:
> https://butler.cassandra.apache.org/#/ci/upstream/workflow/Cassandra-trunk/failure/org.apache.cassandra.io.sstable.indexsummary/IndexSummaryTest/testLargeIndexSummary
--
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-16052) CEP-7 Storage Attached Indexes (Phase 1)
[
https://issues.apache.org/jira/browse/CASSANDRA-16052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17728841#comment-17728841
]
Caleb Rackliffe commented on CASSANDRA-16052:
-
{{cep-7-sai}} is now rebased to trunk as of
https://github.com/apache/cassandra/commit/6cea0cd448d11dc633237ceb1f73f36c2eafb368
> CEP-7 Storage Attached Indexes (Phase 1)
>
>
> Key: CASSANDRA-16052
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16052
> Project: Cassandra
> Issue Type: Epic
> Components: Feature/2i Index, Feature/SAI
>Reporter: Zhao Yang
>Assignee: Caleb Rackliffe
>Priority: Normal
> Labels: SAI
> Fix For: 5.x
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> [CEP|https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-7%3A+Storage+Attached+Index]
> - A new index implementation, called Storage
> Attached Index(SAI), based on the advancement made by SASI.
> * disk usage by sharing of common data between multiple column indexes on
> the same table and better compression of on-disk structures.
> * numeric range query performance with modified KDTree and collection type
> support.
> * compaction performance and stability for larger data set.
--
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] 06/06: post-rebase fixes for the rebase on trunk at fad1f7457032544ab6a7b40c5d38ecb8b25899bb
This is an automated email from the ASF dual-hosted git repository.
maedhroz pushed a commit to branch cep-7-sai
in repository https://gitbox.apache.org/repos/asf/cassandra.git
commit 6ac577308c37ed6b3c8c4400048725223ce1112a
Author: Caleb Rackliffe
AuthorDate: Thu Jun 1 14:43:20 2023 -0500
post-rebase fixes for the rebase on trunk at
fad1f7457032544ab6a7b40c5d38ecb8b25899bb
---
.../config/CassandraRelevantProperties.java| 16 +---
.../cassandra/config/DatabaseDescriptor.java | 1 +
.../apache/cassandra/index/IndexStatusManager.java | 18 -
.../apache/cassandra/index/sai/QueryContext.java | 4 +-
.../index/sai/disk/v1/RowAwarePrimaryKeyMap.java | 6 +--
.../index/sai/disk/v1/SSTableIndexWriter.java | 7 +++-
.../sai/disk/v1/sortedterms/SortedTermsWriter.java | 2 +-
.../index/sai/disk/v1/trie/TriePrefixSearcher.java | 4 +-
.../apache/cassandra/index/sai/utils/TypeUtil.java | 6 +--
.../io/sstable/format/bti/BtiTableWriter.java | 6 ++-
.../org/apache/cassandra/io/tries/TrieNode.java| 2 +-
.../apache/cassandra/io/tries/ValueIterator.java | 8 ++--
.../org/apache/cassandra/index/sai/SAITester.java | 13 --
.../sai/disk/v1/InvertedIndexSearcherTest.java | 2 +-
.../index/sai/disk/v1/SegmentFlushTest.java| 2 +-
.../index/sai/disk/v1/TermsReaderTest.java | 4 +-
.../cassandra/index/sai/disk/v1/TermsScanner.java | 4 +-
.../sai/disk/v1/sortedterms/SortedTermsTest.java | 16
.../sai/disk/v1/trie/TriePrefixSearcherTest.java | 46 +++---
.../sai/disk/v1/trie/TrieTermsDictionaryTest.java | 8 ++--
.../index/sai/memory/RAMStringIndexerTest.java | 2 +-
.../index/sai/memory/TrieMemoryIndexTest.java | 2 +-
.../cassandra/index/sai/plan/OperationTest.java| 3 +-
.../index/sai/utils/AbstractPrimaryKeyTester.java | 2 +-
.../cassandra/index/sai/utils/TypeUtilTest.java| 2 +-
.../index/sai/virtual/SegmentsSystemViewTest.java | 4 +-
.../org/apache/cassandra/io/tries/WalkerTest.java | 1 -
.../apache/cassandra/io/util/SizedIntsTest.java| 1 -
.../io/util/TailOverridingRebuffererTest.java | 4 +-
29 files changed, 105 insertions(+), 91 deletions(-)
diff --git
a/src/java/org/apache/cassandra/config/CassandraRelevantProperties.java
b/src/java/org/apache/cassandra/config/CassandraRelevantProperties.java
index 99dc65cdb6..a81bcd9ed1 100644
--- a/src/java/org/apache/cassandra/config/CassandraRelevantProperties.java
+++ b/src/java/org/apache/cassandra/config/CassandraRelevantProperties.java
@@ -390,16 +390,20 @@ public enum CassandraRelevantProperties
RESET_BOOTSTRAP_PROGRESS("cassandra.reset_bootstrap_progress"),
RING_DELAY("cassandra.ring_delay_ms"),
/** Defines how often schema definitions are pulled from the other nodes */
-SCHEMA_PULL_INTERVAL_MS("cassandra.schema_pull_interval_ms", "6"),
-
SCHEMA_UPDATE_HANDLER_FACTORY_CLASS("cassandra.schema.update_handler_factory.class"),
-SEARCH_CONCURRENCY_FACTOR("cassandra.search_concurrency_factor", "1"),
// SAI specific properties
-/** Latest version to be used for SAI index writing */
-SAI_LATEST_VERSION("cassandra.sai.latest_version", "aa"),
/** Controls the maximum number of index query intersections that will
take part in a query */
SAI_INTERSECTION_CLAUSE_LIMIT("cassandra.sai.intersection.clause.limit",
"2"),
+/** Latest version to be used for SAI index writing */
+SAI_LATEST_VERSION("cassandra.sai.latest_version", "aa"),
+SAI_MAX_FROZEN_TERM_SIZE("cassandra.sai.max_frozen_term_size_kb", "5"),
+SAI_MAX_STRING_TERM_SIZE("cassandra.sai.max_string_term_size_kb", "1"),
+SAI_TEST_DISABLE_TIMEOUT("cassandra.sai.test.disable.timeout", "false"),
+
+SCHEMA_PULL_INTERVAL_MS("cassandra.schema_pull_interval_ms", "6"),
+
SCHEMA_UPDATE_HANDLER_FACTORY_CLASS("cassandra.schema.update_handler_factory.class"),
+SEARCH_CONCURRENCY_FACTOR("cassandra.search_concurrency_factor", "1"),
/**
* The maximum number of seeds returned by a seed provider before
emmitting a warning.
@@ -461,6 +465,7 @@ public enum CassandraRelevantProperties
TEST_DEBUG_REF_COUNT("cassandra.debugrefcount"),
TEST_DRIVER_CONNECTION_TIMEOUT_MS("cassandra.test.driver.connection_timeout_ms",
"5000"),
TEST_DRIVER_READ_TIMEOUT_MS("cassandra.test.driver.read_timeout_ms",
"12000"),
+TEST_ENCRYPTION("cassandra.test.encryption", "false"),
TEST_FAIL_MV_LOCKS_COUNT("cassandra.test.fail_mv_locks_count", "0"),
TEST_FAIL_WRITES_KS("cassandra.test.fail_writes_ks", ""),
/** Flush changes of {@link org.apache.cassandra.schema.SchemaKeyspace}
after each schema modification. In production,
@@ -473,6 +478,7 @@ public enum CassandraRelevantProperties
TEST_JVM_DTEST_DISABLE_SSL("cassandra.test.disable_ssl"),
TEST_LEGACY_SSTABLE_ROOT("legacy-sstable-root"),
TEST_ORG_CAFFINITAS_OHC_SEGMENTCOUNT("org.caffinitas.ohc.segmentCount"
[cassandra] 05/06: Unify CQLTester#waitForIndex and SAITester#waitForIndexQueryable
This is an automated email from the ASF dual-hosted git repository.
maedhroz pushed a commit to branch cep-7-sai
in repository https://gitbox.apache.org/repos/asf/cassandra.git
commit 26f2c942ab475ff80ac9506cfd1408909eb6d8f4
Author: Andrés de la Peña
AuthorDate: Thu May 11 15:01:00 2023 +0100
Unify CQLTester#waitForIndex and SAITester#waitForIndexQueryable
patch by Andrés de la Peña; reviewed by Caleb Rackliffe for CASSANDRA-18521
---
.../cassandra/cql3/functions/types/ParseUtils.java | 4 +-
test/unit/org/apache/cassandra/cql3/CQLTester.java | 253 +++--
.../org/apache/cassandra/cql3/CQLTesterTest.java | 82 +++
.../org/apache/cassandra/cql3/KeyCacheCqlTest.java | 4 +-
.../entities/SecondaryIndexOnMapEntriesTest.java | 2 +-
.../validation/entities/SecondaryIndexTest.java| 38 ++--
.../operations/InsertUpdateIfConditionTest.java| 2 -
.../db/guardrails/GuardrailTablesTest.java | 2 +-
.../cassandra/index/SecondaryIndexManagerTest.java | 127 +--
.../index/internal/CassandraIndexTest.java | 9 +-
.../org/apache/cassandra/index/sai/SAITester.java | 41 +---
.../index/sai/cql/AllowFilteringTest.java | 6 -
.../cassandra/index/sai/cql/BaseDataModel.java | 29 ++-
.../cassandra/index/sai/cql/BooleanTypeTest.java | 1 -
.../index/sai/cql/CollectionIndexingTest.java | 3 -
.../index/sai/cql/DecimalLargeValueTest.java | 2 -
.../index/sai/cql/DuplicateRowIDTest.java | 1 -
.../sai/cql/MixedIndexImplementationsTest.java | 4 -
.../index/sai/cql/MultipleColumnIndexTest.java | 2 -
.../index/sai/cql/SingleNodeExecutor.java | 4 +-
.../index/sai/cql/StorageAttachedIndexDDLTest.java | 36 ++-
.../index/sai/cql/types/IndexingTypeSupport.java | 2 -
.../cassandra/index/sai/disk/NodeStartupTest.java | 5 +-
.../index/sai/disk/SelectiveIntersectionTest.java | 2 -
.../index/sai/disk/SingleNodeQueryFailureTest.java | 1 -
.../index/sai/functional/CompactionTest.java | 2 -
.../index/sai/functional/DiskSpaceTest.java| 1 -
.../index/sai/functional/DropTableTest.java| 1 -
.../index/sai/functional/FailureTest.java | 2 +-
.../index/sai/functional/GroupComponentsTest.java | 3 -
.../index/sai/functional/NodeRestartTest.java | 9 +-
.../index/sai/functional/SnapshotTest.java | 2 -
.../index/sai/metrics/QueryMetricsTest.java| 1 -
.../sai/metrics/SegmentFlushingFailureTester.java | 1 -
.../index/sai/metrics/StateMetricsTest.java| 6 +-
.../cassandra/index/sai/plan/OperationTest.java| 2 +-
.../index/sai/virtual/IndexesSystemViewTest.java | 4 +-
.../index/sai/virtual/SSTablesSystemViewTest.java | 2 -
.../index/sai/virtual/SegmentsSystemViewTest.java | 1 -
39 files changed, 390 insertions(+), 309 deletions(-)
diff --git a/src/java/org/apache/cassandra/cql3/functions/types/ParseUtils.java
b/src/java/org/apache/cassandra/cql3/functions/types/ParseUtils.java
index 8972beed15..8d0f29b45b 100644
--- a/src/java/org/apache/cassandra/cql3/functions/types/ParseUtils.java
+++ b/src/java/org/apache/cassandra/cql3/functions/types/ParseUtils.java
@@ -292,7 +292,7 @@ public abstract class ParseUtils
* @param value The string to un-double quote.
* @return The un-double quoted string.
*/
-static String unDoubleQuote(String value)
+public static String unDoubleQuote(String value)
{
return unquote(value, '"');
}
@@ -482,7 +482,7 @@ public abstract class ParseUtils
* @return {@code true} if the given string is surrounded by the quote
character, and {@code
* false} otherwise.
*/
-private static boolean isQuoted(String value, char quoteChar)
+public static boolean isQuoted(String value, char quoteChar)
{
return value != null
&& value.length() > 1
diff --git a/test/unit/org/apache/cassandra/cql3/CQLTester.java
b/test/unit/org/apache/cassandra/cql3/CQLTester.java
index a898faeb36..dc4a0e413e 100644
--- a/test/unit/org/apache/cassandra/cql3/CQLTester.java
+++ b/test/unit/org/apache/cassandra/cql3/CQLTester.java
@@ -48,6 +48,8 @@ import java.util.function.Consumer;
import java.util.regex.Matcher;
import java.util.regex.Pattern;
import java.util.stream.Collectors;
+
+import javax.annotation.Nullable;
import javax.management.MBeanServerConnection;
import javax.management.remote.JMXConnector;
import javax.management.remote.JMXConnectorFactory;
@@ -59,6 +61,8 @@ import com.google.common.base.Objects;
import com.google.common.base.Strings;
import com.google.common.collect.ImmutableSet;
import com.google.common.collect.Iterables;
+import org.assertj.core.api.Assertions;
+import org.awaitility.Awaitility;
import org.junit.After;
import org.junit.AfterClass;
import org.junit.Assert;
@@ -96,6 +100,7 @@ import org.apache.cassandra.config.DataStorageSpec;
import org.apache.cassa
[cassandra] branch cep-7-sai updated (9970cf5684 -> 6ac577308c)
This is an automated email from the ASF dual-hosted git repository. maedhroz pushed a change to branch cep-7-sai in repository https://gitbox.apache.org/repos/asf/cassandra.git omit 9970cf5684 Unify CQLTester#waitForIndex and SAITester#waitForIndexQueryable omit fa85a191c5 Allow CQL queries on multiple indexes without ALLOW FILTERING omit b45f47d709 Literal on-disk index and index write path (#9) omit 7937878b36 In-memory index implementation with query path omit 758b4dc923 Add Index Group Interface for Storage Attached Index add f2427a0c86 Increment version to 4.0.10 add ccaedfa8e7 Merge branch 'cassandra-4.0' into cassandra-4.1 add 8f7e90dcf3 Merge branch 'cassandra-4.1' into trunk add 2fce3025c4 Fix nested selection of reversed collections add 5869dc0dac Merge branch 'cassandra-4.0' into cassandra-4.1 add b7ec523aa9 Merge branch 'cassandra-4.1' into trunk add bd49f6ff26 Allow keystore and truststore passwords to be nullable add 531b4cde43 Merge branch 'cassandra-4.1' into trunk add 08b9471a1e Fix sstable_count metric missing from tablestats json/yaml output add 3f67827387 Merge branch 'cassandra-3.11' into cassandra-4.0 add 2208235ce9 Merge branch 'cassandra-4.0' into cassandra-4.1 add 976b8395f9 Merge branch 'cassandra-4.1' into trunk add cd9bed0aea Deadlock updating sstable metadata if disk boundaries need reloading add 4c13df58cb Merge branch 'cassandra-4.0' into cassandra-4.1 add 8df072e104 Merge branch 'cassandra-4.1' into trunk add 33d1c4315c Remove the explicit disabling of UseBiasedLocking as it is the default since jdk15 add 29ed31542b Improve apidocs and pre-conditions to how upgrade paths are included in jvm-dtest-upgrade (UpgradeTestBase) add 8b0dc8ad6b When decommissioning should set Severity to limit traffic add 09c1e67598 Incremental repairs fail on mixed IPv4/v6 addresses serializing SyncRequest add 1d926e8c6f Merge branch 'cassandra-4.0' into cassandra-4.1 add b028ac9e87 Merge branch 'cassandra-4.1' into trunk add 4f348786bd Do not remove truncated_at entry in system.local while dropping an index add 81e78192cb Merge branch 'cassandra-3.0' into cassandra-3.11 add 5bcee5c06a Merge branch 'cassandra-3.11' into cassandra-4.0 add e733edb6cc Merge branch 'cassandra-4.0' into cassandra-4.1 add 28b7fdafa2 Merge branch 'cassandra-4.1' into trunk add 1a5302608f Test Failure: HintsDisabledTest.testHintedHandoffDisabled add 2e5fb2ea1d Merge branch 'cassandra-4.1' into trunk add 0f3a990dd2 Fix the capital P usage in the CQL parser add 45938e296e Merge branch 'cassandra-3.11' into cassandra-4.0 add 30220bc723 Merge branch 'cassandra-4.0' into cassandra-4.1 add 16643c0078 Merge branch 'cassandra-4.1' into trunk add db78e746d7 Do not remove SSTables when cause of FSReadError is OutOfMemoryError while using best_effort disk failure policy add c74c9bb037 Merge branch 'cassandra-3.0' into cassandra-3.11 add c4a305d17a Merge branch 'cassandra-3.11' into cassandra-4.0 add ba72d90141 Merge branch 'cassandra-4.0' into cassandra-4.1 add cf48c04c00 Merge branch 'cassandra-4.1' into trunk add 6cdcf5e56a Prepare debian changelog for 3.11.15 add b183e1f0de Merge branch 'cassandra-3.11' into cassandra-4.0 add 1a72fbd9c6 Merge branch 'cassandra-4.0' into cassandra-4.1 add 63ab8e0928 Merge branch 'cassandra-4.1' into trunk add 998a98eae8 Reorganizing doc directories using new info arch add 90d0857d34 fix typos in data modeling and getting started docs add 1929550fc0 Merge branch 'cassandra-3.11' into cassandra-4.0 add cfabddcfb0 Merge branch 'cassandra-4.0' into cassandra-4.1 add d7314a5988 Merge branch 'cassandra-4.1' into trunk add 22329ee0be Deprecate/forbid constructors for Integer, Long, Float, Byte, Double, and Short add 73da05f83b Replace usages of json-simple dependency by Jackson add 602ffcbf3e fix flaky o.a.c.distributed.test.PaxosRepair2Test.paxosRepairHistoryIsntUpdatedInForcedRepair add ccf3789219 Merge branch 'cassandra-4.1' into trunk add 65c99bfc42 Improve 'Not enough space for compaction' logging messages add 82dc54c3a8 Merge branch 'cassandra-4.0' into cassandra-4.1 add 5acfde21fe Merge branch 'cassandra-4.1' into trunk add e72ec4e828 Add sstablepartitions offline tool to find large partitions in sstables add 4a62757624 Suppress CVE-2023-2251 add aa73bc468a Merge branch 'cassandra-3.0' into cassandra-3.11 add dba4162666 Merge branch 'cassandra-3.11' into cassandra-4.0 add b6b71c598e Merge branch 'cassandra-3.0' into cassandra-3.11 add 682ae0c64c Merge branch 'cassandra-3.11' into cassandra-4.0 add 462934a84b Merge branch 'cassandra-4.0' into cassandra-4.1 add 42dac9b950 Merge branch 'cassandra-4.1' into trunk add ee5b601ce7 Increment version to 3.11.16 a
[jira] [Commented] (CASSANDRA-18423) Test failure: org.apache.cassandra.io.sstable.indexsummary.IndexSummaryTest.testLargeIndexSummary
[
https://issues.apache.org/jira/browse/CASSANDRA-18423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17728834#comment-17728834
]
Ekaterina Dimitrova commented on CASSANDRA-18423:
-
{quote}As far as this ticket goes, since we know that CASSANDRA-18435 wants to
run check style on only the lowest supported JDK, which also solves the problem
here, let's commit
[this|https://github.com/driftx/cassandra/commit/8479d4a15df618fbae96421b650eb798a429e0cf]
earlier patch I tested.
{quote}
I am all in to commit it, thanks. We still need to fix and run checkstyle with
11 to drop 8.
Thank you both for looking into this!
{quote} - the check style is skipped for the CircleCI before building and
running tests: https://issues.apache.org/jira/browse/CASSANDRA-18000{quote}
That is a good point, we do the check style in the build step, so there is no
need to repeat it, but unfortunately, that doesn't explain why the test is not
run in CircleCI. :(
> Test failure:
> org.apache.cassandra.io.sstable.indexsummary.IndexSummaryTest.testLargeIndexSummary
> -
>
> Key: CASSANDRA-18423
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18423
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/2i Index
>Reporter: Brandon Williams
>Assignee: Maxim Muzafarov
>Priority: Normal
> Fix For: 5.x
>
> Attachments: image-1.png, image.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Failed 6 times in the last 6 runs. Flakiness: 0%, Stability: 0%
> {noformat}
> unit.framework.AssertionFailedError: Forked Java VM exited abnormally. Please
> note the time in the report does not reflect the time until the VM exit.
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.util.Vector.forEach(Vector.java:1394)
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.util.Vector.forEach(Vector.java:1394)
> {noformat}
> Note that only the 'default' version of this test is failing:
> https://butler.cassandra.apache.org/#/ci/upstream/workflow/Cassandra-trunk/failure/org.apache.cassandra.io.sstable.indexsummary/IndexSummaryTest/testLargeIndexSummary
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18423) Test failure: org.apache.cassandra.io.sstable.indexsummary.IndexSummaryTest.testLargeIndexSummary
[
https://issues.apache.org/jira/browse/CASSANDRA-18423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17728832#comment-17728832
]
Maxim Muzafarov edited comment on CASSANDRA-18423 at 6/2/23 5:13 PM:
-
[~e.dimitrova],
I guess the reason that the CircleCI tests are green is that in fact Jenkins
and the CircleCI tests configuration differ a bit:
- the checkstyle is skipped for the CircleCI before building and running
tests: https://issues.apache.org/jira/browse/CASSANDRA-18000
- the same for the checkstyle on Jenkins is not true:
https://issues.apache.org/jira/browse/CASSANDRA-18017
I think CASSANDRA-18017 might help in this case to solve the issue (I'm also
not able to test that patch), but Michael said he had another solution for
that. My theory is that because the new version of checkstyle needs more heap
to do all the checks, the JVM is unable to allocate enough memory and that's
why it fails, but I'll have to check this to be sure.
was (Author: mmuzaf):
[~e.dimitrova],
I guess the reason that the CircleCI tests are green is that in fact Jenkins
and the CircleCI tests configuration differ a bit:
- the checkstyle is skipped for the CircleCI before building and running tests:
https://issues.apache.org/jira/browse/CASSANDRA-18000
- the same for the checkstyle on Jenkins is not true:
https://issues.apache.org/jira/browse/CASSANDRA-18017
I think CASSANDRA-18017 might help in this case to solve the issue (I'm also
not able to test that patch), but Michael said he had another solution for
that.
> Test failure:
> org.apache.cassandra.io.sstable.indexsummary.IndexSummaryTest.testLargeIndexSummary
> -
>
> Key: CASSANDRA-18423
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18423
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/2i Index
>Reporter: Brandon Williams
>Assignee: Maxim Muzafarov
>Priority: Normal
> Fix For: 5.x
>
> Attachments: image-1.png, image.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Failed 6 times in the last 6 runs. Flakiness: 0%, Stability: 0%
> {noformat}
> unit.framework.AssertionFailedError: Forked Java VM exited abnormally. Please
> note the time in the report does not reflect the time until the VM exit.
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.util.Vector.forEach(Vector.java:1394)
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.util.Vector.forEach(Vector.java:1394)
> {noformat}
> Note that only the 'default' version of this test is failing:
> https://butler.cassandra.apache.org/#/ci/upstream/workflow/Cassandra-trunk/failure/org.apache.cassandra.io.sstable.indexsummary/IndexSummaryTest/testLargeIndexSummary
--
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-18423) Test failure: org.apache.cassandra.io.sstable.indexsummary.IndexSummaryTest.testLargeIndexSummary
[
https://issues.apache.org/jira/browse/CASSANDRA-18423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17728832#comment-17728832
]
Maxim Muzafarov commented on CASSANDRA-18423:
-
[~e.dimitrova],
I guess the reason that the CircleCI tests are green is that in fact Jenkins
and the CircleCI tests configuration differ a bit:
- the checkstyle is skipped for the CircleCI before building and running tests:
https://issues.apache.org/jira/browse/CASSANDRA-18000
- the same for the checkstyle on Jenkins is not true:
https://issues.apache.org/jira/browse/CASSANDRA-18017
I think CASSANDRA-18017 might help in this case to solve the issue (I'm also
not able to test that patch), but Michael said he had another solution for
that.
> Test failure:
> org.apache.cassandra.io.sstable.indexsummary.IndexSummaryTest.testLargeIndexSummary
> -
>
> Key: CASSANDRA-18423
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18423
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/2i Index
>Reporter: Brandon Williams
>Assignee: Maxim Muzafarov
>Priority: Normal
> Fix For: 5.x
>
> Attachments: image-1.png, image.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Failed 6 times in the last 6 runs. Flakiness: 0%, Stability: 0%
> {noformat}
> unit.framework.AssertionFailedError: Forked Java VM exited abnormally. Please
> note the time in the report does not reflect the time until the VM exit.
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.util.Vector.forEach(Vector.java:1394)
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.util.Vector.forEach(Vector.java:1394)
> {noformat}
> Note that only the 'default' version of this test is failing:
> https://butler.cassandra.apache.org/#/ci/upstream/workflow/Cassandra-trunk/failure/org.apache.cassandra.io.sstable.indexsummary/IndexSummaryTest/testLargeIndexSummary
--
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-18423) Test failure: org.apache.cassandra.io.sstable.indexsummary.IndexSummaryTest.testLargeIndexSummary
[
https://issues.apache.org/jira/browse/CASSANDRA-18423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17728831#comment-17728831
]
Brandon Williams commented on CASSANDRA-18423:
--
Regarding the logs, I created CASSANDRA-18565 because it seems like something
is wrong there.
As far as this ticket goes, since we know that CASSANDRA-18435 wants to run
checkstyle on only the lowest supported JDK and that also solves the problem
here, let's just commit
[this|https://github.com/driftx/cassandra/commit/8479d4a15df618fbae96421b650eb798a429e0cf]
earlier patch I tested?
> Test failure:
> org.apache.cassandra.io.sstable.indexsummary.IndexSummaryTest.testLargeIndexSummary
> -
>
> Key: CASSANDRA-18423
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18423
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/2i Index
>Reporter: Brandon Williams
>Assignee: Maxim Muzafarov
>Priority: Normal
> Fix For: 5.x
>
> Attachments: image-1.png, image.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Failed 6 times in the last 6 runs. Flakiness: 0%, Stability: 0%
> {noformat}
> unit.framework.AssertionFailedError: Forked Java VM exited abnormally. Please
> note the time in the report does not reflect the time until the VM exit.
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.util.Vector.forEach(Vector.java:1394)
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.util.Vector.forEach(Vector.java:1394)
> {noformat}
> Note that only the 'default' version of this test is failing:
> https://butler.cassandra.apache.org/#/ci/upstream/workflow/Cassandra-trunk/failure/org.apache.cassandra.io.sstable.indexsummary/IndexSummaryTest/testLargeIndexSummary
--
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-18423) Test failure: org.apache.cassandra.io.sstable.indexsummary.IndexSummaryTest.testLargeIndexSummary
[
https://issues.apache.org/jira/browse/CASSANDRA-18423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17728818#comment-17728818
]
Ekaterina Dimitrova commented on CASSANDRA-18423:
-
Something else I noticed... I found a run from today - jdk 11 on trunk with
another patch -
[https://app.circleci.com/pipelines/github/driftx/cassandra/1040/workflows/37004408-718c-4833-8cc3-9227b6cd7648/jobs/27957/parallel-runs/24?filterBy=ALL]
All tests are green; the IndexSummaryTest artifact does not exist. Looking into
the CircleCI steps - we can find the test under Determine Unit Tests to Run.
I do not see any test run failing in any of the containers. I haven't seen this
behavior before, and logs do not point me in any direction in CircleCI.
> Test failure:
> org.apache.cassandra.io.sstable.indexsummary.IndexSummaryTest.testLargeIndexSummary
> -
>
> Key: CASSANDRA-18423
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18423
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/2i Index
>Reporter: Brandon Williams
>Assignee: Maxim Muzafarov
>Priority: Normal
> Fix For: 5.x
>
> Attachments: image-1.png, image.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Failed 6 times in the last 6 runs. Flakiness: 0%, Stability: 0%
> {noformat}
> unit.framework.AssertionFailedError: Forked Java VM exited abnormally. Please
> note the time in the report does not reflect the time until the VM exit.
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.util.Vector.forEach(Vector.java:1394)
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.util.Vector.forEach(Vector.java:1394)
> {noformat}
> Note that only the 'default' version of this test is failing:
> https://butler.cassandra.apache.org/#/ci/upstream/workflow/Cassandra-trunk/failure/org.apache.cassandra.io.sstable.indexsummary/IndexSummaryTest/testLargeIndexSummary
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18564) Test Failure: MixedModeAvailabilityV3XAllOneTest.testAvailabilityCoordinatorUpgraded
[
https://issues.apache.org/jira/browse/CASSANDRA-18564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17728813#comment-17728813
]
Andres de la Peña edited comment on CASSANDRA-18564 at 6/2/23 4:15 PM:
---
The very similar dtest
{{MixedModeAvailabilityV30AllOneTest.testAvailabilityCoordinatorUpgraded}} has
failed in the same Jenkins run with a mostly identical message, so I guess both
failures have the same cause.
This is the Jenkins run:
[https://ci-cassandra.apache.org/job/Cassandra-trunk/1585/testReport/org.apache.cassandra.distributed.upgrade/MixedModeAvailabilityV30AllOneTest/testAvailabilityCoordinatorUpgraded__jdk11/]
was (Author: adelapena):
The very similar dtest
{{MixedModeAvailabilityV30AllOneTest.testAvailabilityCoordinatorUpgraded}} has
failed in the same Jenkins run with a mostly identical message, so I guess both
failures have the same cause. This the Jenkins run:
[https://ci-cassandra.apache.org/job/Cassandra-trunk/1585/testReport/org.apache.cassandra.distributed.upgrade/MixedModeAvailabilityV30AllOneTest/testAvailabilityCoordinatorUpgraded__jdk11/]
> Test Failure:
> MixedModeAvailabilityV3XAllOneTest.testAvailabilityCoordinatorUpgraded
>
>
> Key: CASSANDRA-18564
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18564
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: Andres de la Peña
>Priority: Normal
>
> The JVM upgrade dtest
> {{MixedModeAvailabilityV3XAllOneTest.testAvailabilityCoordinatorUpgraded}}
> seems to be flaky at least in {{trunk}}:
> {code}
> junit.framework.AssertionFailedError: Error in test '4.0.11 -> [5.0]' while
> upgrading to '5.0'; successful upgrades []
> at
> org.apache.cassandra.distributed.upgrade.UpgradeTestBase$TestCase.run(UpgradeTestBase.java:348)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase.testAvailability(MixedModeAvailabilityTestBase.java:154)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase.testAvailabilityCoordinatorUpgraded(MixedModeAvailabilityTestBase.java:74)
> Caused by: java.lang.AssertionError: Unexpected error while reading in case
> write-read consistency ALL-ONE with upgraded coordinator and 2 nodes down:
> org.apache.cassandra.exceptions.ReadTimeoutException: Operation timed out -
> received only 0 responses.
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase.lambda$testAvailability$6(MixedModeAvailabilityTestBase.java:145)
> at
> org.apache.cassandra.distributed.upgrade.UpgradeTestBase$TestCase.run(UpgradeTestBase.java:339)
> Caused by: org.apache.cassandra.exceptions.ReadTimeoutException: Operation
> timed out - received only 0 responses.
> at
> org.apache.cassandra.service.reads.ReadCallback.awaitResults(ReadCallback.java:162)
> at
> org.apache.cassandra.service.reads.AbstractReadExecutor.awaitResponses(AbstractReadExecutor.java:387)
> at
> org.apache.cassandra.service.StorageProxy.fetchRows(StorageProxy.java:2124)
> at
> org.apache.cassandra.service.StorageProxy.readRegular(StorageProxy.java:1995)
> at
> org.apache.cassandra.service.StorageProxy.read(StorageProxy.java:1873)
> at
> org.apache.cassandra.db.SinglePartitionReadCommand$Group.execute(SinglePartitionReadCommand.java:1286)
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:364)
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:293)
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:105)
> at
> org.apache.cassandra.distributed.impl.Coordinator.unsafeExecuteInternal(Coordinator.java:122)
> at
> org.apache.cassandra.distributed.impl.Coordinator.unsafeExecuteInternal(Coordinator.java:103)
> at
> org.apache.cassandra.distributed.impl.Coordinator.lambda$executeWithResult$0(Coordinator.java:66)
> at org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:61)
> at org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:71)
> 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:750)
> {code}
> This has failed 143 times in 500 iterations of this CircleCI run:
> *
> https://app.circleci.com/pipelines/github/adelapena/cassandra/2927/workflows/fcd1cd60-826b-484a-8e81-d3ba640f7de9/jobs/47659/tests
> The failure has also recently appeared on J
[jira] [Comment Edited] (CASSANDRA-18564) Test Failure: MixedModeAvailabilityV3XAllOneTest.testAvailabilityCoordinatorUpgraded
[
https://issues.apache.org/jira/browse/CASSANDRA-18564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17728813#comment-17728813
]
Andres de la Peña edited comment on CASSANDRA-18564 at 6/2/23 4:14 PM:
---
The very similar dtest
{{MixedModeAvailabilityV30AllOneTest.testAvailabilityCoordinatorUpgraded}} has
failed in the same Jenkins run with a mostly identical message, so I guess both
failures have the same cause. This the Jenkins run:
[https://ci-cassandra.apache.org/job/Cassandra-trunk/1585/testReport/org.apache.cassandra.distributed.upgrade/MixedModeAvailabilityV30AllOneTest/testAvailabilityCoordinatorUpgraded__jdk11/]
was (Author: adelapena):
The very similar dtest
{{MixedModeAvailabilityV30AllOneTest.testAvailabilityCoordinatorUpgraded}} has
failed in the same Jenkins run with a mostly identical message, so I guess both
failures have the cause:
https://ci-cassandra.apache.org/job/Cassandra-trunk/1585/testReport/org.apache.cassandra.distributed.upgrade/MixedModeAvailabilityV30AllOneTest/testAvailabilityCoordinatorUpgraded__jdk11/
> Test Failure:
> MixedModeAvailabilityV3XAllOneTest.testAvailabilityCoordinatorUpgraded
>
>
> Key: CASSANDRA-18564
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18564
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: Andres de la Peña
>Priority: Normal
>
> The JVM upgrade dtest
> {{MixedModeAvailabilityV3XAllOneTest.testAvailabilityCoordinatorUpgraded}}
> seems to be flaky at least in {{trunk}}:
> {code}
> junit.framework.AssertionFailedError: Error in test '4.0.11 -> [5.0]' while
> upgrading to '5.0'; successful upgrades []
> at
> org.apache.cassandra.distributed.upgrade.UpgradeTestBase$TestCase.run(UpgradeTestBase.java:348)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase.testAvailability(MixedModeAvailabilityTestBase.java:154)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase.testAvailabilityCoordinatorUpgraded(MixedModeAvailabilityTestBase.java:74)
> Caused by: java.lang.AssertionError: Unexpected error while reading in case
> write-read consistency ALL-ONE with upgraded coordinator and 2 nodes down:
> org.apache.cassandra.exceptions.ReadTimeoutException: Operation timed out -
> received only 0 responses.
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase.lambda$testAvailability$6(MixedModeAvailabilityTestBase.java:145)
> at
> org.apache.cassandra.distributed.upgrade.UpgradeTestBase$TestCase.run(UpgradeTestBase.java:339)
> Caused by: org.apache.cassandra.exceptions.ReadTimeoutException: Operation
> timed out - received only 0 responses.
> at
> org.apache.cassandra.service.reads.ReadCallback.awaitResults(ReadCallback.java:162)
> at
> org.apache.cassandra.service.reads.AbstractReadExecutor.awaitResponses(AbstractReadExecutor.java:387)
> at
> org.apache.cassandra.service.StorageProxy.fetchRows(StorageProxy.java:2124)
> at
> org.apache.cassandra.service.StorageProxy.readRegular(StorageProxy.java:1995)
> at
> org.apache.cassandra.service.StorageProxy.read(StorageProxy.java:1873)
> at
> org.apache.cassandra.db.SinglePartitionReadCommand$Group.execute(SinglePartitionReadCommand.java:1286)
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:364)
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:293)
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:105)
> at
> org.apache.cassandra.distributed.impl.Coordinator.unsafeExecuteInternal(Coordinator.java:122)
> at
> org.apache.cassandra.distributed.impl.Coordinator.unsafeExecuteInternal(Coordinator.java:103)
> at
> org.apache.cassandra.distributed.impl.Coordinator.lambda$executeWithResult$0(Coordinator.java:66)
> at org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:61)
> at org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:71)
> 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:750)
> {code}
> This has failed 143 times in 500 iterations of this CircleCI run:
> *
> https://app.circleci.com/pipelines/github/adelapena/cassandra/2927/workflows/fcd1cd60-826b-484a-8e81-d3ba640f7de9/jobs/47659/tests
> The failure has also recently appeared on Jenkins too:
> *
> https://ci-cas
[jira] [Commented] (CASSANDRA-18564) Test Failure: MixedModeAvailabilityV3XAllOneTest.testAvailabilityCoordinatorUpgraded
[
https://issues.apache.org/jira/browse/CASSANDRA-18564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17728813#comment-17728813
]
Andres de la Peña commented on CASSANDRA-18564:
---
The very similar dtest
{{MixedModeAvailabilityV30AllOneTest.testAvailabilityCoordinatorUpgraded}} has
failed in the same Jenkins run with a mostly identical message, so I guess both
failures have the cause:
https://ci-cassandra.apache.org/job/Cassandra-trunk/1585/testReport/org.apache.cassandra.distributed.upgrade/MixedModeAvailabilityV30AllOneTest/testAvailabilityCoordinatorUpgraded__jdk11/
> Test Failure:
> MixedModeAvailabilityV3XAllOneTest.testAvailabilityCoordinatorUpgraded
>
>
> Key: CASSANDRA-18564
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18564
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: Andres de la Peña
>Priority: Normal
>
> The JVM upgrade dtest
> {{MixedModeAvailabilityV3XAllOneTest.testAvailabilityCoordinatorUpgraded}}
> seems to be flaky at least in {{trunk}}:
> {code}
> junit.framework.AssertionFailedError: Error in test '4.0.11 -> [5.0]' while
> upgrading to '5.0'; successful upgrades []
> at
> org.apache.cassandra.distributed.upgrade.UpgradeTestBase$TestCase.run(UpgradeTestBase.java:348)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase.testAvailability(MixedModeAvailabilityTestBase.java:154)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase.testAvailabilityCoordinatorUpgraded(MixedModeAvailabilityTestBase.java:74)
> Caused by: java.lang.AssertionError: Unexpected error while reading in case
> write-read consistency ALL-ONE with upgraded coordinator and 2 nodes down:
> org.apache.cassandra.exceptions.ReadTimeoutException: Operation timed out -
> received only 0 responses.
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase.lambda$testAvailability$6(MixedModeAvailabilityTestBase.java:145)
> at
> org.apache.cassandra.distributed.upgrade.UpgradeTestBase$TestCase.run(UpgradeTestBase.java:339)
> Caused by: org.apache.cassandra.exceptions.ReadTimeoutException: Operation
> timed out - received only 0 responses.
> at
> org.apache.cassandra.service.reads.ReadCallback.awaitResults(ReadCallback.java:162)
> at
> org.apache.cassandra.service.reads.AbstractReadExecutor.awaitResponses(AbstractReadExecutor.java:387)
> at
> org.apache.cassandra.service.StorageProxy.fetchRows(StorageProxy.java:2124)
> at
> org.apache.cassandra.service.StorageProxy.readRegular(StorageProxy.java:1995)
> at
> org.apache.cassandra.service.StorageProxy.read(StorageProxy.java:1873)
> at
> org.apache.cassandra.db.SinglePartitionReadCommand$Group.execute(SinglePartitionReadCommand.java:1286)
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:364)
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:293)
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:105)
> at
> org.apache.cassandra.distributed.impl.Coordinator.unsafeExecuteInternal(Coordinator.java:122)
> at
> org.apache.cassandra.distributed.impl.Coordinator.unsafeExecuteInternal(Coordinator.java:103)
> at
> org.apache.cassandra.distributed.impl.Coordinator.lambda$executeWithResult$0(Coordinator.java:66)
> at org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:61)
> at org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:71)
> 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:750)
> {code}
> This has failed 143 times in 500 iterations of this CircleCI run:
> *
> https://app.circleci.com/pipelines/github/adelapena/cassandra/2927/workflows/fcd1cd60-826b-484a-8e81-d3ba640f7de9/jobs/47659/tests
> The failure has also recently appeared on Jenkins too:
> *
> https://ci-cassandra.apache.org/job/Cassandra-trunk/1585/testReport/org.apache.cassandra.distributed.upgrade/MixedModeAvailabilityV3XAllOneTest/testAvailabilityCoordinatorUpgraded__jdk11/
> Given that the failure has just appeared on Jenkins and it fails relatively
> easily on CircleCI, it's likely that it has been broken by a very recent
> change.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: comm
[jira] [Created] (CASSANDRA-18564) Test Failure: MixedModeAvailabilityV3XAllOneTest.testAvailabilityCoordinatorUpgraded
Andres de la Peña created CASSANDRA-18564:
-
Summary: Test Failure:
MixedModeAvailabilityV3XAllOneTest.testAvailabilityCoordinatorUpgraded
Key: CASSANDRA-18564
URL: https://issues.apache.org/jira/browse/CASSANDRA-18564
Project: Cassandra
Issue Type: Bug
Components: Test/dtest/java
Reporter: Andres de la Peña
The JVM upgrade dtest
{{MixedModeAvailabilityV3XAllOneTest.testAvailabilityCoordinatorUpgraded}}
seems to be flaky at least in {{trunk}}:
{code}
junit.framework.AssertionFailedError: Error in test '4.0.11 -> [5.0]' while
upgrading to '5.0'; successful upgrades []
at
org.apache.cassandra.distributed.upgrade.UpgradeTestBase$TestCase.run(UpgradeTestBase.java:348)
at
org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase.testAvailability(MixedModeAvailabilityTestBase.java:154)
at
org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase.testAvailabilityCoordinatorUpgraded(MixedModeAvailabilityTestBase.java:74)
Caused by: java.lang.AssertionError: Unexpected error while reading in case
write-read consistency ALL-ONE with upgraded coordinator and 2 nodes down:
org.apache.cassandra.exceptions.ReadTimeoutException: Operation timed out -
received only 0 responses.
at
org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase.lambda$testAvailability$6(MixedModeAvailabilityTestBase.java:145)
at
org.apache.cassandra.distributed.upgrade.UpgradeTestBase$TestCase.run(UpgradeTestBase.java:339)
Caused by: org.apache.cassandra.exceptions.ReadTimeoutException: Operation
timed out - received only 0 responses.
at
org.apache.cassandra.service.reads.ReadCallback.awaitResults(ReadCallback.java:162)
at
org.apache.cassandra.service.reads.AbstractReadExecutor.awaitResponses(AbstractReadExecutor.java:387)
at
org.apache.cassandra.service.StorageProxy.fetchRows(StorageProxy.java:2124)
at
org.apache.cassandra.service.StorageProxy.readRegular(StorageProxy.java:1995)
at
org.apache.cassandra.service.StorageProxy.read(StorageProxy.java:1873)
at
org.apache.cassandra.db.SinglePartitionReadCommand$Group.execute(SinglePartitionReadCommand.java:1286)
at
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:364)
at
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:293)
at
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:105)
at
org.apache.cassandra.distributed.impl.Coordinator.unsafeExecuteInternal(Coordinator.java:122)
at
org.apache.cassandra.distributed.impl.Coordinator.unsafeExecuteInternal(Coordinator.java:103)
at
org.apache.cassandra.distributed.impl.Coordinator.lambda$executeWithResult$0(Coordinator.java:66)
at org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:61)
at org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:71)
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:750)
{code}
This has failed 143 times in 500 iterations of this CircleCI run:
*
https://app.circleci.com/pipelines/github/adelapena/cassandra/2927/workflows/fcd1cd60-826b-484a-8e81-d3ba640f7de9/jobs/47659/tests
The failure has also recently appeared on Jenkins too:
*
https://ci-cassandra.apache.org/job/Cassandra-trunk/1585/testReport/org.apache.cassandra.distributed.upgrade/MixedModeAvailabilityV3XAllOneTest/testAvailabilityCoordinatorUpgraded__jdk11/
Given that the failure has just appeared on Jenkins and it fails relatively
easily on CircleCI, it's likely that it has been broken by a very recent change.
--
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-18564) Test Failure: MixedModeAvailabilityV3XAllOneTest.testAvailabilityCoordinatorUpgraded
[
https://issues.apache.org/jira/browse/CASSANDRA-18564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-18564:
--
Bug Category: Parent values: Correctness(12982)Level 1 values: Test
Failure(12990)
> Test Failure:
> MixedModeAvailabilityV3XAllOneTest.testAvailabilityCoordinatorUpgraded
>
>
> Key: CASSANDRA-18564
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18564
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: Andres de la Peña
>Priority: Normal
>
> The JVM upgrade dtest
> {{MixedModeAvailabilityV3XAllOneTest.testAvailabilityCoordinatorUpgraded}}
> seems to be flaky at least in {{trunk}}:
> {code}
> junit.framework.AssertionFailedError: Error in test '4.0.11 -> [5.0]' while
> upgrading to '5.0'; successful upgrades []
> at
> org.apache.cassandra.distributed.upgrade.UpgradeTestBase$TestCase.run(UpgradeTestBase.java:348)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase.testAvailability(MixedModeAvailabilityTestBase.java:154)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase.testAvailabilityCoordinatorUpgraded(MixedModeAvailabilityTestBase.java:74)
> Caused by: java.lang.AssertionError: Unexpected error while reading in case
> write-read consistency ALL-ONE with upgraded coordinator and 2 nodes down:
> org.apache.cassandra.exceptions.ReadTimeoutException: Operation timed out -
> received only 0 responses.
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase.lambda$testAvailability$6(MixedModeAvailabilityTestBase.java:145)
> at
> org.apache.cassandra.distributed.upgrade.UpgradeTestBase$TestCase.run(UpgradeTestBase.java:339)
> Caused by: org.apache.cassandra.exceptions.ReadTimeoutException: Operation
> timed out - received only 0 responses.
> at
> org.apache.cassandra.service.reads.ReadCallback.awaitResults(ReadCallback.java:162)
> at
> org.apache.cassandra.service.reads.AbstractReadExecutor.awaitResponses(AbstractReadExecutor.java:387)
> at
> org.apache.cassandra.service.StorageProxy.fetchRows(StorageProxy.java:2124)
> at
> org.apache.cassandra.service.StorageProxy.readRegular(StorageProxy.java:1995)
> at
> org.apache.cassandra.service.StorageProxy.read(StorageProxy.java:1873)
> at
> org.apache.cassandra.db.SinglePartitionReadCommand$Group.execute(SinglePartitionReadCommand.java:1286)
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:364)
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:293)
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:105)
> at
> org.apache.cassandra.distributed.impl.Coordinator.unsafeExecuteInternal(Coordinator.java:122)
> at
> org.apache.cassandra.distributed.impl.Coordinator.unsafeExecuteInternal(Coordinator.java:103)
> at
> org.apache.cassandra.distributed.impl.Coordinator.lambda$executeWithResult$0(Coordinator.java:66)
> at org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:61)
> at org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:71)
> 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:750)
> {code}
> This has failed 143 times in 500 iterations of this CircleCI run:
> *
> https://app.circleci.com/pipelines/github/adelapena/cassandra/2927/workflows/fcd1cd60-826b-484a-8e81-d3ba640f7de9/jobs/47659/tests
> The failure has also recently appeared on Jenkins too:
> *
> https://ci-cassandra.apache.org/job/Cassandra-trunk/1585/testReport/org.apache.cassandra.distributed.upgrade/MixedModeAvailabilityV3XAllOneTest/testAvailabilityCoordinatorUpgraded__jdk11/
> Given that the failure has just appeared on Jenkins and it fails relatively
> easily on CircleCI, it's likely that it has been broken by a very recent
> change.
--
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-18423) Test failure: org.apache.cassandra.io.sstable.indexsummary.IndexSummaryTest.testLargeIndexSummary
[
https://issues.apache.org/jira/browse/CASSANDRA-18423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17728808#comment-17728808
]
Ekaterina Dimitrova commented on CASSANDRA-18423:
-
Thanks, [~mmuzaf] for all the investigations!
{quote} - I can confirm the issue, but the scope is a bit wider. In fact, all
the tests with the {{.jdk11}} postfix are not run as they are stuck on the
first one {{testLargeIndexSummary}} with an error {{Forked Java VM exited
abnormally}}{quote}
I guess you mean all the tests with jdk11 only on the specific split?
In any case, I would like to suggest to revert the patch that caused it until
the root cause is found. Running all tests is very important for releasing on
time and catching quickly regressions.
About the logs - [~mck], [~brandon.williams] , is that something you can advise
about?
> Test failure:
> org.apache.cassandra.io.sstable.indexsummary.IndexSummaryTest.testLargeIndexSummary
> -
>
> Key: CASSANDRA-18423
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18423
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/2i Index
>Reporter: Brandon Williams
>Assignee: Maxim Muzafarov
>Priority: Normal
> Fix For: 5.x
>
> Attachments: image-1.png, image.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Failed 6 times in the last 6 runs. Flakiness: 0%, Stability: 0%
> {noformat}
> unit.framework.AssertionFailedError: Forked Java VM exited abnormally. Please
> note the time in the report does not reflect the time until the VM exit.
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.util.Vector.forEach(Vector.java:1394)
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.util.Vector.forEach(Vector.java:1394)
> {noformat}
> Note that only the 'default' version of this test is failing:
> https://butler.cassandra.apache.org/#/ci/upstream/workflow/Cassandra-trunk/failure/org.apache.cassandra.io.sstable.indexsummary/IndexSummaryTest/testLargeIndexSummary
--
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-18423) Test failure: org.apache.cassandra.io.sstable.indexsummary.IndexSummaryTest.testLargeIndexSummary
[
https://issues.apache.org/jira/browse/CASSANDRA-18423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17728799#comment-17728799
]
Maxim Muzafarov commented on CASSANDRA-18423:
-
I think I need to share some intermediate results as I have spent a few days
investigating the cause.
- I can confirm the issue, but the scope is a bit wider. In fact, all the
tests with the {{.jdk11}} postfix are not run as they are stuck on the first
one {{testLargeIndexSummary}} with an error {{{}Forked Java VM exited
abnormally.{}}}.
- I have failed to reproduce the issue locally using the {{testclasslist}}
build step (or I also tried creating a new ant target to emulate the
environment);
- There are no logs for the failed suite on Jenkins (see the link), so it is
difficult to find out the cause of failed tests. The error {{Forked Java VM
exited abnormally.}} is just the tip of the iceberg, the real cause is hidden
and alive in the agent logs (I have no access to them);
[https://nightlies.apache.org/cassandra/devbranch/Cassandra-devbranch/]
I have reproduced the same stack trace limiting the maximum heap size on the
local JVM running the tests just to be sure of the possibility of such a
scenario. The easiest way to find the real cause is to find the full log or
fetch it from the build agent. I'll continue the investigation.
> Test failure:
> org.apache.cassandra.io.sstable.indexsummary.IndexSummaryTest.testLargeIndexSummary
> -
>
> Key: CASSANDRA-18423
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18423
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/2i Index
>Reporter: Brandon Williams
>Assignee: Maxim Muzafarov
>Priority: Normal
> Fix For: 5.x
>
> Attachments: image-1.png, image.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Failed 6 times in the last 6 runs. Flakiness: 0%, Stability: 0%
> {noformat}
> unit.framework.AssertionFailedError: Forked Java VM exited abnormally. Please
> note the time in the report does not reflect the time until the VM exit.
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.util.Vector.forEach(Vector.java:1394)
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.util.Vector.forEach(Vector.java:1394)
> {noformat}
> Note that only the 'default' version of this test is failing:
> https://butler.cassandra.apache.org/#/ci/upstream/workflow/Cassandra-trunk/failure/org.apache.cassandra.io.sstable.indexsummary/IndexSummaryTest/testLargeIndexSummary
--
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-18554) mTLS based client and internode authenticators
[ https://issues.apache.org/jira/browse/CASSANDRA-18554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dinesh Joshi updated CASSANDRA-18554: - Authors: Dinesh Joshi, Jyothsna Konisa (was: Jyothsna Konisa) > mTLS based client and internode authenticators > -- > > Key: CASSANDRA-18554 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18554 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Authorization >Reporter: Jyothsna Konisa >Assignee: Jyothsna Konisa >Priority: Normal > Time Spent: 10m > Remaining Estimate: 0h > > Cassandra currently doesn't have any certificate based authenticator for both > client connections and internode connections. If one wants to use certificate > based authentication protocol like TLS, in which clients send their > certificates for the TLS handshake, we can leverage the information from the > client certificate to identify a client. Using this authentication mechanism > one can avoid the pain of password generations, sharing and rotation. > Introducing following certificate based mTLS authenticators for internode and > client connections > MutualTlsAuthenticator (client authentication) > MutualTlsInternodeAuthenticator (internode authentication) > MutualTlsWithPasswordFallbackAuthenticator (for optional mode operation for > client authentication) > An implementation of MutualTlsCertificateValidator called > SpiffeCertificateValidator whose identity is SPIFFE that is embedded in SAN > of the client certificate. One can implement their own CertificateValidator > to match their needs and configure it in Cassandra.yaml -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18554) mTLS based client and internode authenticators
[ https://issues.apache.org/jira/browse/CASSANDRA-18554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dinesh Joshi updated CASSANDRA-18554: - Reviewers: Dinesh Joshi, Jon Meredith, Yifan Cai (was: Blake Eggleston, Dinesh Joshi, Jon Meredith, Yifan Cai) Status: Review In Progress (was: Patch Available) > mTLS based client and internode authenticators > -- > > Key: CASSANDRA-18554 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18554 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Authorization >Reporter: Jyothsna Konisa >Assignee: Jyothsna Konisa >Priority: Normal > Time Spent: 10m > Remaining Estimate: 0h > > Cassandra currently doesn't have any certificate based authenticator for both > client connections and internode connections. If one wants to use certificate > based authentication protocol like TLS, in which clients send their > certificates for the TLS handshake, we can leverage the information from the > client certificate to identify a client. Using this authentication mechanism > one can avoid the pain of password generations, sharing and rotation. > Introducing following certificate based mTLS authenticators for internode and > client connections > MutualTlsAuthenticator (client authentication) > MutualTlsInternodeAuthenticator (internode authentication) > MutualTlsWithPasswordFallbackAuthenticator (for optional mode operation for > client authentication) > An implementation of MutualTlsCertificateValidator called > SpiffeCertificateValidator whose identity is SPIFFE that is embedded in SAN > of the client certificate. One can implement their own CertificateValidator > to match their needs and configure it in Cassandra.yaml -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18305) Enhance nodetool compactionstats with existing MBean metrics
[
https://issues.apache.org/jira/browse/CASSANDRA-18305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17728778#comment-17728778
]
Manish Ghildiyal commented on CASSANDRA-18305:
--
Ok, would do.
> Enhance nodetool compactionstats with existing MBean metrics
>
>
> Key: CASSANDRA-18305
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18305
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Brad Schoening
>Assignee: Manish Ghildiyal
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Nodetool compactionstats reports only on active compactions, if nothing is
> active, you see only:
> {quote}$nodetool compactionstats
> pending tasks: 0
> {quote}
> but in the MBean Compaction/TotalCompactionsCompleted there are recent
> statistic in events/second for:
> * Count
> * FifteenMinueRate
> * FiveMinueRate
> * MeanRate
> * OneMinuteRate
> 1) It would be useful to see in addition:
> {quote}pending tasks: 0
> compactions completed: 20
> 1 minute rate: 0/second
> 5 minute rate: 2.3/second
> 15 minute rate: 4.6/second
> {quote}
> 2) Since compaction_throughput_mb_per_sec is a throttling parameter in
> cassandra.yaml (default 64 MBps), it would be nice to show the actual
> compaction throughput and be able to observe if you're close to the limit.
> I.e.,
> {quote}compaction throughput 13.2 MBps / 16 MBps (82.5%)
> {quote}
> 3) for completness, compactionstats should list the number of concurrent
> compactors configured, perhaps simply add to existing 'pending tasks' line:
> {quote}4 concurrent compactors, 0 pending tasks
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-13041) Do not allow removal of a DC from system_auth replication settings if the DC has active Cassandra instances
[ https://issues.apache.org/jira/browse/CASSANDRA-13041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17728772#comment-17728772 ] Stefan Miklosovic edited comment on CASSANDRA-13041 at 6/2/23 2:51 PM: --- Nevertheless, I implemented guardrail approach here (1). What I do not like about the current implementation is that it is wired into NetworkTopologyStrategy. While this "just works" because system_auth is basically on NTS _all the time_, I feel like this kind of stuff should not be wired in NTS only. There might be different replication strategies, in theory, and having this wired in NTS will make other strategies necessary to replicate this logic? Also, what if there are keyspaces in the future which need to have same treatment? So, I implemented it in AlterKeyspaceStatement and removed it from NTS and now it is replication-strategy-agnostic. If we take more generic approach to the introduced guardrail, it should be probably renamed to not contain "system_auth" string. Something like "system_keyspace_dc_removal_protection" would be more appropriate? We would then just added more keyspaces if they happen to suffer from the same problem system_auth was. I still think this makes sense to rework. Guardrails would make it able to override and emit warning only if really needed for power users and it would be by default disabled as already existing solution did it. cc [~jmckenzie] [~brandon.williams] (1) https://github.com/apache/cassandra/pull/2384 was (Author: smiklosovic): Nevertheless, I implemented guardrail approach here (1). What I do not like about the current implementation is that it is wired into NetworkTopologyStrategy. While this "just works" because system_auth is basically on NTS _all the time_, I feel like this kind of stuff should not be wired in NTS only. There might be different replication strategies, in theory, and having this wired in NTS will make other strategies necessary to replicate this logic? Also, what if there are keyspaces in the future which need to have same treatment? So, I implemented it in AlterKeyspaceStatement and removed it from NTS and now it is replication-strategy-agnostic. I still think this makes sense to rework. Guardrails would make it able to override and emit warning only if really needed for power users and it would be by default disabled as already existing solution did it. cc [~jmckenzie] [~brandon.williams] (1) https://github.com/apache/cassandra/pull/2384 > Do not allow removal of a DC from system_auth replication settings if the DC > has active Cassandra instances > --- > > Key: CASSANDRA-13041 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13041 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Distributed Metadata >Reporter: Nachiket Patil >Assignee: Stefan Miklosovic >Priority: Low > Fix For: 5.x > > Attachments: trunk.diff > > Time Spent: 10m > Remaining Estimate: 0h > > I don’t believe it is ever correct to remove a DC from the system_auth > replication settings while there are nodes up in that DC. Cassandra should > not allow this change if there are hosts which are currently members of the > cluster in that DC, as any request which is routed to these hosts will meet > an unavailable. Also dropping the keyspace system_auth should not be allowed. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-13041) Do not allow removal of a DC from system_auth replication settings if the DC has active Cassandra instances
[ https://issues.apache.org/jira/browse/CASSANDRA-13041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17728772#comment-17728772 ] Stefan Miklosovic edited comment on CASSANDRA-13041 at 6/2/23 2:48 PM: --- Nevertheless, I implemented guardrail approach here (1). What I do not like about the current implementation is that it is wired into NetworkTopologyStrategy. While this "just works" because system_auth is basically on NTS _all the time_, I feel like this kind of stuff should not be wired in NTS only. There might be different replication strategies, in theory, and having this wired in NTS will make other strategies necessary to replicate this logic? Also, what if there are keyspaces in the future which need to have same treatment? So, I implemented it in AlterKeyspaceStatement and removed it from NTS and now it is replication-strategy-agnostic. I still think this makes sense to rework. Guardrails would make it able to override and emit warning only if really needed for power users and it would be by default disabled as already existing solution did it. cc [~jmckenzie] [~brandon.williams] (1) https://github.com/apache/cassandra/pull/2384 was (Author: smiklosovic): Nevertheless, I implemented guardrail approach here (1). What I do not like about the current implementation is that it is wired into NetworkTopologyStrategy. While this "just works" because system_auth is basically on NTS _all the time_, I feel like this kind of stuff should not be wired in NTS only. There might be different replication strategies, in theory, and having this wired in NTS will make other strategies necessary to replicate this logic? Also, what if there is more keyspaces in the future which needs to have same treatment? So, I implemented it in AlterKeyspaceStatement and removed it from NTS and now it is replication-strategy-agnostic. I still think this makes sense to rework. Guardrails would make it able to override and emit warning only if really needed for power users and it would be by default disabled as already existing solution did it. cc [~jmckenzie] [~brandon.williams] (1) https://github.com/apache/cassandra/pull/2384 > Do not allow removal of a DC from system_auth replication settings if the DC > has active Cassandra instances > --- > > Key: CASSANDRA-13041 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13041 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Distributed Metadata >Reporter: Nachiket Patil >Assignee: Stefan Miklosovic >Priority: Low > Fix For: 5.x > > Attachments: trunk.diff > > Time Spent: 10m > Remaining Estimate: 0h > > I don’t believe it is ever correct to remove a DC from the system_auth > replication settings while there are nodes up in that DC. Cassandra should > not allow this change if there are hosts which are currently members of the > cluster in that DC, as any request which is routed to these hosts will meet > an unavailable. Also dropping the keyspace system_auth should not be allowed. -- 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-13041) Do not allow removal of a DC from system_auth replication settings if the DC has active Cassandra instances
[ https://issues.apache.org/jira/browse/CASSANDRA-13041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17728772#comment-17728772 ] Stefan Miklosovic commented on CASSANDRA-13041: --- Nevertheless, I implemented guardrail approach here (1). What I do not like about the current implementation is that it is wired into NetworkTopologyStrategy. While this "just works" because system_auth is basically on NTS _all the time_, I feel like this kind of stuff should not be wired in NTS only. There might be different replication strategies, in theory, and having this wired in NTS will make other strategies necessary to replicate this logic? Also, what if there is more keyspaces in the future which needs to have same treatment? So, I implemented it in AlterKeyspaceStatement and removed it from NTS and now it is replication-strategy-agnostic. I still think this makes sense to rework. Guardrails would make it able to override and emit warning only if really needed for power users and it would be by default disabled as already existing solution did it. cc [~jmckenzie] [~brandon.williams] (1) https://github.com/apache/cassandra/pull/2384 > Do not allow removal of a DC from system_auth replication settings if the DC > has active Cassandra instances > --- > > Key: CASSANDRA-13041 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13041 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Distributed Metadata >Reporter: Nachiket Patil >Assignee: Stefan Miklosovic >Priority: Low > Fix For: 5.x > > Attachments: trunk.diff > > Time Spent: 10m > Remaining Estimate: 0h > > I don’t believe it is ever correct to remove a DC from the system_auth > replication settings while there are nodes up in that DC. Cassandra should > not allow this change if there are hosts which are currently members of the > cluster in that DC, as any request which is routed to these hosts will meet > an unavailable. Also dropping the keyspace system_auth should not be allowed. -- 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-18305) Enhance nodetool compactionstats with existing MBean metrics
[
https://issues.apache.org/jira/browse/CASSANDRA-18305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17728770#comment-17728770
]
Brandon Williams commented on CASSANDRA-18305:
--
I suspect CompactionStatsTest will Just Work in 4.0, we can backport that there.
> Enhance nodetool compactionstats with existing MBean metrics
>
>
> Key: CASSANDRA-18305
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18305
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Brad Schoening
>Assignee: Manish Ghildiyal
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Nodetool compactionstats reports only on active compactions, if nothing is
> active, you see only:
> {quote}$nodetool compactionstats
> pending tasks: 0
> {quote}
> but in the MBean Compaction/TotalCompactionsCompleted there are recent
> statistic in events/second for:
> * Count
> * FifteenMinueRate
> * FiveMinueRate
> * MeanRate
> * OneMinuteRate
> 1) It would be useful to see in addition:
> {quote}pending tasks: 0
> compactions completed: 20
> 1 minute rate: 0/second
> 5 minute rate: 2.3/second
> 15 minute rate: 4.6/second
> {quote}
> 2) Since compaction_throughput_mb_per_sec is a throttling parameter in
> cassandra.yaml (default 64 MBps), it would be nice to show the actual
> compaction throughput and be able to observe if you're close to the limit.
> I.e.,
> {quote}compaction throughput 13.2 MBps / 16 MBps (82.5%)
> {quote}
> 3) for completness, compactionstats should list the number of concurrent
> compactors configured, perhaps simply add to existing 'pending tasks' line:
> {quote}4 concurrent compactors, 0 pending tasks
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-builds] branch trunk updated: Add a new line of aliases in contribulyze patch by Maxwell Guo;reviewed by Mick Semb Wever
This is an automated email from the ASF dual-hosted git repository. mck pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra-builds.git The following commit(s) were added to refs/heads/trunk by this push: new b0f1125 Add a new line of aliases in contribulyze patch by Maxwell Guo;reviewed by Mick Semb Wever b0f1125 is described below commit b0f112547eab58760ff62899af787d8dbbc39207 Author: maxwellguo AuthorDate: Thu Jun 1 22:22:45 2023 +0800 Add a new line of aliases in contribulyze patch by Maxwell Guo;reviewed by Mick Semb Wever --- contribulyze/contribulyze.aliases | 1 + 1 file changed, 1 insertion(+) diff --git a/contribulyze/contribulyze.aliases b/contribulyze/contribulyze.aliases index a526b9b..044dfe5 100644 --- a/contribulyze/contribulyze.aliases +++ b/contribulyze/contribulyze.aliases @@ -40,6 +40,7 @@ Jun Rao,junrao Lorina Poland,polandll Marcus Eriksson,Marcuse,Marcus,Krummas,Marcus Erikkson Matthew Dennis,mdennis +Maxwell Guo,Maxwell-Guo,maxwellguo,xuanling.gc Michael Kjellman,mkjellman Mick Semb Wever,Michael Semb Wever,Mck SembWever,Michael SembWever,Mck Semb Wever Nate McCall,zznate,Nat McCall - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18305) Enhance nodetool compactionstats with existing MBean metrics
[
https://issues.apache.org/jira/browse/CASSANDRA-18305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17728768#comment-17728768
]
Manish Ghildiyal commented on CASSANDRA-18305:
--
Because in 4.0 , we dont have any test for console output.
I would add one.
> Enhance nodetool compactionstats with existing MBean metrics
>
>
> Key: CASSANDRA-18305
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18305
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Brad Schoening
>Assignee: Manish Ghildiyal
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Nodetool compactionstats reports only on active compactions, if nothing is
> active, you see only:
> {quote}$nodetool compactionstats
> pending tasks: 0
> {quote}
> but in the MBean Compaction/TotalCompactionsCompleted there are recent
> statistic in events/second for:
> * Count
> * FifteenMinueRate
> * FiveMinueRate
> * MeanRate
> * OneMinuteRate
> 1) It would be useful to see in addition:
> {quote}pending tasks: 0
> compactions completed: 20
> 1 minute rate: 0/second
> 5 minute rate: 2.3/second
> 15 minute rate: 4.6/second
> {quote}
> 2) Since compaction_throughput_mb_per_sec is a throttling parameter in
> cassandra.yaml (default 64 MBps), it would be nice to show the actual
> compaction throughput and be able to observe if you're close to the limit.
> I.e.,
> {quote}compaction throughput 13.2 MBps / 16 MBps (82.5%)
> {quote}
> 3) for completness, compactionstats should list the number of concurrent
> compactors configured, perhaps simply add to existing 'pending tasks' line:
> {quote}4 concurrent compactors, 0 pending tasks
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18305) Enhance nodetool compactionstats with existing MBean metrics
[
https://issues.apache.org/jira/browse/CASSANDRA-18305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17728767#comment-17728767
]
Brandon Williams commented on CASSANDRA-18305:
--
Trunk is (or will become) 5.0, so that is covered. We are intending to fix
this from 4.0 forward (see the fixversions set on the ticket.) Ultimately
we'll need a PR for 4.0, 4.1 and trunk.
If the 4.0 patch applies to 4.1 then I will handle that part, but the 4.0 PR
does not have the tests.
> Enhance nodetool compactionstats with existing MBean metrics
>
>
> Key: CASSANDRA-18305
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18305
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Brad Schoening
>Assignee: Manish Ghildiyal
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Nodetool compactionstats reports only on active compactions, if nothing is
> active, you see only:
> {quote}$nodetool compactionstats
> pending tasks: 0
> {quote}
> but in the MBean Compaction/TotalCompactionsCompleted there are recent
> statistic in events/second for:
> * Count
> * FifteenMinueRate
> * FiveMinueRate
> * MeanRate
> * OneMinuteRate
> 1) It would be useful to see in addition:
> {quote}pending tasks: 0
> compactions completed: 20
> 1 minute rate: 0/second
> 5 minute rate: 2.3/second
> 15 minute rate: 4.6/second
> {quote}
> 2) Since compaction_throughput_mb_per_sec is a throttling parameter in
> cassandra.yaml (default 64 MBps), it would be nice to show the actual
> compaction throughput and be able to observe if you're close to the limit.
> I.e.,
> {quote}compaction throughput 13.2 MBps / 16 MBps (82.5%)
> {quote}
> 3) for completness, compactionstats should list the number of concurrent
> compactors configured, perhaps simply add to existing 'pending tasks' line:
> {quote}4 concurrent compactors, 0 pending tasks
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18305) Enhance nodetool compactionstats with existing MBean metrics
[
https://issues.apache.org/jira/browse/CASSANDRA-18305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-18305:
-
Fix Version/s: 5.x
(was: 5.0)
> Enhance nodetool compactionstats with existing MBean metrics
>
>
> Key: CASSANDRA-18305
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18305
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Brad Schoening
>Assignee: Manish Ghildiyal
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Nodetool compactionstats reports only on active compactions, if nothing is
> active, you see only:
> {quote}$nodetool compactionstats
> pending tasks: 0
> {quote}
> but in the MBean Compaction/TotalCompactionsCompleted there are recent
> statistic in events/second for:
> * Count
> * FifteenMinueRate
> * FiveMinueRate
> * MeanRate
> * OneMinuteRate
> 1) It would be useful to see in addition:
> {quote}pending tasks: 0
> compactions completed: 20
> 1 minute rate: 0/second
> 5 minute rate: 2.3/second
> 15 minute rate: 4.6/second
> {quote}
> 2) Since compaction_throughput_mb_per_sec is a throttling parameter in
> cassandra.yaml (default 64 MBps), it would be nice to show the actual
> compaction throughput and be able to observe if you're close to the limit.
> I.e.,
> {quote}compaction throughput 13.2 MBps / 16 MBps (82.5%)
> {quote}
> 3) for completness, compactionstats should list the number of concurrent
> compactors configured, perhaps simply add to existing 'pending tasks' line:
> {quote}4 concurrent compactors, 0 pending tasks
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18305) Enhance nodetool compactionstats with existing MBean metrics
[
https://issues.apache.org/jira/browse/CASSANDRA-18305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17728760#comment-17728760
]
Manish Ghildiyal commented on CASSANDRA-18305:
--
Ah ok. I made original PR against trunk. Never made any PR against 5.0. Do I
need to create one for 5.0 too?
> Enhance nodetool compactionstats with existing MBean metrics
>
>
> Key: CASSANDRA-18305
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18305
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Brad Schoening
>Assignee: Manish Ghildiyal
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Nodetool compactionstats reports only on active compactions, if nothing is
> active, you see only:
> {quote}$nodetool compactionstats
> pending tasks: 0
> {quote}
> but in the MBean Compaction/TotalCompactionsCompleted there are recent
> statistic in events/second for:
> * Count
> * FifteenMinueRate
> * FiveMinueRate
> * MeanRate
> * OneMinuteRate
> 1) It would be useful to see in addition:
> {quote}pending tasks: 0
> compactions completed: 20
> 1 minute rate: 0/second
> 5 minute rate: 2.3/second
> 15 minute rate: 4.6/second
> {quote}
> 2) Since compaction_throughput_mb_per_sec is a throttling parameter in
> cassandra.yaml (default 64 MBps), it would be nice to show the actual
> compaction throughput and be able to observe if you're close to the limit.
> I.e.,
> {quote}compaction throughput 13.2 MBps / 16 MBps (82.5%)
> {quote}
> 3) for completness, compactionstats should list the number of concurrent
> compactors configured, perhaps simply add to existing 'pending tasks' line:
> {quote}4 concurrent compactors, 0 pending tasks
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18305) Enhance nodetool compactionstats with existing MBean metrics
[
https://issues.apache.org/jira/browse/CASSANDRA-18305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17728758#comment-17728758
]
Brandon Williams commented on CASSANDRA-18305:
--
Yes, I see them in the trunk PR only.
> Enhance nodetool compactionstats with existing MBean metrics
>
>
> Key: CASSANDRA-18305
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18305
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Brad Schoening
>Assignee: Manish Ghildiyal
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Nodetool compactionstats reports only on active compactions, if nothing is
> active, you see only:
> {quote}$nodetool compactionstats
> pending tasks: 0
> {quote}
> but in the MBean Compaction/TotalCompactionsCompleted there are recent
> statistic in events/second for:
> * Count
> * FifteenMinueRate
> * FiveMinueRate
> * MeanRate
> * OneMinuteRate
> 1) It would be useful to see in addition:
> {quote}pending tasks: 0
> compactions completed: 20
> 1 minute rate: 0/second
> 5 minute rate: 2.3/second
> 15 minute rate: 4.6/second
> {quote}
> 2) Since compaction_throughput_mb_per_sec is a throttling parameter in
> cassandra.yaml (default 64 MBps), it would be nice to show the actual
> compaction throughput and be able to observe if you're close to the limit.
> I.e.,
> {quote}compaction throughput 13.2 MBps / 16 MBps (82.5%)
> {quote}
> 3) for completness, compactionstats should list the number of concurrent
> compactors configured, perhaps simply add to existing 'pending tasks' line:
> {quote}4 concurrent compactors, 0 pending tasks
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18305) Enhance nodetool compactionstats with existing MBean metrics
[
https://issues.apache.org/jira/browse/CASSANDRA-18305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17728756#comment-17728756
]
Manish Ghildiyal commented on CASSANDRA-18305:
--
Ok.
But can you see the test changes.
> Enhance nodetool compactionstats with existing MBean metrics
>
>
> Key: CASSANDRA-18305
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18305
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Brad Schoening
>Assignee: Manish Ghildiyal
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Nodetool compactionstats reports only on active compactions, if nothing is
> active, you see only:
> {quote}$nodetool compactionstats
> pending tasks: 0
> {quote}
> but in the MBean Compaction/TotalCompactionsCompleted there are recent
> statistic in events/second for:
> * Count
> * FifteenMinueRate
> * FiveMinueRate
> * MeanRate
> * OneMinuteRate
> 1) It would be useful to see in addition:
> {quote}pending tasks: 0
> compactions completed: 20
> 1 minute rate: 0/second
> 5 minute rate: 2.3/second
> 15 minute rate: 4.6/second
> {quote}
> 2) Since compaction_throughput_mb_per_sec is a throttling parameter in
> cassandra.yaml (default 64 MBps), it would be nice to show the actual
> compaction throughput and be able to observe if you're close to the limit.
> I.e.,
> {quote}compaction throughput 13.2 MBps / 16 MBps (82.5%)
> {quote}
> 3) for completness, compactionstats should list the number of concurrent
> compactors configured, perhaps simply add to existing 'pending tasks' line:
> {quote}4 concurrent compactors, 0 pending tasks
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18305) Enhance nodetool compactionstats with existing MBean metrics
[
https://issues.apache.org/jira/browse/CASSANDRA-18305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17728754#comment-17728754
]
Brandon Williams commented on CASSANDRA-18305:
--
That definitely does not appear for me when logged in, or in incognito mode. I
think it's because it's in 'pending', but in any case I think that is the best
place to get the current compaction rate, since the limiter is what directly
controls it.
> Enhance nodetool compactionstats with existing MBean metrics
>
>
> Key: CASSANDRA-18305
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18305
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Brad Schoening
>Assignee: Manish Ghildiyal
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Nodetool compactionstats reports only on active compactions, if nothing is
> active, you see only:
> {quote}$nodetool compactionstats
> pending tasks: 0
> {quote}
> but in the MBean Compaction/TotalCompactionsCompleted there are recent
> statistic in events/second for:
> * Count
> * FifteenMinueRate
> * FiveMinueRate
> * MeanRate
> * OneMinuteRate
> 1) It would be useful to see in addition:
> {quote}pending tasks: 0
> compactions completed: 20
> 1 minute rate: 0/second
> 5 minute rate: 2.3/second
> 15 minute rate: 4.6/second
> {quote}
> 2) Since compaction_throughput_mb_per_sec is a throttling parameter in
> cassandra.yaml (default 64 MBps), it would be nice to show the actual
> compaction throughput and be able to observe if you're close to the limit.
> I.e.,
> {quote}compaction throughput 13.2 MBps / 16 MBps (82.5%)
> {quote}
> 3) for completness, compactionstats should list the number of concurrent
> compactors configured, perhaps simply add to existing 'pending tasks' line:
> {quote}4 concurrent compactors, 0 pending tasks
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18305) Enhance nodetool compactionstats with existing MBean metrics
[
https://issues.apache.org/jira/browse/CASSANDRA-18305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17728753#comment-17728753
]
Manish Ghildiyal edited comment on CASSANDRA-18305 at 6/2/23 2:08 PM:
--
Body of the comment:
*After working a bit more through the code, I am not sure if this is right way
of getting compaction rate. I think better/correct way is to get hold of all
CompactionInfo instances from ActiveCompactions, and use the data from them to
calculate the value.*
*Please suggest.*
Above comment is for current implementation of getCompactionRate.
was (Author: manish.c.ghildi...@gmail.com):
Body of the comment:
*After working a bit more through the code, I am not sure if this is right way
of getting compaction rate. I think better/correct way is to get hold of all
CompactionInfo instances from ActiveCompactions, and use the data from them to
calculate the value.*
*Please suggest.*
Above comment is for current implementation fo getCompactionRate. **
> Enhance nodetool compactionstats with existing MBean metrics
>
>
> Key: CASSANDRA-18305
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18305
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Brad Schoening
>Assignee: Manish Ghildiyal
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Nodetool compactionstats reports only on active compactions, if nothing is
> active, you see only:
> {quote}$nodetool compactionstats
> pending tasks: 0
> {quote}
> but in the MBean Compaction/TotalCompactionsCompleted there are recent
> statistic in events/second for:
> * Count
> * FifteenMinueRate
> * FiveMinueRate
> * MeanRate
> * OneMinuteRate
> 1) It would be useful to see in addition:
> {quote}pending tasks: 0
> compactions completed: 20
> 1 minute rate: 0/second
> 5 minute rate: 2.3/second
> 15 minute rate: 4.6/second
> {quote}
> 2) Since compaction_throughput_mb_per_sec is a throttling parameter in
> cassandra.yaml (default 64 MBps), it would be nice to show the actual
> compaction throughput and be able to observe if you're close to the limit.
> I.e.,
> {quote}compaction throughput 13.2 MBps / 16 MBps (82.5%)
> {quote}
> 3) for completness, compactionstats should list the number of concurrent
> compactors configured, perhaps simply add to existing 'pending tasks' line:
> {quote}4 concurrent compactors, 0 pending tasks
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18305) Enhance nodetool compactionstats with existing MBean metrics
[
https://issues.apache.org/jira/browse/CASSANDRA-18305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17728753#comment-17728753
]
Manish Ghildiyal edited comment on CASSANDRA-18305 at 6/2/23 2:07 PM:
--
Body of the comment:
*After working a bit more through the code, I am not sure if this is right way
of getting compaction rate. I think better/correct way is to get hold of all
CompactionInfo instances from ActiveCompactions, and use the data from them to
calculate the value.*
*Please suggest.*
Above comment is for current implementation fo getCompactionRate. **
was (Author: manish.c.ghildi...@gmail.com):
Body of the comment:
*After working a bit more through the code, I am not sure if this is right way
of getting compaction rate. I think better/correct way is to get hold of all
CompactionInfo instances from ActiveCompactions, and use the data from them to
calculate the value.*
*Please suggest.*
> Enhance nodetool compactionstats with existing MBean metrics
>
>
> Key: CASSANDRA-18305
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18305
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Brad Schoening
>Assignee: Manish Ghildiyal
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Nodetool compactionstats reports only on active compactions, if nothing is
> active, you see only:
> {quote}$nodetool compactionstats
> pending tasks: 0
> {quote}
> but in the MBean Compaction/TotalCompactionsCompleted there are recent
> statistic in events/second for:
> * Count
> * FifteenMinueRate
> * FiveMinueRate
> * MeanRate
> * OneMinuteRate
> 1) It would be useful to see in addition:
> {quote}pending tasks: 0
> compactions completed: 20
> 1 minute rate: 0/second
> 5 minute rate: 2.3/second
> 15 minute rate: 4.6/second
> {quote}
> 2) Since compaction_throughput_mb_per_sec is a throttling parameter in
> cassandra.yaml (default 64 MBps), it would be nice to show the actual
> compaction throughput and be able to observe if you're close to the limit.
> I.e.,
> {quote}compaction throughput 13.2 MBps / 16 MBps (82.5%)
> {quote}
> 3) for completness, compactionstats should list the number of concurrent
> compactors configured, perhaps simply add to existing 'pending tasks' line:
> {quote}4 concurrent compactors, 0 pending tasks
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18305) Enhance nodetool compactionstats with existing MBean metrics
[
https://issues.apache.org/jira/browse/CASSANDRA-18305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Manish Ghildiyal updated CASSANDRA-18305:
-
Attachment: (was: Screenshot 2023-06-02 at 7.33.49 PM.png)
> Enhance nodetool compactionstats with existing MBean metrics
>
>
> Key: CASSANDRA-18305
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18305
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Brad Schoening
>Assignee: Manish Ghildiyal
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Nodetool compactionstats reports only on active compactions, if nothing is
> active, you see only:
> {quote}$nodetool compactionstats
> pending tasks: 0
> {quote}
> but in the MBean Compaction/TotalCompactionsCompleted there are recent
> statistic in events/second for:
> * Count
> * FifteenMinueRate
> * FiveMinueRate
> * MeanRate
> * OneMinuteRate
> 1) It would be useful to see in addition:
> {quote}pending tasks: 0
> compactions completed: 20
> 1 minute rate: 0/second
> 5 minute rate: 2.3/second
> 15 minute rate: 4.6/second
> {quote}
> 2) Since compaction_throughput_mb_per_sec is a throttling parameter in
> cassandra.yaml (default 64 MBps), it would be nice to show the actual
> compaction throughput and be able to observe if you're close to the limit.
> I.e.,
> {quote}compaction throughput 13.2 MBps / 16 MBps (82.5%)
> {quote}
> 3) for completness, compactionstats should list the number of concurrent
> compactors configured, perhaps simply add to existing 'pending tasks' line:
> {quote}4 concurrent compactors, 0 pending tasks
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18305) Enhance nodetool compactionstats with existing MBean metrics
[
https://issues.apache.org/jira/browse/CASSANDRA-18305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17728753#comment-17728753
]
Manish Ghildiyal commented on CASSANDRA-18305:
--
Body of the comment:
*After working a bit more through the code, I am not sure if this is right way
of getting compaction rate. I think better/correct way is to get hold of all
CompactionInfo instances from ActiveCompactions, and use the data from them to
calculate the value.*
*Please suggest.*
> Enhance nodetool compactionstats with existing MBean metrics
>
>
> Key: CASSANDRA-18305
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18305
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Brad Schoening
>Assignee: Manish Ghildiyal
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Nodetool compactionstats reports only on active compactions, if nothing is
> active, you see only:
> {quote}$nodetool compactionstats
> pending tasks: 0
> {quote}
> but in the MBean Compaction/TotalCompactionsCompleted there are recent
> statistic in events/second for:
> * Count
> * FifteenMinueRate
> * FiveMinueRate
> * MeanRate
> * OneMinuteRate
> 1) It would be useful to see in addition:
> {quote}pending tasks: 0
> compactions completed: 20
> 1 minute rate: 0/second
> 5 minute rate: 2.3/second
> 15 minute rate: 4.6/second
> {quote}
> 2) Since compaction_throughput_mb_per_sec is a throttling parameter in
> cassandra.yaml (default 64 MBps), it would be nice to show the actual
> compaction throughput and be able to observe if you're close to the limit.
> I.e.,
> {quote}compaction throughput 13.2 MBps / 16 MBps (82.5%)
> {quote}
> 3) for completness, compactionstats should list the number of concurrent
> compactors configured, perhaps simply add to existing 'pending tasks' line:
> {quote}4 concurrent compactors, 0 pending tasks
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18305) Enhance nodetool compactionstats with existing MBean metrics
[
https://issues.apache.org/jira/browse/CASSANDRA-18305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Manish Ghildiyal updated CASSANDRA-18305:
-
Attachment: (was: image-2023-06-02-19-34-20-072.png)
> Enhance nodetool compactionstats with existing MBean metrics
>
>
> Key: CASSANDRA-18305
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18305
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Brad Schoening
>Assignee: Manish Ghildiyal
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0
>
> Attachments: Screenshot 2023-06-02 at 7.33.49 PM.png
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Nodetool compactionstats reports only on active compactions, if nothing is
> active, you see only:
> {quote}$nodetool compactionstats
> pending tasks: 0
> {quote}
> but in the MBean Compaction/TotalCompactionsCompleted there are recent
> statistic in events/second for:
> * Count
> * FifteenMinueRate
> * FiveMinueRate
> * MeanRate
> * OneMinuteRate
> 1) It would be useful to see in addition:
> {quote}pending tasks: 0
> compactions completed: 20
> 1 minute rate: 0/second
> 5 minute rate: 2.3/second
> 15 minute rate: 4.6/second
> {quote}
> 2) Since compaction_throughput_mb_per_sec is a throttling parameter in
> cassandra.yaml (default 64 MBps), it would be nice to show the actual
> compaction throughput and be able to observe if you're close to the limit.
> I.e.,
> {quote}compaction throughput 13.2 MBps / 16 MBps (82.5%)
> {quote}
> 3) for completness, compactionstats should list the number of concurrent
> compactors configured, perhaps simply add to existing 'pending tasks' line:
> {quote}4 concurrent compactors, 0 pending tasks
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18305) Enhance nodetool compactionstats with existing MBean metrics
[
https://issues.apache.org/jira/browse/CASSANDRA-18305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17728752#comment-17728752
]
Manish Ghildiyal commented on CASSANDRA-18305:
--
Here is the screenshot for comment body. !Screenshot 2023-06-02 at 7.33.49
PM.png!
> Enhance nodetool compactionstats with existing MBean metrics
>
>
> Key: CASSANDRA-18305
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18305
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Brad Schoening
>Assignee: Manish Ghildiyal
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0
>
> Attachments: Screenshot 2023-06-02 at 7.33.49 PM.png
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Nodetool compactionstats reports only on active compactions, if nothing is
> active, you see only:
> {quote}$nodetool compactionstats
> pending tasks: 0
> {quote}
> but in the MBean Compaction/TotalCompactionsCompleted there are recent
> statistic in events/second for:
> * Count
> * FifteenMinueRate
> * FiveMinueRate
> * MeanRate
> * OneMinuteRate
> 1) It would be useful to see in addition:
> {quote}pending tasks: 0
> compactions completed: 20
> 1 minute rate: 0/second
> 5 minute rate: 2.3/second
> 15 minute rate: 4.6/second
> {quote}
> 2) Since compaction_throughput_mb_per_sec is a throttling parameter in
> cassandra.yaml (default 64 MBps), it would be nice to show the actual
> compaction throughput and be able to observe if you're close to the limit.
> I.e.,
> {quote}compaction throughput 13.2 MBps / 16 MBps (82.5%)
> {quote}
> 3) for completness, compactionstats should list the number of concurrent
> compactors configured, perhaps simply add to existing 'pending tasks' line:
> {quote}4 concurrent compactors, 0 pending tasks
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] (CASSANDRA-18305) Enhance nodetool compactionstats with existing MBean metrics
[ https://issues.apache.org/jira/browse/CASSANDRA-18305 ]
Manish Ghildiyal deleted comment on CASSANDRA-18305:
--
was (Author: manish.c.ghildi...@gmail.com):
Here is the screenshot for comment body. !Screenshot 2023-06-02 at 7.33.49
PM.png!
> Enhance nodetool compactionstats with existing MBean metrics
>
>
> Key: CASSANDRA-18305
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18305
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Brad Schoening
>Assignee: Manish Ghildiyal
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0
>
> Attachments: Screenshot 2023-06-02 at 7.33.49 PM.png
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Nodetool compactionstats reports only on active compactions, if nothing is
> active, you see only:
> {quote}$nodetool compactionstats
> pending tasks: 0
> {quote}
> but in the MBean Compaction/TotalCompactionsCompleted there are recent
> statistic in events/second for:
> * Count
> * FifteenMinueRate
> * FiveMinueRate
> * MeanRate
> * OneMinuteRate
> 1) It would be useful to see in addition:
> {quote}pending tasks: 0
> compactions completed: 20
> 1 minute rate: 0/second
> 5 minute rate: 2.3/second
> 15 minute rate: 4.6/second
> {quote}
> 2) Since compaction_throughput_mb_per_sec is a throttling parameter in
> cassandra.yaml (default 64 MBps), it would be nice to show the actual
> compaction throughput and be able to observe if you're close to the limit.
> I.e.,
> {quote}compaction throughput 13.2 MBps / 16 MBps (82.5%)
> {quote}
> 3) for completness, compactionstats should list the number of concurrent
> compactors configured, perhaps simply add to existing 'pending tasks' line:
> {quote}4 concurrent compactors, 0 pending tasks
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18305) Enhance nodetool compactionstats with existing MBean metrics
[
https://issues.apache.org/jira/browse/CASSANDRA-18305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Manish Ghildiyal updated CASSANDRA-18305:
-
Attachment: Screenshot 2023-06-02 at 7.33.49 PM.png
> Enhance nodetool compactionstats with existing MBean metrics
>
>
> Key: CASSANDRA-18305
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18305
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Brad Schoening
>Assignee: Manish Ghildiyal
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0
>
> Attachments: Screenshot 2023-06-02 at 7.33.49 PM.png,
> image-2023-06-02-19-34-20-072.png
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Nodetool compactionstats reports only on active compactions, if nothing is
> active, you see only:
> {quote}$nodetool compactionstats
> pending tasks: 0
> {quote}
> but in the MBean Compaction/TotalCompactionsCompleted there are recent
> statistic in events/second for:
> * Count
> * FifteenMinueRate
> * FiveMinueRate
> * MeanRate
> * OneMinuteRate
> 1) It would be useful to see in addition:
> {quote}pending tasks: 0
> compactions completed: 20
> 1 minute rate: 0/second
> 5 minute rate: 2.3/second
> 15 minute rate: 4.6/second
> {quote}
> 2) Since compaction_throughput_mb_per_sec is a throttling parameter in
> cassandra.yaml (default 64 MBps), it would be nice to show the actual
> compaction throughput and be able to observe if you're close to the limit.
> I.e.,
> {quote}compaction throughput 13.2 MBps / 16 MBps (82.5%)
> {quote}
> 3) for completness, compactionstats should list the number of concurrent
> compactors configured, perhaps simply add to existing 'pending tasks' line:
> {quote}4 concurrent compactors, 0 pending tasks
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18305) Enhance nodetool compactionstats with existing MBean metrics
[
https://issues.apache.org/jira/browse/CASSANDRA-18305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Manish Ghildiyal updated CASSANDRA-18305:
-
Attachment: image-2023-06-02-19-34-20-072.png
> Enhance nodetool compactionstats with existing MBean metrics
>
>
> Key: CASSANDRA-18305
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18305
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Brad Schoening
>Assignee: Manish Ghildiyal
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0
>
> Attachments: Screenshot 2023-06-02 at 7.33.49 PM.png,
> image-2023-06-02-19-34-20-072.png
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Nodetool compactionstats reports only on active compactions, if nothing is
> active, you see only:
> {quote}$nodetool compactionstats
> pending tasks: 0
> {quote}
> but in the MBean Compaction/TotalCompactionsCompleted there are recent
> statistic in events/second for:
> * Count
> * FifteenMinueRate
> * FiveMinueRate
> * MeanRate
> * OneMinuteRate
> 1) It would be useful to see in addition:
> {quote}pending tasks: 0
> compactions completed: 20
> 1 minute rate: 0/second
> 5 minute rate: 2.3/second
> 15 minute rate: 4.6/second
> {quote}
> 2) Since compaction_throughput_mb_per_sec is a throttling parameter in
> cassandra.yaml (default 64 MBps), it would be nice to show the actual
> compaction throughput and be able to observe if you're close to the limit.
> I.e.,
> {quote}compaction throughput 13.2 MBps / 16 MBps (82.5%)
> {quote}
> 3) for completness, compactionstats should list the number of concurrent
> compactors configured, perhaps simply add to existing 'pending tasks' line:
> {quote}4 concurrent compactors, 0 pending tasks
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18305) Enhance nodetool compactionstats with existing MBean metrics
[
https://issues.apache.org/jira/browse/CASSANDRA-18305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17728751#comment-17728751
]
Brandon Williams commented on CASSANDRA-18305:
--
That doesn't take me to a comment, it takes me to the definition of
getCompactionRate.
> Enhance nodetool compactionstats with existing MBean metrics
>
>
> Key: CASSANDRA-18305
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18305
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Brad Schoening
>Assignee: Manish Ghildiyal
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Nodetool compactionstats reports only on active compactions, if nothing is
> active, you see only:
> {quote}$nodetool compactionstats
> pending tasks: 0
> {quote}
> but in the MBean Compaction/TotalCompactionsCompleted there are recent
> statistic in events/second for:
> * Count
> * FifteenMinueRate
> * FiveMinueRate
> * MeanRate
> * OneMinuteRate
> 1) It would be useful to see in addition:
> {quote}pending tasks: 0
> compactions completed: 20
> 1 minute rate: 0/second
> 5 minute rate: 2.3/second
> 15 minute rate: 4.6/second
> {quote}
> 2) Since compaction_throughput_mb_per_sec is a throttling parameter in
> cassandra.yaml (default 64 MBps), it would be nice to show the actual
> compaction throughput and be able to observe if you're close to the limit.
> I.e.,
> {quote}compaction throughput 13.2 MBps / 16 MBps (82.5%)
> {quote}
> 3) for completness, compactionstats should list the number of concurrent
> compactors configured, perhaps simply add to existing 'pending tasks' line:
> {quote}4 concurrent compactors, 0 pending tasks
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18305) Enhance nodetool compactionstats with existing MBean metrics
[
https://issues.apache.org/jira/browse/CASSANDRA-18305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17728749#comment-17728749
]
Manish Ghildiyal commented on CASSANDRA-18305:
--
[Link to
comment|https://github.com/apache/cassandra/pull/2333/files#diff-f7dd0237c343649f70b7ec9fefd7f6941a40b5164fd6063dce00fc09d2c234a7R2338-R2341]
> Enhance nodetool compactionstats with existing MBean metrics
>
>
> Key: CASSANDRA-18305
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18305
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Brad Schoening
>Assignee: Manish Ghildiyal
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Nodetool compactionstats reports only on active compactions, if nothing is
> active, you see only:
> {quote}$nodetool compactionstats
> pending tasks: 0
> {quote}
> but in the MBean Compaction/TotalCompactionsCompleted there are recent
> statistic in events/second for:
> * Count
> * FifteenMinueRate
> * FiveMinueRate
> * MeanRate
> * OneMinuteRate
> 1) It would be useful to see in addition:
> {quote}pending tasks: 0
> compactions completed: 20
> 1 minute rate: 0/second
> 5 minute rate: 2.3/second
> 15 minute rate: 4.6/second
> {quote}
> 2) Since compaction_throughput_mb_per_sec is a throttling parameter in
> cassandra.yaml (default 64 MBps), it would be nice to show the actual
> compaction throughput and be able to observe if you're close to the limit.
> I.e.,
> {quote}compaction throughput 13.2 MBps / 16 MBps (82.5%)
> {quote}
> 3) for completness, compactionstats should list the number of concurrent
> compactors configured, perhaps simply add to existing 'pending tasks' line:
> {quote}4 concurrent compactors, 0 pending tasks
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18305) Enhance nodetool compactionstats with existing MBean metrics
[
https://issues.apache.org/jira/browse/CASSANDRA-18305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17728747#comment-17728747
]
Brandon Williams commented on CASSANDRA-18305:
--
Your [commit with the
test|https://github.com/apache/cassandra/pull/2333/commits/8f53e9d6a263c55c8fa39cc020f855d9d66021cc]
is amended to a [merge
commit|https://github.com/apache/cassandra/commit/8f53e9d6a263c55c8fa39cc020f855d9d66021cc]
so it's not easy to separate and I can't find your comment, can you repeat it
here?
> Enhance nodetool compactionstats with existing MBean metrics
>
>
> Key: CASSANDRA-18305
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18305
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Brad Schoening
>Assignee: Manish Ghildiyal
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Nodetool compactionstats reports only on active compactions, if nothing is
> active, you see only:
> {quote}$nodetool compactionstats
> pending tasks: 0
> {quote}
> but in the MBean Compaction/TotalCompactionsCompleted there are recent
> statistic in events/second for:
> * Count
> * FifteenMinueRate
> * FiveMinueRate
> * MeanRate
> * OneMinuteRate
> 1) It would be useful to see in addition:
> {quote}pending tasks: 0
> compactions completed: 20
> 1 minute rate: 0/second
> 5 minute rate: 2.3/second
> 15 minute rate: 4.6/second
> {quote}
> 2) Since compaction_throughput_mb_per_sec is a throttling parameter in
> cassandra.yaml (default 64 MBps), it would be nice to show the actual
> compaction throughput and be able to observe if you're close to the limit.
> I.e.,
> {quote}compaction throughput 13.2 MBps / 16 MBps (82.5%)
> {quote}
> 3) for completness, compactionstats should list the number of concurrent
> compactors configured, perhaps simply add to existing 'pending tasks' line:
> {quote}4 concurrent compactors, 0 pending tasks
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-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: - Reviewers: Brandon Williams, Stefan Miklosovic (was: Stefan Miklosovic) Status: Review In Progress (was: Needs Committer) > 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: 0.5h > 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-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: Ready to Commit (was: Review In Progress) > 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: 0.5h > 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] [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&focusedCommentId=17728745#comment-17728745 ] Brad Schoening commented on CASSANDRA-17433: +1 nice work! > 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: 0.5h > 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-18562) guava vulnerability CVE-2023-2976
[ https://issues.apache.org/jira/browse/CASSANDRA-18562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-18562: - Test and Documentation Plan: run CI Status: Patch Available (was: Open) > guava vulnerability CVE-2023-2976 > - > > Key: CASSANDRA-18562 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18562 > Project: Cassandra > Issue Type: Bug > Components: Build >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.x > > > This is failing the OWASP check. -- 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&focusedCommentId=17728743#comment-17728743 ] Brandon Williams commented on CASSANDRA-17433: -- LGTM, I'm +1 if [~bschoeni] is satisfied. > 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: 0.5h > 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] [Created] (CASSANDRA-18563) Convert AccordStateCache cache from write-through to write-back
Aleksey Yeschenko created CASSANDRA-18563: - Summary: Convert AccordStateCache cache from write-through to write-back Key: CASSANDRA-18563 URL: https://issues.apache.org/jira/browse/CASSANDRA-18563 Project: Cassandra Issue Type: Improvement Reporter: Aleksey Yeschenko Assignee: Aleksey Yeschenko -- 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-13041) Do not allow removal of a DC from system_auth replication settings if the DC has active Cassandra instances
[ https://issues.apache.org/jira/browse/CASSANDRA-13041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17728715#comment-17728715 ] Stefan Miklosovic commented on CASSANDRA-13041: --- This was already implemented in CASSANDRA-17478. The approach taken there went without guardrail so I think that this ticket is not relevant anymore. > Do not allow removal of a DC from system_auth replication settings if the DC > has active Cassandra instances > --- > > Key: CASSANDRA-13041 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13041 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Distributed Metadata >Reporter: Nachiket Patil >Assignee: Stefan Miklosovic >Priority: Low > Fix For: 5.x > > Attachments: trunk.diff > > > I don’t believe it is ever correct to remove a DC from the system_auth > replication settings while there are nodes up in that DC. Cassandra should > not allow this change if there are hosts which are currently members of the > cluster in that DC, as any request which is routed to these hosts will meet > an unavailable. Also dropping the keyspace system_auth should not be allowed. -- 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&focusedCommentId=17728701#comment-17728701 ] Stefan Miklosovic commented on CASSANDRA-17433: --- fyi [~brandon.williams] > 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: 0.5h > 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] [Commented] (CASSANDRA-18562) guava vulnerability CVE-2023-2976
[ https://issues.apache.org/jira/browse/CASSANDRA-18562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17728698#comment-17728698 ] Brandon Williams commented on CASSANDRA-18562: -- Near as I can tell this is a false positive and the CVE does not exist, nor any has been filed in 2023 against guava: https://nvd.nist.gov/vuln/detail/CVE-2023-2976 https://www.cvedetails.com/product/52274/Google-Guava.html?vendor_id=1224 ||Branch||CI|| |[3.0|https://github.com/driftx/cassandra/tree/CASSANDRA-18562-3.0]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/1041/workflows/0572683c-4f4a-418c-b6b6-4ddaa22f33b5]| |[3.11|https://github.com/driftx/cassandra/tree/CASSANDRA-18562-3.11]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/1042/workflows/6aad569d-bcd3-4e86-bae4-baaf61031d52]| |[4.0|https://github.com/driftx/cassandra/tree/CASSANDRA-18562-4.0]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/1044/workflows/29253ff0-6d78-4019-bac1-77bf2bbd0819], [j11|https://app.circleci.com/pipelines/github/driftx/cassandra/1044/workflows/749d7eaf-c2e7-4b29-b9a0-932221db8c4c]| |[4.1|https://github.com/driftx/cassandra/tree/CASSANDRA-18562-4.1]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/1043/workflows/bd637682-9a02-4db2-9d9f-977aa07acdaa], [j11|https://app.circleci.com/pipelines/github/driftx/cassandra/1043/workflows/a95b57ec-bda7-464d-ad68-2081e1060c9a]| |[trunk|https://github.com/driftx/cassandra/tree/CASSANDRA-18562-trunk]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/1040/workflows/f260b72d-6175-4a1a-9bfb-b4ff3e8ff177], [j11|https://app.circleci.com/pipelines/github/driftx/cassandra/1040/workflows/37004408-718c-4833-8cc3-9227b6cd7648]| > guava vulnerability CVE-2023-2976 > - > > Key: CASSANDRA-18562 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18562 > Project: Cassandra > Issue Type: Bug > Components: Build >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.x > > > This is failing the OWASP check. -- 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&focusedCommentId=17728697#comment-17728697 ] Stefan Miklosovic commented on CASSANDRA-17433: --- PR https://github.com/apache/cassandra/pull/2378/files jenkins https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2503/ ci j11 https://app.circleci.com/pipelines/github/instaclustr/cassandra/2356/workflows/445dae27-504d-4d1e-a6ff-33cee73668e7 ci j8 https://app.circleci.com/pipelines/github/instaclustr/cassandra/2356/workflows/849c9964-9e3e-44a3-b8e8-d71cd03b970e > 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: 0.5h > 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-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 ] Stefan Miklosovic updated CASSANDRA-17433: -- Status: Needs Committer (was: Review In Progress) > 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: 0.5h > 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-18561) Extend Accord MessageType with a side effect flag
[ https://issues.apache.org/jira/browse/CASSANDRA-18561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-18561: -- Test and Documentation Plan: Mechanical change Status: Patch Available (was: In Progress) > Extend Accord MessageType with a side effect flag > - > > Key: CASSANDRA-18561 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18561 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: Aleksey Yeschenko >Assignee: Aleksey Yeschenko >Priority: Low > Fix For: 5.0 > > > Tiny change to make it easier for implementations to decide if a protocol > message should be persisted to the log. -- 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-18561) Extend Accord MessageType with a side effect flag
[ https://issues.apache.org/jira/browse/CASSANDRA-18561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-18561: -- Status: Ready to Commit (was: Review In Progress) > Extend Accord MessageType with a side effect flag > - > > Key: CASSANDRA-18561 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18561 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: Aleksey Yeschenko >Assignee: Aleksey Yeschenko >Priority: Low > Fix For: 5.0 > > > Tiny change to make it easier for implementations to decide if a protocol > message should be persisted to the log. -- 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-18561) Extend Accord MessageType with a side effect flag
[ https://issues.apache.org/jira/browse/CASSANDRA-18561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-18561: -- Source Control Link: https://github.com/apache/cassandra-accord/commit/8830d97ba517fb2d0f7f22e8e6b886a98839e694 https://github.com/apache/cassandra/commit/2230fb55cd0c0ee9c4d0732ab1a5ad2ffb28e15f Resolution: Fixed Status: Resolved (was: Ready to Commit) > Extend Accord MessageType with a side effect flag > - > > Key: CASSANDRA-18561 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18561 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: Aleksey Yeschenko >Assignee: Aleksey Yeschenko >Priority: Low > Fix For: 5.0 > > > Tiny change to make it easier for implementations to decide if a protocol > message should be persisted to the log. -- 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-18561) Extend Accord MessageType with a side effect flag
[ https://issues.apache.org/jira/browse/CASSANDRA-18561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-18561: -- Change Category: Code Clarity Complexity: Low Hanging Fruit Component/s: Accord Fix Version/s: 5.0 Reviewers: Benedict Elliott Smith Assignee: Aleksey Yeschenko Priority: Low (was: Normal) Status: Open (was: Triage Needed) > Extend Accord MessageType with a side effect flag > - > > Key: CASSANDRA-18561 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18561 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: Aleksey Yeschenko >Assignee: Aleksey Yeschenko >Priority: Low > Fix For: 5.0 > > > Tiny change to make it easier for implementations to decide if a protocol > message should be persisted to the log. -- 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-18561) Extend Accord MessageType with a side effect flag
[ https://issues.apache.org/jira/browse/CASSANDRA-18561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-18561: -- Status: Review In Progress (was: Patch Available) > Extend Accord MessageType with a side effect flag > - > > Key: CASSANDRA-18561 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18561 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: Aleksey Yeschenko >Assignee: Aleksey Yeschenko >Priority: Low > Fix For: 5.0 > > > Tiny change to make it easier for implementations to decide if a protocol > message should be persisted to the log. -- 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-18561) Extend Accord MessageType with a side effect flag
[ https://issues.apache.org/jira/browse/CASSANDRA-18561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17728694#comment-17728694 ] Aleksey Yeschenko commented on CASSANDRA-18561: --- Accord PR: [https://github.com/apache/cassandra-accord/pull/48] Cassandra PR: [https://github.com/apache/cassandra/pull/2383] > Extend Accord MessageType with a side effect flag > - > > Key: CASSANDRA-18561 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18561 > Project: Cassandra > Issue Type: Improvement >Reporter: Aleksey Yeschenko >Priority: Normal > > Tiny change to make it easier for implementations to decide if a protocol > message should be persisted to the log. -- 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 cep-15-accord updated: CEP-15: Extend Accord MessageType with a side effect flag
This is an automated email from the ASF dual-hosted git repository. aleksey pushed a commit to branch cep-15-accord in repository https://gitbox.apache.org/repos/asf/cassandra.git The following commit(s) were added to refs/heads/cep-15-accord by this push: new 2230fb55cd CEP-15: Extend Accord MessageType with a side effect flag 2230fb55cd is described below commit 2230fb55cd0c0ee9c4d0732ab1a5ad2ffb28e15f Author: Aleksey Yeschenko AuthorDate: Fri Jun 2 11:45:41 2023 +0100 CEP-15: Extend Accord MessageType with a side effect flag patch by Aleksey Yeschenko; reviewed by Benedic Elliott Smith for CASSANDRA-18561 --- modules/accord | 2 +- src/java/org/apache/cassandra/net/Verb.java | 14 +++--- .../apache/cassandra/service/accord/AccordJournal.java | 10 +- .../cassandra/service/accord/AccordMessageSink.java | 16 .../cassandra/service/accord/AccordMessageSinkTest.java | 2 +- 5 files changed, 22 insertions(+), 22 deletions(-) diff --git a/modules/accord b/modules/accord index 3d0ff07cd5..8830d97ba5 16 --- a/modules/accord +++ b/modules/accord @@ -1 +1 @@ -Subproject commit 3d0ff07cd5c7db43390b85afa593e6f76471d886 +Subproject commit 8830d97ba517fb2d0f7f22e8e6b886a98839e694 diff --git a/src/java/org/apache/cassandra/net/Verb.java b/src/java/org/apache/cassandra/net/Verb.java index 781261e655..c9a678a2ca 100644 --- a/src/java/org/apache/cassandra/net/Verb.java +++ b/src/java/org/apache/cassandra/net/Verb.java @@ -229,8 +229,8 @@ public enum Verb // accord ACCORD_SIMPLE_RSP (119, P2, writeTimeout, REQUEST_RESPONSE, () -> EnumSerializer.simpleReply, RESPONSE_HANDLER ), -ACCORD_PREACCEPT_RSP(121, P2, writeTimeout, REQUEST_RESPONSE, () -> PreacceptSerializers.reply, RESPONSE_HANDLER ), -ACCORD_PREACCEPT_REQ(120, P2, writeTimeout, IMMEDIATE, () -> PreacceptSerializers.request, () -> AccordService.instance().verbHandler(), ACCORD_PREACCEPT_RSP ), +ACCORD_PRE_ACCEPT_RSP (121, P2, writeTimeout, REQUEST_RESPONSE, () -> PreacceptSerializers.reply, RESPONSE_HANDLER ), +ACCORD_PRE_ACCEPT_REQ (120, P2, writeTimeout, IMMEDIATE, () -> PreacceptSerializers.request, () -> AccordService.instance().verbHandler(), ACCORD_PRE_ACCEPT_RSP ), ACCORD_ACCEPT_RSP (124, P2, writeTimeout, REQUEST_RESPONSE, () -> AcceptSerializers.reply, RESPONSE_HANDLER ), ACCORD_ACCEPT_REQ (122, P2, writeTimeout, IMMEDIATE, () -> AcceptSerializers.request,() -> AccordService.instance().verbHandler(), ACCORD_ACCEPT_RSP ), ACCORD_ACCEPT_INVALIDATE_REQ(123, P2, writeTimeout, IMMEDIATE, () -> AcceptSerializers.invalidate, () -> AccordService.instance().verbHandler(), ACCORD_ACCEPT_RSP ), @@ -240,13 +240,13 @@ public enum Verb ACCORD_COMMIT_INVALIDATE_REQ(126, P2, writeTimeout, IMMEDIATE, () -> CommitSerializers.invalidate, () -> AccordService.instance().verbHandler()), ACCORD_APPLY_RSP(130, P2, writeTimeout, REQUEST_RESPONSE, () -> ApplySerializers.reply, RESPONSE_HANDLER ), ACCORD_APPLY_REQ(129, P2, writeTimeout, IMMEDIATE, () -> ApplySerializers.request, () -> AccordService.instance().verbHandler(), ACCORD_APPLY_RSP ), -ACCORD_RECOVER_RSP (132, P2, writeTimeout, REQUEST_RESPONSE, () -> RecoverySerializers.reply,RESPONSE_HANDLER ), -ACCORD_RECOVER_REQ (131, P2, writeTimeout, IMMEDIATE, () -> RecoverySerializers.request, () -> AccordService.instance().verbHandler(), ACCORD_RECOVER_RSP), +ACCORD_BEGIN_RECOVER_RSP(132, P2, writeTimeout, REQUEST_RESPONSE, () -> RecoverySerializers.reply,RESPONSE_HANDLER ), +ACCORD_BEGIN_RECOVER_REQ(131, P2, writeTimeout, IMMEDIATE, () -> RecoverySerializers.request, () -> AccordService.instance().verbHandler(), ACCORD_BEGIN_RECOVER_RSP ), ACCORD_BEGIN_INVALIDATE_RSP (134, P2, writeTimeout, REQUEST_RESPONSE, () -> BeginInvalidationSerializers.reply, RESPONSE_HANDLER ), ACCORD_BEGIN_INVALIDATE_REQ (133, P2, wri
[cassandra-accord] branch trunk updated: CEP-15: Extend Accord MessageType with a side effect flag
This is an automated email from the ASF dual-hosted git repository.
aleksey pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra-accord.git
The following commit(s) were added to refs/heads/trunk by this push:
new 8830d97b CEP-15: Extend Accord MessageType with a side effect flag
8830d97b is described below
commit 8830d97ba517fb2d0f7f22e8e6b886a98839e694
Author: Aleksey Yeschenko
AuthorDate: Fri Jun 2 11:00:03 2023 +0100
CEP-15: Extend Accord MessageType with a side effect flag
patch by Aleksey Yeschenko; reviewed by Benedic Elliott Smith for
CASSANDRA-18561
---
.../src/main/java/accord/messages/Commit.java | 2 +-
.../main/java/accord/messages/InformOfTxnId.java | 2 +-
.../src/main/java/accord/messages/MessageType.java | 66 +-
.../src/main/java/accord/messages/PreAccept.java | 4 +-
4 files changed, 42 insertions(+), 32 deletions(-)
diff --git a/accord-core/src/main/java/accord/messages/Commit.java
b/accord-core/src/main/java/accord/messages/Commit.java
index 91732b41..8d21c9e0 100644
--- a/accord-core/src/main/java/accord/messages/Commit.java
+++ b/accord-core/src/main/java/accord/messages/Commit.java
@@ -288,7 +288,7 @@ public class Commit extends TxnRequest
@Override
public MessageType type()
{
-return MessageType.COMMIT_INVALIDATE;
+return MessageType.COMMIT_INVALIDATE_REQ;
}
@Override
diff --git a/accord-core/src/main/java/accord/messages/InformOfTxnId.java
b/accord-core/src/main/java/accord/messages/InformOfTxnId.java
index b29c72c1..dbb65e4b 100644
--- a/accord-core/src/main/java/accord/messages/InformOfTxnId.java
+++ b/accord-core/src/main/java/accord/messages/InformOfTxnId.java
@@ -73,7 +73,7 @@ public class InformOfTxnId extends
AbstractEpochRequest implements Reques
@Override
public MessageType type()
{
-return MessageType.INFORM_TXNID_REQ;
+return MessageType.INFORM_OF_TXN_REQ;
}
@Override
diff --git a/accord-core/src/main/java/accord/messages/MessageType.java
b/accord-core/src/main/java/accord/messages/MessageType.java
index 5de5cdb4..f5361e6e 100644
--- a/accord-core/src/main/java/accord/messages/MessageType.java
+++ b/accord-core/src/main/java/accord/messages/MessageType.java
@@ -15,37 +15,47 @@
* See the License for the specific language governing permissions and
* limitations under the License.
*/
-
package accord.messages;
/**
- * meant to assist implementations map accord messages to their own messaging
systems
+ * Meant to assist implementations map accord messages to their own messaging
systems.
*/
public enum MessageType
{
-SIMPLE_RSP,
-PREACCEPT_REQ,
-PREACCEPT_RSP,
-ACCEPT_REQ,
-ACCEPT_RSP,
-ACCEPT_INVALIDATE_REQ,
-GET_DEPS_REQ,
-GET_DEPS_RSP,
-COMMIT_REQ,
-COMMIT_INVALIDATE,
-APPLY_REQ,
-APPLY_RSP,
-READ_REQ,
-READ_RSP,
-BEGIN_RECOVER_REQ,
-BEGIN_RECOVER_RSP,
-BEGIN_INVALIDATE_REQ,
-BEGIN_INVALIDATE_RSP,
-WAIT_ON_COMMIT_REQ,
-WAIT_ON_COMMIT_RSP,
-INFORM_TXNID_REQ,
-INFORM_DURABLE_REQ,
-INFORM_HOME_DURABLE_REQ,
-CHECK_STATUS_REQ,
-CHECK_STATUS_RSP,
-}
+SIMPLE_RSP (false),
+PRE_ACCEPT_REQ (true ),
+PRE_ACCEPT_RSP (false),
+ACCEPT_REQ (true ),
+ACCEPT_RSP (false),
+ACCEPT_INVALIDATE_REQ (true ),
+GET_DEPS_REQ(false),
+GET_DEPS_RSP(false),
+COMMIT_REQ (true ),
+COMMIT_INVALIDATE_REQ (true ),
+APPLY_REQ (true ),
+APPLY_RSP (false),
+READ_REQ(false),
+READ_RSP(false),
+BEGIN_RECOVER_REQ (true ),
+BEGIN_RECOVER_RSP (false),
+BEGIN_INVALIDATE_REQ(true ),
+BEGIN_INVALIDATE_RSP(false),
+WAIT_ON_COMMIT_REQ (false),
+WAIT_ON_COMMIT_RSP (false),
+INFORM_OF_TXN_REQ (true ),
+INFORM_DURABLE_REQ (true ),
+INFORM_HOME_DURABLE_REQ (true ),
+CHECK_STATUS_REQ(false),
+CHECK_STATUS_RSP(false),
+;
+
+/**
+ * If true, indicates that processing of the message has important side
effects.
+ */
+public final boolean hasSideEffects;
+
+MessageType(boolean hasSideEffects)
+{
+this.hasSideEffects = hasSideEffects;
+}
+}
\ No newline at end of file
diff --git a/accord-core/src/main/java/accord/messages/PreAccept.java
b/accord-core/src/main/java/accord/messages/PreAccept.java
index 5b482169..38f96b51 100644
--- a/accord-core/src/main/java/accord/messages/PreAccept.java
+++ b/accord-core/src/main/java/accord/messages/PreAccept.java
@@ -148,7 +148,7 @@ public class PreAccept extends
WithUnsynced
@Override
public MessageType type()
{
-return MessageType.PREACCEPT_REQ;
+return MessageType.PRE_ACCEPT_REQ;
[jira] [Updated] (CASSANDRA-18562) guava vulnerability CVE-2023-2976
[ https://issues.apache.org/jira/browse/CASSANDRA-18562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-18562: - Bug Category: Parent values: Security(12985) Complexity: Normal Component/s: Build Discovered By: User Report Fix Version/s: 3.0.x 3.11.x 4.0.x 4.1.x 5.x Severity: Normal Assignee: Brandon Williams Status: Open (was: Triage Needed) > guava vulnerability CVE-2023-2976 > - > > Key: CASSANDRA-18562 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18562 > Project: Cassandra > Issue Type: Bug > Components: Build >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.x > > > This is failing the OWASP check. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-18562) guava vulnerability CVE-2023-2976
Brandon Williams created CASSANDRA-18562: Summary: guava vulnerability CVE-2023-2976 Key: CASSANDRA-18562 URL: https://issues.apache.org/jira/browse/CASSANDRA-18562 Project: Cassandra Issue Type: Bug Reporter: Brandon Williams This is failing the OWASP check. -- 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-18285) Add JDK 11 upgrade tests for 4.0+ in CircleCI
[ https://issues.apache.org/jira/browse/CASSANDRA-18285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17728678#comment-17728678 ] Michael Semb Wever commented on CASSANDRA-18285: bq. Mine and your links do not point to a specific line in GitHub it will if you "Load diff" on the right file > Add JDK 11 upgrade tests for 4.0+ in CircleCI > - > > Key: CASSANDRA-18285 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18285 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.0.x, 4.1.x, 5.x > > > Currently we test upgrades with Java 8, in preparation to drop it we need > first to ensurer we test with 11. This has to be added not only in trunk,, > but also 4.1 > I believe [~mck] has this ready to push in Jenkins at some point so this > ticket should accommodate the addition of those upgrade tests in CircleCI for > 4.1 and trunk. -- 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-18285) Add JDK 11 upgrade tests for 4.0+ in CircleCI
[ https://issues.apache.org/jira/browse/CASSANDRA-18285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17728675#comment-17728675 ] Ekaterina Dimitrova commented on CASSANDRA-18285: - Mine and your links do not point to a specific line in GitHub (even if I tried to take a direct link to a particular line), but I found the check. It seems at one place, 1.8 is dropped; in another, it is not, and I missed that one initially. Thanks for bearing with me; I wanted to be sure I got everything right. I will move to create equivalent jobs in CircleCI now. > Add JDK 11 upgrade tests for 4.0+ in CircleCI > - > > Key: CASSANDRA-18285 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18285 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.0.x, 4.1.x, 5.x > > > Currently we test upgrades with Java 8, in preparation to drop it we need > first to ensurer we test with 11. This has to be added not only in trunk,, > but also 4.1 > I believe [~mck] has this ready to push in Jenkins at some point so this > ticket should accommodate the addition of those upgrade tests in CircleCI for > 4.1 and trunk. -- 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 (08e7a3d1 -> 66ba22e7)
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 08e7a3d1 generate docs for 1b144e50 new 66ba22e7 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 (08e7a3d1) \ N -- N -- N refs/heads/asf-staging (66ba22e7) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: site-ui/build/ui-bundle.zip | Bin 4796900 -> 4796900 bytes 1 file changed, 0 insertions(+), 0 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18285) Add JDK 11 upgrade tests for 4.0+ in CircleCI
[ https://issues.apache.org/jira/browse/CASSANDRA-18285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17728668#comment-17728668 ] Michael Semb Wever commented on CASSANDRA-18285: bq. It is but the tests are run with jdk 11 for trunk in Jenkins … https://github.com/apache/cassandra-builds/commit/7e205252a001b9316efe98da329d26e3b62c1df9#diff-1f760d89dfb81ea05a11d862007a4e4e586b38aac7ae87f62c5b2e86571809c0R118 (so in jenkins 8 has already been dropped for trunk's jvm-dtest-upgrade) > Add JDK 11 upgrade tests for 4.0+ in CircleCI > - > > Key: CASSANDRA-18285 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18285 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.0.x, 4.1.x, 5.x > > > Currently we test upgrades with Java 8, in preparation to drop it we need > first to ensurer we test with 11. This has to be added not only in trunk,, > but also 4.1 > I believe [~mck] has this ready to push in Jenkins at some point so this > ticket should accommodate the addition of those upgrade tests in CircleCI for > 4.1 and trunk. -- 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-18285) Add JDK 11 upgrade tests for 4.0+ in CircleCI
[ https://issues.apache.org/jira/browse/CASSANDRA-18285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17728665#comment-17728665 ] Ekaterina Dimitrova commented on CASSANDRA-18285: - It is but the tests are run with jdk 11 for trunk in Jenkins, even if we haven’t dropped 8 yet and I do not understand why as 1.8 is not dropped from the list in the scripts yet. See [here|https://ci-cassandra.apache.org/job/Cassandra-trunk/1585/testReport/org.apache.cassandra.distributed.upgrade/MixedModeAvailabilityV30AllOneTest/testAvailabilityCoordinatorUpgraded__jdk11/] > Add JDK 11 upgrade tests for 4.0+ in CircleCI > - > > Key: CASSANDRA-18285 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18285 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.0.x, 4.1.x, 5.x > > > Currently we test upgrades with Java 8, in preparation to drop it we need > first to ensurer we test with 11. This has to be added not only in trunk,, > but also 4.1 > I believe [~mck] has this ready to push in Jenkins at some point so this > ticket should accommodate the addition of those upgrade tests in CircleCI for > 4.1 and trunk. -- 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-18285) Add JDK 11 upgrade tests for 4.0+ in CircleCI
[ https://issues.apache.org/jira/browse/CASSANDRA-18285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17728656#comment-17728656 ] Michael Semb Wever commented on CASSANDRA-18285: bq. Though it seems in trunk, we should still see them run with 8 as it still needs to be dropped here. Yes, it will be dropped with CASSANDRA-18255. Until then 8 is the common lowest jdk from 4.x to 5.x > Add JDK 11 upgrade tests for 4.0+ in CircleCI > - > > Key: CASSANDRA-18285 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18285 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.0.x, 4.1.x, 5.x > > > Currently we test upgrades with Java 8, in preparation to drop it we need > first to ensurer we test with 11. This has to be added not only in trunk,, > but also 4.1 > I believe [~mck] has this ready to push in Jenkins at some point so this > ticket should accommodate the addition of those upgrade tests in CircleCI for > 4.1 and trunk. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-18561) Extend Accord MessageType with a side effect flag
Aleksey Yeschenko created CASSANDRA-18561: - Summary: Extend Accord MessageType with a side effect flag Key: CASSANDRA-18561 URL: https://issues.apache.org/jira/browse/CASSANDRA-18561 Project: Cassandra Issue Type: Improvement Reporter: Aleksey Yeschenko Tiny change to make it easier for implementations to decide if a protocol message should be persisted to the log. -- 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-18506) Deduplicate the MixedModeAvailability upgrade jvm-dtests
[ https://issues.apache.org/jira/browse/CASSANDRA-18506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17728650#comment-17728650 ] Michael Semb Wever commented on CASSANDRA-18506: renames done. CI - ci-cassandra: https://ci-cassandra.apache.org/job/Cassandra-devbranch-dtest-upgrade/1690/ - circleci: https://app.circleci.com/pipelines/github/michaelsembwever/cassandra/158/workflows/92452beb-7922-48e3-a98b-56152bda592e > Deduplicate the MixedModeAvailability upgrade jvm-dtests > > > Key: CASSANDRA-18506 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18506 > Project: Cassandra > Issue Type: Task > Components: Test/dtest/java >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: Normal > Fix For: 5.x > > Time Spent: 0.5h > Remaining Estimate: 0h > > There's V30 and V3X duplicates of each subclass test to > MixedModeAvailabilityTestBase. > The V3X tests will always also be run in the V30. > Suggestion is to dedup and remove the version from the names. -- 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-18285) Add JDK 11 upgrade tests for 4.0+ in CircleCI
[ https://issues.apache.org/jira/browse/CASSANDRA-18285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17728648#comment-17728648 ] Ekaterina Dimitrova commented on CASSANDRA-18285: - Thank you for confirming. What about this question: bq. Though it seems in trunk, we should still see them run with 8 as it still needs to be dropped here. What am I missing? > Add JDK 11 upgrade tests for 4.0+ in CircleCI > - > > Key: CASSANDRA-18285 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18285 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.0.x, 4.1.x, 5.x > > > Currently we test upgrades with Java 8, in preparation to drop it we need > first to ensurer we test with 11. This has to be added not only in trunk,, > but also 4.1 > I believe [~mck] has this ready to push in Jenkins at some point so this > ticket should accommodate the addition of those upgrade tests in CircleCI for > 4.1 and trunk. -- 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 ] Stefan Miklosovic updated CASSANDRA-17433: -- Reviewers: Stefan Miklosovic Status: Review In Progress (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: 0.5h > 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-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 ] Stefan Miklosovic updated CASSANDRA-17433: -- Status: Patch Available (was: Open) https://github.com/apache/cassandra/pull/2378/files > 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: 0.5h > 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-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: Needs Committer (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: 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-18285) Add JDK 11 upgrade tests for 4.0+ in CircleCI
[ https://issues.apache.org/jira/browse/CASSANDRA-18285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17728611#comment-17728611 ] Michael Semb Wever commented on CASSANDRA-18285: We will need to filter out upgrade tests that are not valid with the current jdk. If/Where forward-upgrade tests exist, they will only be run (not skipped) when the jdk is the common jdk for that version and the forward version. The consequence of this is that we would need to run upgrade tests twice, on each jdk, to ensure all upgrade tests are run. (They would not be duplicated, as upgrade tests would only run on the default/lowest common jdk that exists on the upgrade path.) > Add JDK 11 upgrade tests for 4.0+ in CircleCI > - > > Key: CASSANDRA-18285 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18285 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.0.x, 4.1.x, 5.x > > > Currently we test upgrades with Java 8, in preparation to drop it we need > first to ensurer we test with 11. This has to be added not only in trunk,, > but also 4.1 > I believe [~mck] has this ready to push in Jenkins at some point so this > ticket should accommodate the addition of those upgrade tests in CircleCI for > 4.1 and trunk. -- 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
