[jira] [Updated] (CASSANDRA-19216) CMS: Additional nodes are not added to CMS
[
https://issues.apache.org/jira/browse/CASSANDRA-19216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-19216:
--
Since Version: NA
Source Control Link:
https://github.com/apache/cassandra/commit/3acec3c28e56239147d9fb4bd821a49f4b86a77a
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
> CMS: Additional nodes are not added to CMS
> --
>
> Key: CASSANDRA-19216
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19216
> Project: Cassandra
> Issue Type: Bug
> Components: Transactional Cluster Metadata
>Reporter: Paul Chandler
>Assignee: Marcus Eriksson
>Priority: Normal
> Fix For: 5.1-alpha1
>
> Attachments: ci_summary.html, result_details.tar.gz
>
>
> When creating a 3 node cluster on a local machine using 3 loopback addresses
> 127.0.0.1
> 127.0.0.2
> 127.0.0.3
> The nodes are created correctly and the first node is assigned as a CMS node
> as shown:
> {{bin/nodetool p 7199 status{-}{-}}}
> {{{}Datacenter:
> datacenter1{}}}{{{}==={}}}{{{}Status=Up/Down{}}}{{{}|/
> State=Normal/Leaving/Joining/Moving{}}}{{{}- Address Load Tokens
> Owns (effective) Host ID Rack{}}}
> {{UN 127.0.0.3 75.55 KiB 16 76.0%
> 6d194555-f6eb-41d0-c000-0003 rack1}}
> {{UN 127.0.0.2 67.97 KiB 16 59.3%
> 6d194555-f6eb-41d0-c000-0002 rack1}}
> {{UN 127.0.0.1 81 KiB 16 64.7%
> 6d194555-f6eb-41d0-c000-0001 rack1}}
> {{bin/nodetool -p 7199 describecms}}
> {{Cluster Metadata Service:}}
> {{Members: /127.0.0.1:7000}}
> {{Is Member: true}}
> {{Service State: LOCAL}}
> {{Is Migrating: false}}
> {{Epoch: 14}}
> {{Local Pending Count: 0}}
> {{Commits Paused: false}}
> {{{}Replication factor:
> ReplicationParams{class=org.apache.cassandra.locator.MetaStrategy,
> datacenter1=1{
> {{However after doing a reconfigurecms to create a replication factor of 3,
> it seems that there is still only one member of cms.}}
> {{bin/nodetool -p 7199 reconfigurecms datacenter1:3}}
> {{bin/nodetool -p 7199 describecms}}
> {{Cluster Metadata Service:}}
> {{Members: /127.0.0.1:7000}}
> {{Is Member: true}}
> {{Service State: LOCAL}}
> Is Migrating: false
> Epoch: 16
> Local Pending Count: 0
> Commits Paused: false
> Replication factor:
> ReplicationParams\{class=org.apache.cassandra.locator.MetaStrategy,
> datacenter1=3}
> Is this correct, should all 3 nodes be shown in the Members section ?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
(cassandra) branch trunk updated: Make nodetool reconfigurecms sync by default and add --cancel to be able to cancel ongoing reconfigurations
This is an automated email from the ASF dual-hosted git repository.
smiklosovic 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 3acec3c28e Make nodetool reconfigurecms sync by default and add
--cancel to be able to cancel ongoing reconfigurations
3acec3c28e is described below
commit 3acec3c28e56239147d9fb4bd821a49f4b86a77a
Author: Marcus Eriksson
AuthorDate: Thu Dec 21 12:22:59 2023 +0100
Make nodetool reconfigurecms sync by default and add --cancel to be able to
cancel ongoing reconfigurations
patch by Marcus Eriksson; reviewed by Stefan Miklosovic, Sam Tunnicliffe
for CASSANDRA-19216
Co-authored-by: Sam Tunnicliffe
---
CHANGES.txt| 1 +
.../org/apache/cassandra/tcm/CMSOperations.java| 50 +--
.../apache/cassandra/tcm/CMSOperationsMBean.java | 5 +-
.../cassandra/tcm/ownership/DataPlacements.java| 6 +++
.../tcm/sequences/CancelCMSReconfiguration.java| 56 ++
.../cassandra/tcm/sequences/ReconfigureCMS.java| 16 +++
.../cassandra/tools/nodetool/ReconfigureCMS.java | 18 ---
.../distributed/test/log/ReconfigureCMSTest.java | 25 +-
.../test/log/TriggeredReconfigureCMSTest.java | 6 +--
.../upgrade/ClusterMetadataUpgradeHarryTest.java | 2 +-
.../upgrade/ClusterMetadataUpgradeTest.java| 2 +-
11 files changed, 129 insertions(+), 58 deletions(-)
diff --git a/CHANGES.txt b/CHANGES.txt
index f36529a350..d73539808e 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
5.1
+ * Make nodetool reconfigurecms sync by default and add --cancel to be able to
cancel ongoing reconfigurations (CASSANDRA-19216)
* Expose auth mode in system_views.clients, nodetool clientstats, metrics
(CASSANDRA-19366)
* Remove sealed_periods and last_sealed_period tables (CASSANDRA-19189)
* Improve setup and initialisation of LocalLog/LogSpec (CASSANDRA-19271)
diff --git a/src/java/org/apache/cassandra/tcm/CMSOperations.java
b/src/java/org/apache/cassandra/tcm/CMSOperations.java
index 6aaccf7f83..8eacd53873 100644
--- a/src/java/org/apache/cassandra/tcm/CMSOperations.java
+++ b/src/java/org/apache/cassandra/tcm/CMSOperations.java
@@ -29,10 +29,10 @@ import java.util.stream.Collectors;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
-import org.apache.cassandra.concurrent.ScheduledExecutors;
import org.apache.cassandra.config.DatabaseDescriptor;
import org.apache.cassandra.schema.ReplicationParams;
import org.apache.cassandra.tcm.membership.NodeVersion;
+import org.apache.cassandra.tcm.sequences.CancelCMSReconfiguration;
import org.apache.cassandra.tcm.sequences.InProgressSequences;
import org.apache.cassandra.tcm.sequences.ReconfigureCMS;
import org.apache.cassandra.tcm.serialization.Version;
@@ -73,23 +73,21 @@ public class CMSOperations implements CMSOperationsMBean
@Override
-public void reconfigureCMS(int rf, boolean sync)
+public void reconfigureCMS(int rf)
{
-Runnable r = () -> cms.reconfigureCMS(ReplicationParams.simpleMeta(rf,
ClusterMetadata.current().directory.knownDatacenters()));
-if (sync)
-r.run();
-else
-ScheduledExecutors.nonPeriodicTasks.submit(r);
+cms.reconfigureCMS(ReplicationParams.simpleMeta(rf,
ClusterMetadata.current().directory.knownDatacenters()));
}
@Override
-public void reconfigureCMS(Map rf, boolean sync)
+public void reconfigureCMS(Map rf)
{
-Runnable r = () ->
ClusterMetadataService.instance().reconfigureCMS(ReplicationParams.ntsMeta(rf));
-if (sync)
-r.run();
-else
-ScheduledExecutors.nonPeriodicTasks.submit(r);
+cms.reconfigureCMS(ReplicationParams.ntsMeta(rf));
+}
+
+@Override
+public void cancelReconfigureCms()
+{
+cms.commit(CancelCMSReconfiguration.instance);
}
@Override
@@ -117,6 +115,9 @@ public class CMSOperations implements CMSOperationsMBean
.map(Object::toString)
.collect(Collectors.toList()));
+if (advance.diff.removals.isEmpty() &&
advance.diff.additions.isEmpty())
+status.put("INCOMPLETE", Collections.singletonList("All operations
have finished but metadata keyspace ranges are still locked"));
+
return status;
}
@@ -125,15 +126,14 @@ public class CMSOperations implements CMSOperationsMBean
{
Map info = new HashMap<>();
ClusterMetadata metadata = ClusterMetadata.current();
-ClusterMetadataService service = ClusterMetadataService.instance();
String members =
metadata.fullCMSMembers().stream().sorted().map(Object::toString).collect(Collectors.joining(","));
info.put("MEMBERS",
[jira] [Comment Edited] (CASSANDRA-19216) CMS: Additional nodes are not added to CMS
[
https://issues.apache.org/jira/browse/CASSANDRA-19216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17817113#comment-17817113
]
Stefan Miklosovic edited comment on CASSANDRA-19216 at 2/14/24 7:30 AM:
*CASSANDRA-19216-trunk*
{noformat}
java17_pre-commit_tests
✓ j17_build4m 36s
✓ j17_cqlsh_dtests_py311_vnode 7m 0s
✓ j17_cqlsh_dtests_py387m 24s
✓ j17_cqlsh_dtests_py38_vnode 6m 59s
✓ j17_cqlshlib_cython_tests7m 37s
✓ j17_cqlshlib_tests 6m 34s
✓ j17_dtests 35m 48s
✓ j17_jvm_dtests_repeat0m 44s
✓ j17_jvm_dtests_vnode_repeat 0m 41s
✕ j17_cqlsh_dtests_py311 7m 21s
✕ j17_dtests_vnode 36m 5s
client_request_metrics_local_remote_test.TestClientRequestMetricsLocalRemote
test_write_and_read (1)
✕ j17_jvm_dtests 27m 47s
✕ j17_jvm_dtests_vnode21m 14s
junit.framework.TestSuite
org.apache.cassandra.fuzz.harry.integration.model.InJVMTokenAwareExecutorTest
TIMEOUTED (2)
org.apache.cassandra.distributed.test.log.BounceIndexRebuildTest
bounceTest (3)
org.apache.cassandra.distributed.test.NativeTransportEncryptionOptionsTest
testEndpointVerificationEnabledIpNotInSAN (4)
✕ j17_unit_tests 14m 27s
org.apache.cassandra.index.sai.cql.VectorUpdateDeleteTest updateTest (5)
✕ j17_utests_oa 13m 12s
org.apache.cassandra.net.ConnectionTest testTimeout (6)
org.apache.cassandra.index.sai.cql.VectorUpdateDeleteTest updateTest (7)
java17_separate_tests
java11_pre-commit_tests
✓ j11_build8m 55s
✓ j11_cqlsh_dtests_py311 10m 48s
✓ j11_cqlsh_dtests_py311_vnode 8m 14s
✓ j11_cqlsh_dtests_py389m 45s
✓ j11_cqlsh_dtests_py38_vnode 9m 35s
✓ j11_cqlshlib_cython_tests9m 44s
✓ j11_cqlshlib_tests 10m 33s
✓ j11_dtests_vnode39m 50s
✓ j11_jvm_dtests 26m 8s
✓ j11_jvm_dtests_repeat 4m 6s
✓ j11_jvm_dtests_vnode24m 16s
✓ j11_jvm_dtests_vnode_repeat 4m 26s
✓ j17_cqlsh_dtests_py311 7m 22s
✓ j17_cqlsh_dtests_py311_vnode 7m 7s
✓ j17_cqlsh_dtests_py386m 53s
✓ j17_cqlsh_dtests_py38_vnode 7m 20s
✓ j17_cqlshlib_cython_tests9m 15s
✓ j17_cqlshlib_tests 6m 51s
✓ j17_dtests 34m 17s
✓ j17_dtests_vnode 35m 4s
✓ j17_jvm_dtests_repeat0m 48s
✓ j17_jvm_dtests_vnode_repeat 0m 16s
✕ j11_dtests 38m 17s
pushed_notifications_test.TestPushedNotifications
test_move_single_node_localhost (8)
✕ j11_simulator_dtests11m 24s
org.apache.cassandra.simulator.test.ShortPaxosSimulationTest
simulationTest (9)
✕ j11_unit_tests 15m 32s
org.apache.cassandra.index.sai.cql.VectorUpdateDeleteTest updateTest
✕ j11_utests_oa 18m 42s
org.apache.cassandra.index.sai.cql.VectorUpdateDeleteTest updateTest
✕ j11_utests_system_keyspace_directory14m 41s
org.apache.cassandra.index.sai.cql.VectorUpdateDeleteTest updateTest
✕ j17_jvm_dtests 26m 48s
✕ j17_jvm_dtests_vnode20m 49s
org.apache.cassandra.distributed.test.NativeTransportEncryptionOptionsTest
testEndpointVerificationEnabledIpNotInSAN
✕ j17_unit_tests 13m 54s
org.apache.cassandra.index.sai.cql.VectorUpdateDeleteTest updateTest
✕ j17_utests_oa 13m 42s
org.apache.cassandra.index.sai.cql.VectorUpdateDeleteTest updateTest
java11_separate_tests
{noformat}
[java17_pre-commit_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/3855/workflows/7f1d89d8-eef0-4e3c-9ea6-9329056b142e]
[java17_separate_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/3855/workflows/d9c9516a-51de-4ce5-a6f5-dce8adf14f0b]
[jira] [Commented] (CASSANDRA-19335) Default nodetool tablestats to Human-Readable Output
[ https://issues.apache.org/jira/browse/CASSANDRA-19335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17817214#comment-17817214 ] Leo Toff commented on CASSANDRA-19335: -- [~smiklosovic] yes, I was going to update the dtests. Step 0: use "--no-human-readable" for the current Cassandra's nodetool tablestats. Step 1: use JSON / YAML output instead of "--no-human-readable" when querying nodetool tablestats. [~brandon.williams] I'm actually not sure what changes CCM would need. > Default nodetool tablestats to Human-Readable Output > > > Key: CASSANDRA-19335 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19335 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool >Reporter: Leo Toff >Assignee: Leo Toff >Priority: Low > Fix For: 5.x > > Time Spent: 50m > Remaining Estimate: 0h > > *Current Behavior* > The current implementation of nodetool tablestats in Apache Cassandra outputs > statistics in a format that is not immediately human-readable. This output > primarily includes raw byte counts, which require additional calculation or > conversion to be easily understood by users. This can be inefficient and > time-consuming, especially for users who frequently monitor these statistics > for performance tuning or maintenance purposes. > *Proposed Change* > We propose that nodetool tablestats should, by default, provide its output in > a human-readable format. This change would involve converting byte counts > into more understandable units (KiB, MiB, GiB). The tool could still retain > the option to display raw data for those who need it, perhaps through a flag > such as --no-human-readable or --raw. > *Considerations* > The change should maintain backward compatibility, ensuring that scripts or > tools relying on the current output format can continue to function correctly. > We should provide adequate documentation and examples of both the new default > output and how to access the raw data format, if needed. > *Alignment* > Discussion in the dev mailing list: > [https://lists.apache.org/thread/mlp715kxho5b6f1ql9omlzmmnh4qfby9] > *Related work* > Previous work in the series: > # https://issues.apache.org/jira/browse/CASSANDRA-19015 > # https://issues.apache.org/jira/browse/CASSANDRA-19104 -- 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
Re: [PR] CASSANDRA-19369 Use XXHash32 for digest calculation of SSTables [cassandra-analytics]
frankgh commented on PR #38: URL: https://github.com/apache/cassandra-analytics/pull/38#issuecomment-1942964282 Closed via https://github.com/apache/cassandra-analytics/commit/dc0e79b9c483562ec0920d69e886715eb329c426 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19369) [Analytics] Use XXHash32 for digest calculation of SSTables
[
https://issues.apache.org/jira/browse/CASSANDRA-19369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francisco Guerrero updated CASSANDRA-19369:
---
Fix Version/s: NA
Source Control Link:
https://github.com/apache/cassandra-analytics/commit/dc0e79b9c483562ec0920d69e886715eb329c426
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
> [Analytics] Use XXHash32 for digest calculation of SSTables
> ---
>
> Key: CASSANDRA-19369
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19369
> Project: Cassandra
> Issue Type: Improvement
> Components: Analytics Library
>Reporter: Francisco Guerrero
>Assignee: Francisco Guerrero
>Priority: Normal
> Fix For: NA
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> During bulk writes, Cassandra Analytics calculates the MD5 checksum of every
> SSTable it produces. During SSTable upload to Cassandra Sidecar, Cassandra
> Analytics includes the {{content-md5}} header as part of the upload request.
> This information is used by Cassandra Sidecar to validate the integrity of
> the uploaded SSTable and prevent issues with bit flips and corrupted SSTables.
> Recently, Cassandra Sidecar introduced [support for additional checksum
> validations|https://issues.apache.org/jira/browse/CASSANDRASC-97] during
> SSTable upload. Notably the XXHash32 digest support was added which offers
> for more performant checksum calculations. This support now allows Cassandra
> Analytics to use a more efficient digest algorithm that is friendlier on the
> CPU usage of Sidecar and spark resources.
--
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
Re: [PR] CASSANDRA-19369 Use XXHash32 for digest calculation of SSTables [cassandra-analytics]
frankgh closed pull request #38: CASSANDRA-19369 Use XXHash32 for digest calculation of SSTables URL: https://github.com/apache/cassandra-analytics/pull/38 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
(cassandra-analytics) branch trunk updated: CASSANDRA-19369 Use XXHash32 for digest calculation of SSTables
This is an automated email from the ASF dual-hosted git repository.
frankgh pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra-analytics.git
The following commit(s) were added to refs/heads/trunk by this push:
new dc0e79b CASSANDRA-19369 Use XXHash32 for digest calculation of
SSTables
dc0e79b is described below
commit dc0e79b9c483562ec0920d69e886715eb329c426
Author: Francisco Guerrero
AuthorDate: Wed Jan 31 13:44:23 2024 -0800
CASSANDRA-19369 Use XXHash32 for digest calculation of SSTables
This commit adds the ability to use the newly supported in Cassandra
Sidecar XXhash32 digest algorithm.
The commit allows for backwards compatibility to perform MD5 checksumming,
but it now defaults to XXHash32.
A new Writer option is added:
```
.option(WriterOptions.DIGEST.name(), "XXHASH32") // or
.option(WriterOptions.DIGEST.name(), "MD5")
```
This option defaults to XXHash32, when not provided, but it can be
configured to use the legacy MD5 algorithm.
Path by Francisco Guerrero; Reviewed by Yifan Cai for CASSANDRA-19369
---
CHANGES.txt| 1 +
cassandra-analytics-core/build.gradle | 1 +
.../cassandra/spark/bulkwriter/BulkSparkConf.java | 16 ++-
.../spark/bulkwriter/CassandraJobInfo.java | 7 ++
.../spark/bulkwriter/DataTransferApi.java | 4 +-
.../spark/bulkwriter/DigestAlgorithmSupplier.java} | 19 +---
.../spark/bulkwriter/DigestAlgorithms.java}| 39 +--
.../apache/cassandra/spark/bulkwriter/JobInfo.java | 6 +
.../cassandra/spark/bulkwriter/RecordWriter.java | 36 --
.../cassandra/spark/bulkwriter/SSTableWriter.java | 42 ---
.../spark/bulkwriter/SidecarDataTransferApi.java | 7 +-
.../cassandra/spark/bulkwriter/StreamSession.java | 19 ++--
.../cassandra/spark/bulkwriter/WriterOptions.java | 5 +
.../spark/common/{MD5Hash.java => Digest.java} | 31 ++
.../spark/common/{MD5Hash.java => MD5Digest.java} | 44 ++--
.../cassandra/spark/common/XXHash32Digest.java | 79 +
.../cassandra/spark/utils/DigestAlgorithm.java}| 28 ++---
.../cassandra/spark/utils/MD5DigestAlgorithm.java | 55 ++
.../spark/utils/XXHash32DigestAlgorithm.java | 67 +++
.../spark/bulkwriter/MockBulkWriterContext.java| 14 ++-
.../bulkwriter/NonValidatingTestSSTableWriter.java | 5 +-
.../spark/bulkwriter/RecordWriterTest.java | 24 ++--
.../spark/bulkwriter/SSTableWriterTest.java| 8 +-
.../bulkwriter/StreamSessionConsistencyTest.java | 10 +-
.../spark/bulkwriter/StreamSessionTest.java| 18 +--
.../cassandra/spark/bulkwriter/UploadRequest.java | 14 +--
.../spark/utils/MD5DigestAlgorithmTest.java| 68
.../cassandra/spark/utils/ResourceUtils.java | 79 +
...pTests.java => SSTableInputStreamHttpTest.java} | 10 +-
.../spark/utils/XXHash32DigestAlgorithmTest.java | 71
.../src/test/resources/digest/file1.txt| 1 +
.../src/test/resources/digest/file2.txt| 1 +
.../src/test/resources/digest/file3.txt| 1 +
.../distributed/impl/AbstractClusterUtils.java | 2 +-
.../testing/SharedClusterIntegrationTestBase.java | 24
.../analytics/QuoteIdentifiersWriteTest.java | 91 ++-
.../apache/cassandra/analytics/SparkTestUtils.java | 34 ++
.../analytics/WriterDigestIntegrationTest.java | 122 +
.../org/apache/cassandra/spark/utils/MapUtils.java | 2 +-
scripts/build-sidecar.sh | 2 +-
40 files changed, 872 insertions(+), 235 deletions(-)
diff --git a/CHANGES.txt b/CHANGES.txt
index e0ff584..9daa5f0 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
1.0.0
+ * Use XXHash32 for digest calculation of SSTables (CASSANDRA-19369)
* Startup Validation Failures when Checking Sidecar Connectivity
(CASSANDRA-19377)
* No longer need to synchronize on Schema.instance after Cassandra 4.0.12
(CASSANDRA-19351)
* Upgrade to Cassandra 4.0.12 and remove RowBufferMode and BatchSize options
(CASSANDRA-19334)
diff --git a/cassandra-analytics-core/build.gradle
b/cassandra-analytics-core/build.gradle
index 9228741..e015a27 100644
--- a/cassandra-analytics-core/build.gradle
+++ b/cassandra-analytics-core/build.gradle
@@ -58,6 +58,7 @@ project(':cassandra-analytics-core') {
// This dependency must be built by running
`scripts/build-dependencies.sh`
implementation(group: "${sidecarClientGroup}", name:
"${sidecarClientName}", version: "${sidecarVersion}")
+implementation(group: 'org.lz4', name: 'lz4-java', version: '1.8.0')
if ("${scalaMajorVersion}" == "2.11") {
implementation(group: 'org.scala-lang.modules', name:
"scala-java8-compat_2.11", version: '1.0.1', transitive: false)
diff --git
[jira] [Updated] (CASSANDRA-19369) [Analytics] Use XXHash32 for digest calculation of SSTables
[
https://issues.apache.org/jira/browse/CASSANDRA-19369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francisco Guerrero updated CASSANDRA-19369:
---
Status: Ready to Commit (was: Review In Progress)
> [Analytics] Use XXHash32 for digest calculation of SSTables
> ---
>
> Key: CASSANDRA-19369
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19369
> Project: Cassandra
> Issue Type: Improvement
> Components: Analytics Library
>Reporter: Francisco Guerrero
>Assignee: Francisco Guerrero
>Priority: Normal
> Time Spent: 1h
> Remaining Estimate: 0h
>
> During bulk writes, Cassandra Analytics calculates the MD5 checksum of every
> SSTable it produces. During SSTable upload to Cassandra Sidecar, Cassandra
> Analytics includes the {{content-md5}} header as part of the upload request.
> This information is used by Cassandra Sidecar to validate the integrity of
> the uploaded SSTable and prevent issues with bit flips and corrupted SSTables.
> Recently, Cassandra Sidecar introduced [support for additional checksum
> validations|https://issues.apache.org/jira/browse/CASSANDRASC-97] during
> SSTable upload. Notably the XXHash32 digest support was added which offers
> for more performant checksum calculations. This support now allows Cassandra
> Analytics to use a more efficient digest algorithm that is friendlier on the
> CPU usage of Sidecar and spark resources.
--
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-19241) Upgrade ci-cassandra.a.o agents to Ubuntu 22.04.3
[ https://issues.apache.org/jira/browse/CASSANDRA-19241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17817185#comment-17817185 ] Brandon Williams commented on CASSANDRA-19241: -- Note that the second drive is mounted on /x1, same as where it is mounted on the others in this group. > Upgrade ci-cassandra.a.o agents to Ubuntu 22.04.3 > - > > Key: CASSANDRA-19241 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19241 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Michael Semb Wever >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.0.x, 5.x > > > All agents are currently Ubuntu 18.04 LTS per the > [docs|https://github.com/apache/cassandra-builds/blob/trunk/ASF-jenkins-agents.md#server-requirements]. > All agents need to be upgraded to Ubuntu 22.04.3 LTS. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRASC-104) Relocate Sidecar common classes in vertx-client-shaded
[
https://issues.apache.org/jira/browse/CASSANDRASC-104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francisco Guerrero updated CASSANDRASC-104:
---
Status: Ready to Commit (was: Review In Progress)
> Relocate Sidecar common classes in vertx-client-shaded
> --
>
> Key: CASSANDRASC-104
> URL: https://issues.apache.org/jira/browse/CASSANDRASC-104
> Project: Sidecar for Apache Cassandra
> Issue Type: Improvement
> Components: Configuration
>Reporter: Francisco Guerrero
>Assignee: Francisco Guerrero
>Priority: Normal
> Labels: pull-request-available
>
> It is desirable to relocate the common classes
> {{org.apache.cassandra.sidecar.common.*}} in the {{vertx-client-shaded}}
> subproject. The benefits are the following:
> - Better isolation of the shared classes when loading them in downstream
> projects (i.e Analytics)
> - Avoids having two classes loaded in the same classpath, but with different
> internal definition (for example when annotations are relocated but the class
> itself is not)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRASC-104) Relocate Sidecar common classes in vertx-client-shaded
[
https://issues.apache.org/jira/browse/CASSANDRASC-104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17817173#comment-17817173
]
Yifan Cai commented on CASSANDRASC-104:
---
+1
> Relocate Sidecar common classes in vertx-client-shaded
> --
>
> Key: CASSANDRASC-104
> URL: https://issues.apache.org/jira/browse/CASSANDRASC-104
> Project: Sidecar for Apache Cassandra
> Issue Type: Improvement
> Components: Configuration
>Reporter: Francisco Guerrero
>Assignee: Francisco Guerrero
>Priority: Normal
> Labels: pull-request-available
>
> It is desirable to relocate the common classes
> {{org.apache.cassandra.sidecar.common.*}} in the {{vertx-client-shaded}}
> subproject. The benefits are the following:
> - Better isolation of the shared classes when loading them in downstream
> projects (i.e Analytics)
> - Avoids having two classes loaded in the same classpath, but with different
> internal definition (for example when annotations are relocated but the class
> itself is not)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRASC-104) Relocate Sidecar common classes in vertx-client-shaded
[
https://issues.apache.org/jira/browse/CASSANDRASC-104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yifan Cai updated CASSANDRASC-104:
--
Reviewers: Yifan Cai
Status: Review In Progress (was: Patch Available)
> Relocate Sidecar common classes in vertx-client-shaded
> --
>
> Key: CASSANDRASC-104
> URL: https://issues.apache.org/jira/browse/CASSANDRASC-104
> Project: Sidecar for Apache Cassandra
> Issue Type: Improvement
> Components: Configuration
>Reporter: Francisco Guerrero
>Assignee: Francisco Guerrero
>Priority: Normal
> Labels: pull-request-available
>
> It is desirable to relocate the common classes
> {{org.apache.cassandra.sidecar.common.*}} in the {{vertx-client-shaded}}
> subproject. The benefits are the following:
> - Better isolation of the shared classes when loading them in downstream
> projects (i.e Analytics)
> - Avoids having two classes loaded in the same classpath, but with different
> internal definition (for example when annotations are relocated but the class
> itself is not)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19042) Repair fuzz tests fail with paxos_variant: v2
[
https://issues.apache.org/jira/browse/CASSANDRA-19042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Capwell updated CASSANDRA-19042:
--
Test and Documentation Plan: updated tests
Status: Patch Available (was: In Progress)
> Repair fuzz tests fail with paxos_variant: v2
> -
>
> Key: CASSANDRA-19042
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19042
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Repair, Feature/Lightweight Transactions,
> Test/fuzz
>Reporter: Branimir Lambov
>Assignee: David Capwell
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Adding {{paxos_variant: v2}} to the test yaml causes all fuzz repair tests to
> fail with
> {code}
> java.lang.NullPointerException: null
> at
> org.apache.cassandra.gms.EndpointStateSerializer.serializedSize(EndpointState.java:337)
> at
> org.apache.cassandra.gms.EndpointStateSerializer.serializedSize(EndpointState.java:300)
> at
> org.apache.cassandra.service.paxos.cleanup.PaxosStartPrepareCleanup$RequestSerializer.serializedSize(PaxosStartPrepareCleanup.java:176)
> at
> org.apache.cassandra.service.paxos.cleanup.PaxosStartPrepareCleanup$RequestSerializer.serializedSize(PaxosStartPrepareCleanup.java:147)
> at
> org.apache.cassandra.net.Message$Serializer.payloadSize(Message.java:1067)
> at org.apache.cassandra.net.Message.payloadSize(Message.java:1114)
> at
> org.apache.cassandra.net.Message$Serializer.serializedSize(Message.java:750)
> at org.apache.cassandra.net.Message.serializedSize(Message.java:1094)
> ...
> {code}
> This happens for all three options of {{paxos_state_purging}} and both with
> and without {{storage_compatibility_mode: NONE}}.
> Tests still fail if {{PaxosStartPrepareCleanup}} is changed to use
> {{EndpointState.nullableSerializer}}.
--
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-19285) Flaky Host replacement tests and shrink tests (Instance class loader is already closed)
[
https://issues.apache.org/jira/browse/CASSANDRA-19285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yifan Cai updated CASSANDRA-19285:
--
Fix Version/s: NA
Since Version: NA
Source Control Link:
https://github.com/apache/cassandra-analytics/commit/c3e8803b3331bc7ef81797ac52a8417524f67edc
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
> Flaky Host replacement tests and shrink tests (Instance class loader is
> already closed)
> ---
>
> Key: CASSANDRA-19285
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19285
> Project: Cassandra
> Issue Type: Bug
> Components: Analytics Library
>Reporter: Francisco Guerrero
>Assignee: Yifan Cai
>Priority: Normal
> Fix For: NA
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> During Circle CI runs there are some flaky integration tests, some noticed are
> * HostReplacementMultiDCTest
> * HostReplacementMultiDCFailureTest
> * HostReplacementFailureTest
> * LeavingSingleFailureTest
> Some of the error message I see in these tests are e.g.
> {code:java}
> java.lang.RuntimeException: java.lang.IllegalStateException: Can't load
> org.apache.cassandra.utils.concurrent.Ref$OnLeak. Instance class loader is
> already closed.
> {code}
> On repeated run, these tests pass.
--
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-19285) Flaky Host replacement tests and shrink tests (Instance class loader is already closed)
[
https://issues.apache.org/jira/browse/CASSANDRA-19285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yifan Cai updated CASSANDRA-19285:
--
Status: Ready to Commit (was: Review In Progress)
> Flaky Host replacement tests and shrink tests (Instance class loader is
> already closed)
> ---
>
> Key: CASSANDRA-19285
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19285
> Project: Cassandra
> Issue Type: Bug
> Components: Analytics Library
>Reporter: Francisco Guerrero
>Assignee: Yifan Cai
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> During Circle CI runs there are some flaky integration tests, some noticed are
> * HostReplacementMultiDCTest
> * HostReplacementMultiDCFailureTest
> * HostReplacementFailureTest
> * LeavingSingleFailureTest
> Some of the error message I see in these tests are e.g.
> {code:java}
> java.lang.RuntimeException: java.lang.IllegalStateException: Can't load
> org.apache.cassandra.utils.concurrent.Ref$OnLeak. Instance class loader is
> already closed.
> {code}
> On repeated run, these tests pass.
--
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-analytics) branch trunk updated: CASSANDRA-19285 Fix flaky Host replacement tests and shrink tests
This is an automated email from the ASF dual-hosted git repository.
ycai pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra-analytics.git
The following commit(s) were added to refs/heads/trunk by this push:
new c3e8803 CASSANDRA-19285 Fix flaky Host replacement tests and shrink
tests
c3e8803 is described below
commit c3e8803b3331bc7ef81797ac52a8417524f67edc
Author: Yifan Cai
AuthorDate: Tue Feb 13 09:52:57 2024 -0800
CASSANDRA-19285 Fix flaky Host replacement tests and shrink tests
The flakiness is caused by inspecting a class whose classloader is already
closed. The fix is to include the those classes in the sharedClassLoader, so
that the classLoader is not closed during the test.
patch by Yifan Cai; reviewed by Francisco Guerrero for CASSANDRA-19285
---
.../spark/bulkwriter/SidecarDataTransferApi.java | 3 +-
.../testing/JvmDTestSharedClassesPredicate.java| 47 ++
.../cassandra/testing/CassandraTestTemplate.java | 2 +
.../cassandra/analytics/BulkWriteTtlTest.java | 2 +
.../analytics/QuoteIdentifiersReadTest.java| 2 +
.../analytics/QuoteIdentifiersWriteTest.java | 2 +
.../cassandra/analytics/ResiliencyTestBase.java| 4 +-
.../analytics/data/ClearSnapshotTest.java | 2 +
8 files changed, 62 insertions(+), 2 deletions(-)
diff --git
a/cassandra-analytics-core/src/main/java/org/apache/cassandra/spark/bulkwriter/SidecarDataTransferApi.java
b/cassandra-analytics-core/src/main/java/org/apache/cassandra/spark/bulkwriter/SidecarDataTransferApi.java
index 6ddba7a..b6a492b 100644
---
a/cassandra-analytics-core/src/main/java/org/apache/cassandra/spark/bulkwriter/SidecarDataTransferApi.java
+++
b/cassandra-analytics-core/src/main/java/org/apache/cassandra/spark/bulkwriter/SidecarDataTransferApi.java
@@ -31,6 +31,7 @@ import org.apache.cassandra.bridge.CassandraBridge;
import org.apache.cassandra.sidecar.client.SidecarClient;
import org.apache.cassandra.sidecar.client.SidecarInstanceImpl;
import org.apache.cassandra.sidecar.client.request.ImportSSTableRequest;
+import org.apache.cassandra.sidecar.common.data.MD5Digest;
import org.apache.cassandra.sidecar.common.data.SSTableImportResponse;
import org.apache.cassandra.spark.common.MD5Hash;
import org.apache.cassandra.spark.common.client.ClientException;
@@ -79,7 +80,7 @@ public class SidecarDataTransferApi implements DataTransferApi
maybeQuotedIdentifier(bridge,
conf.quoteIdentifiers, conf.table),
uploadId,
componentName,
- fileHash.toString(),
+ new
MD5Digest(fileHash.toString()),
componentFile.toAbsolutePath().toString())
.get();
}
diff --git
a/cassandra-analytics-integration-framework/src/main/java/org/apache/cassandra/sidecar/testing/JvmDTestSharedClassesPredicate.java
b/cassandra-analytics-integration-framework/src/main/java/org/apache/cassandra/sidecar/testing/JvmDTestSharedClassesPredicate.java
new file mode 100644
index 000..d4772d0
--- /dev/null
+++
b/cassandra-analytics-integration-framework/src/main/java/org/apache/cassandra/sidecar/testing/JvmDTestSharedClassesPredicate.java
@@ -0,0 +1,47 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.cassandra.sidecar.testing;
+
+import java.util.function.Predicate;
+
+import org.apache.cassandra.distributed.impl.AbstractCluster;
+
+/**
+ * Predicate to instruct the JVM DTest framework on the classes should be
loaded by the shared classloader.
+ */
+public class JvmDTestSharedClassesPredicate implements Predicate
+{
+public static final JvmDTestSharedClassesPredicate INSTANCE = new
JvmDTestSharedClassesPredicate();
+
+private static final Predicate EXTRA = className -> {
+// Those classes can be reached by Spark SizeEstimator, when it
estimates the broadcast variable.
+// In the test scenario containing cassandra instance
[jira] [Updated] (CASSANDRA-19392) deprecate dual ports support (native_transport_port_ssl)
[ https://issues.apache.org/jira/browse/CASSANDRA-19392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-19392: - Reviewers: Abe Ratnofsky, Brandon Williams (was: Abe Ratnofsky) > deprecate dual ports support (native_transport_port_ssl) > - > > Key: CASSANDRA-19392 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19392 > Project: Cassandra > Issue Type: Task > Components: Legacy/Core >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 5.0-beta > > Time Spent: 1h 40m > Remaining Estimate: 0h > > We decided (1) to deprecate dual ports support in 5.0 (and eventually remove > it in trunk). This ticket will track the work towards the deprecation for 5.0. > (1) https://lists.apache.org/thread/dow196gspwgp2og576zh3lotvt6mc3lv -- 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-19392) deprecate dual ports support (native_transport_port_ssl)
[ https://issues.apache.org/jira/browse/CASSANDRA-19392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17817166#comment-17817166 ] Stefan Miklosovic commented on CASSANDRA-19392: --- OK I think we are done, I ll just run quick pre-commit tests tomorrow for this. > deprecate dual ports support (native_transport_port_ssl) > - > > Key: CASSANDRA-19392 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19392 > Project: Cassandra > Issue Type: Task > Components: Legacy/Core >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 5.0-beta > > Time Spent: 1h 40m > Remaining Estimate: 0h > > We decided (1) to deprecate dual ports support in 5.0 (and eventually remove > it in trunk). This ticket will track the work towards the deprecation for 5.0. > (1) https://lists.apache.org/thread/dow196gspwgp2og576zh3lotvt6mc3lv -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRASC-104) Relocate Sidecar common classes in vertx-client-shaded
[
https://issues.apache.org/jira/browse/CASSANDRASC-104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francisco Guerrero updated CASSANDRASC-104:
---
Authors: Francisco Guerrero
Test and Documentation Plan: No tests added to the patch
Status: Patch Available (was: In Progress)
PR: https://github.com/apache/cassandra-sidecar/pull/100
CI:
https://app.circleci.com/pipelines/github/frankgh/cassandra-sidecar/454/workflows/d896132d-43e1-45e8-b935-79903c0e35b6
> Relocate Sidecar common classes in vertx-client-shaded
> --
>
> Key: CASSANDRASC-104
> URL: https://issues.apache.org/jira/browse/CASSANDRASC-104
> Project: Sidecar for Apache Cassandra
> Issue Type: Improvement
> Components: Configuration
>Reporter: Francisco Guerrero
>Assignee: Francisco Guerrero
>Priority: Normal
> Labels: pull-request-available
>
> It is desirable to relocate the common classes
> {{org.apache.cassandra.sidecar.common.*}} in the {{vertx-client-shaded}}
> subproject. The benefits are the following:
> - Better isolation of the shared classes when loading them in downstream
> projects (i.e Analytics)
> - Avoids having two classes loaded in the same classpath, but with different
> internal definition (for example when annotations are relocated but the class
> itself is not)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19392) deprecate dual ports support (native_transport_port_ssl)
[ https://issues.apache.org/jira/browse/CASSANDRA-19392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17817158#comment-17817158 ] Abe Ratnofsky commented on CASSANDRA-19392: --- +1, just left some feedback on wording > deprecate dual ports support (native_transport_port_ssl) > - > > Key: CASSANDRA-19392 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19392 > Project: Cassandra > Issue Type: Task > Components: Legacy/Core >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 5.0-beta > > Time Spent: 20m > Remaining Estimate: 0h > > We decided (1) to deprecate dual ports support in 5.0 (and eventually remove > it in trunk). This ticket will track the work towards the deprecation for 5.0. > (1) https://lists.apache.org/thread/dow196gspwgp2og576zh3lotvt6mc3lv -- 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-19285) Flaky Host replacement tests and shrink tests (Instance class loader is already closed)
[
https://issues.apache.org/jira/browse/CASSANDRA-19285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17817157#comment-17817157
]
Yifan Cai commented on CASSANDRA-19285:
---
Reverted the CI config and the full test set is also green
https://app.circleci.com/pipelines/github/yifan-c/cassandra-analytics/29/workflows/186e499f-4043-42a5-81be-4f4fb8ab1a50
> Flaky Host replacement tests and shrink tests (Instance class loader is
> already closed)
> ---
>
> Key: CASSANDRA-19285
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19285
> Project: Cassandra
> Issue Type: Bug
> Components: Analytics Library
>Reporter: Francisco Guerrero
>Assignee: Yifan Cai
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> During Circle CI runs there are some flaky integration tests, some noticed are
> * HostReplacementMultiDCTest
> * HostReplacementMultiDCFailureTest
> * HostReplacementFailureTest
> * LeavingSingleFailureTest
> Some of the error message I see in these tests are e.g.
> {code:java}
> java.lang.RuntimeException: java.lang.IllegalStateException: Can't load
> org.apache.cassandra.utils.concurrent.Ref$OnLeak. Instance class loader is
> already closed.
> {code}
> On repeated run, these tests pass.
--
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-19285) Flaky Host replacement tests and shrink tests (Instance class loader is already closed)
[
https://issues.apache.org/jira/browse/CASSANDRA-19285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francisco Guerrero updated CASSANDRA-19285:
---
Reviewers: Francisco Guerrero, Francisco Guerrero
Francisco Guerrero, Francisco Guerrero (was: Francisco Guerrero)
Status: Review In Progress (was: Patch Available)
> Flaky Host replacement tests and shrink tests (Instance class loader is
> already closed)
> ---
>
> Key: CASSANDRA-19285
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19285
> Project: Cassandra
> Issue Type: Bug
> Components: Analytics Library
>Reporter: Francisco Guerrero
>Assignee: Yifan Cai
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> During Circle CI runs there are some flaky integration tests, some noticed are
> * HostReplacementMultiDCTest
> * HostReplacementMultiDCFailureTest
> * HostReplacementFailureTest
> * LeavingSingleFailureTest
> Some of the error message I see in these tests are e.g.
> {code:java}
> java.lang.RuntimeException: java.lang.IllegalStateException: Can't load
> org.apache.cassandra.utils.concurrent.Ref$OnLeak. Instance class loader is
> already closed.
> {code}
> On repeated run, these tests pass.
--
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-19285) Flaky Host replacement tests and shrink tests (Instance class loader is already closed)
[
https://issues.apache.org/jira/browse/CASSANDRA-19285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17817153#comment-17817153
]
Francisco Guerrero commented on CASSANDRA-19285:
+1 (waiting on final CI results). Repeated tests are looking good! Thanks again
> Flaky Host replacement tests and shrink tests (Instance class loader is
> already closed)
> ---
>
> Key: CASSANDRA-19285
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19285
> Project: Cassandra
> Issue Type: Bug
> Components: Analytics Library
>Reporter: Francisco Guerrero
>Assignee: Yifan Cai
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> During Circle CI runs there are some flaky integration tests, some noticed are
> * HostReplacementMultiDCTest
> * HostReplacementMultiDCFailureTest
> * HostReplacementFailureTest
> * LeavingSingleFailureTest
> Some of the error message I see in these tests are e.g.
> {code:java}
> java.lang.RuntimeException: java.lang.IllegalStateException: Can't load
> org.apache.cassandra.utils.concurrent.Ref$OnLeak. Instance class loader is
> already closed.
> {code}
> On repeated run, these tests pass.
--
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-18940) SAI post-filtering reads don't update local table latency metrics
[ https://issues.apache.org/jira/browse/CASSANDRA-18940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Rackliffe updated CASSANDRA-18940: Fix Version/s: 5.0.x (was: 5.0-rc) > SAI post-filtering reads don't update local table latency metrics > - > > Key: CASSANDRA-18940 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18940 > Project: Cassandra > Issue Type: Bug > Components: Feature/2i Index, Feature/SAI, Observability/Metrics >Reporter: Caleb Rackliffe >Assignee: Mike Adamson >Priority: Normal > Fix For: 5.0.x, 5.x > > Attachments: > draft_fix_for_SAI_post-filtering_reads_not_updating_local_table_metrics.patch > > > Once an SAI index finds matches (primary keys), it reads the associated rows > and post-filters them to incorporate partial writes, tombstones, etc. > However, those reads are not currently updating the local table latency > metrics. It should be simple enough to attach a metrics recording > transformation to the iterator produced by querying local storage. (I've > attached a patch that should apply cleanly to trunk, but there may be a > better way...) -- 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-18940) SAI post-filtering reads don't update local table latency metrics
[
https://issues.apache.org/jira/browse/CASSANDRA-18940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17817149#comment-17817149
]
Caleb Rackliffe commented on CASSANDRA-18940:
-
The basic thing we want to do here is fire latency measurements for the
post-filtering reads SAI does in {{QueryController}} to {{TableQueryMetrics}}.
I don't really think it's a 5.0.0 blocker though, even if I'd like to get it in
there once CASSANDRA-19018 (which is a 5.0 blocker) wraps up.
> SAI post-filtering reads don't update local table latency metrics
> -
>
> Key: CASSANDRA-18940
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18940
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/2i Index, Feature/SAI, Observability/Metrics
>Reporter: Caleb Rackliffe
>Assignee: Mike Adamson
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
> Attachments:
> draft_fix_for_SAI_post-filtering_reads_not_updating_local_table_metrics.patch
>
>
> Once an SAI index finds matches (primary keys), it reads the associated rows
> and post-filters them to incorporate partial writes, tombstones, etc.
> However, those reads are not currently updating the local table latency
> metrics. It should be simple enough to attach a metrics recording
> transformation to the iterator produced by querying local storage. (I've
> attached a patch that should apply cleanly to trunk, but there may be a
> better way...)
--
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-19285) Flaky Host replacement tests and shrink tests (Instance class loader is already closed)
[
https://issues.apache.org/jira/browse/CASSANDRA-19285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17817148#comment-17817148
]
Yifan Cai commented on CASSANDRA-19285:
---
CI (for repeated test) is green
> Flaky Host replacement tests and shrink tests (Instance class loader is
> already closed)
> ---
>
> Key: CASSANDRA-19285
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19285
> Project: Cassandra
> Issue Type: Bug
> Components: Analytics Library
>Reporter: Francisco Guerrero
>Assignee: Yifan Cai
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> During Circle CI runs there are some flaky integration tests, some noticed are
> * HostReplacementMultiDCTest
> * HostReplacementMultiDCFailureTest
> * HostReplacementFailureTest
> * LeavingSingleFailureTest
> Some of the error message I see in these tests are e.g.
> {code:java}
> java.lang.RuntimeException: java.lang.IllegalStateException: Can't load
> org.apache.cassandra.utils.concurrent.Ref$OnLeak. Instance class loader is
> already closed.
> {code}
> On repeated run, these tests pass.
--
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-19392) deprecate dual ports support (native_transport_port_ssl)
[ https://issues.apache.org/jira/browse/CASSANDRA-19392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abe Ratnofsky updated CASSANDRA-19392: -- Reviewers: Abe Ratnofsky Status: Review In Progress (was: Needs Committer) > deprecate dual ports support (native_transport_port_ssl) > - > > Key: CASSANDRA-19392 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19392 > Project: Cassandra > Issue Type: Task > Components: Legacy/Core >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 5.0-beta > > Time Spent: 10m > Remaining Estimate: 0h > > We decided (1) to deprecate dual ports support in 5.0 (and eventually remove > it in trunk). This ticket will track the work towards the deprecation for 5.0. > (1) https://lists.apache.org/thread/dow196gspwgp2og576zh3lotvt6mc3lv -- 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-19392) deprecate dual ports support (native_transport_port_ssl)
[ https://issues.apache.org/jira/browse/CASSANDRA-19392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17817145#comment-17817145 ] Stefan Miklosovic commented on CASSANDRA-19392: --- [~aratnofsky] anything to add / change to the PR above? > deprecate dual ports support (native_transport_port_ssl) > - > > Key: CASSANDRA-19392 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19392 > Project: Cassandra > Issue Type: Task > Components: Legacy/Core >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 5.0-beta > > Time Spent: 10m > Remaining Estimate: 0h > > We decided (1) to deprecate dual ports support in 5.0 (and eventually remove > it in trunk). This ticket will track the work towards the deprecation for 5.0. > (1) https://lists.apache.org/thread/dow196gspwgp2og576zh3lotvt6mc3lv -- 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-19043) RepairJobTest fails with paxos_variant: v2
[
https://issues.apache.org/jira/browse/CASSANDRA-19043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-19043:
-
Fix Version/s: 5.0.x
(was: 5.0-rc)
> RepairJobTest fails with paxos_variant: v2
> --
>
> Key: CASSANDRA-19043
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19043
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Repair, Feature/Lightweight Transactions
>Reporter: Branimir Lambov
>Priority: Normal
> Fix For: 4.1.x, 5.0.x
>
>
> {{testEndToEndNoDifferences}} and {{testValidationFailure}} time out. The
> paxos repair stage never completes --- it's does not appear to be properly
> wired up (e.g. {{outboundSink}} returns before processing the PAXOS2-specific
> cases).
> This happens for all three options of {{paxos_state_purging}} and both with
> and without {{storage_compatibility_mode: NONE}}.
--
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-18940) SAI post-filtering reads don't update local table latency metrics
[ https://issues.apache.org/jira/browse/CASSANDRA-18940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17817133#comment-17817133 ] Ekaterina Dimitrova commented on CASSANDRA-18940: - Any thoughts what we do with this one? It is marked 5.0 blocker > SAI post-filtering reads don't update local table latency metrics > - > > Key: CASSANDRA-18940 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18940 > Project: Cassandra > Issue Type: Bug > Components: Feature/2i Index, Feature/SAI, Observability/Metrics >Reporter: Caleb Rackliffe >Assignee: Mike Adamson >Priority: Normal > Fix For: 5.0-rc, 5.x > > Attachments: > draft_fix_for_SAI_post-filtering_reads_not_updating_local_table_metrics.patch > > > Once an SAI index finds matches (primary keys), it reads the associated rows > and post-filters them to incorporate partial writes, tombstones, etc. > However, those reads are not currently updating the local table latency > metrics. It should be simple enough to attach a metrics recording > transformation to the iterator produced by querying local storage. (I've > attached a patch that should apply cleanly to trunk, but there may be a > better way...) -- 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-19043) RepairJobTest fails with paxos_variant: v2
[
https://issues.apache.org/jira/browse/CASSANDRA-19043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17817129#comment-17817129
]
Ekaterina Dimitrova edited comment on CASSANDRA-19043 at 2/13/24 8:02 PM:
--
[~dcapwell] , am I right in saying we hit the problem you describe in
CASSANDRA-19042 here? Repair does not finish:
{code:java}
java.util.concurrent.TimeoutException
at
org.apache.cassandra.utils.concurrent.AbstractFuture.get(AbstractFuture.java:253)
at
org.apache.cassandra.repair.RepairJobTest.testValidationFailure(RepairJobTest.java:332)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
at
com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:69)
at
com.intellij.rt.junit.IdeaTestRunner$Repeater$1.execute(IdeaTestRunner.java:38)
at
com.intellij.rt.execution.junit.TestsRepeater.repeat(TestsRepeater.java:11)
at
com.intellij.rt.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:35)
at
com.intellij.rt.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:232)
at com.intellij.rt.junit.JUnitStarter.main(JUnitStarter.java:55){code}
was (Author: e.dimitrova):
[~dcapwell] , am I right by saying that here we hit the problem you describe in
CASSANDRA-19042?
> RepairJobTest fails with paxos_variant: v2
> --
>
> Key: CASSANDRA-19043
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19043
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Repair, Feature/Lightweight Transactions
>Reporter: Branimir Lambov
>Priority: Normal
> Fix For: 4.1.x, 5.0-rc
>
>
> {{testEndToEndNoDifferences}} and {{testValidationFailure}} time out. The
> paxos repair stage never completes --- it's does not appear to be properly
> wired up (e.g. {{outboundSink}} returns before processing the PAXOS2-specific
> cases).
> This happens for all three options of {{paxos_state_purging}} and both with
> and without {{storage_compatibility_mode: NONE}}.
--
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-19216) CMS: Additional nodes are not added to CMS
[
https://issues.apache.org/jira/browse/CASSANDRA-19216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-19216:
--
Status: Ready to Commit (was: Review In Progress)
> CMS: Additional nodes are not added to CMS
> --
>
> Key: CASSANDRA-19216
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19216
> Project: Cassandra
> Issue Type: Bug
> Components: Transactional Cluster Metadata
>Reporter: Paul Chandler
>Assignee: Marcus Eriksson
>Priority: Normal
> Fix For: 5.1-alpha1
>
> Attachments: ci_summary.html, result_details.tar.gz
>
>
> When creating a 3 node cluster on a local machine using 3 loopback addresses
> 127.0.0.1
> 127.0.0.2
> 127.0.0.3
> The nodes are created correctly and the first node is assigned as a CMS node
> as shown:
> {{bin/nodetool p 7199 status{-}{-}}}
> {{{}Datacenter:
> datacenter1{}}}{{{}==={}}}{{{}Status=Up/Down{}}}{{{}|/
> State=Normal/Leaving/Joining/Moving{}}}{{{}- Address Load Tokens
> Owns (effective) Host ID Rack{}}}
> {{UN 127.0.0.3 75.55 KiB 16 76.0%
> 6d194555-f6eb-41d0-c000-0003 rack1}}
> {{UN 127.0.0.2 67.97 KiB 16 59.3%
> 6d194555-f6eb-41d0-c000-0002 rack1}}
> {{UN 127.0.0.1 81 KiB 16 64.7%
> 6d194555-f6eb-41d0-c000-0001 rack1}}
> {{bin/nodetool -p 7199 describecms}}
> {{Cluster Metadata Service:}}
> {{Members: /127.0.0.1:7000}}
> {{Is Member: true}}
> {{Service State: LOCAL}}
> {{Is Migrating: false}}
> {{Epoch: 14}}
> {{Local Pending Count: 0}}
> {{Commits Paused: false}}
> {{{}Replication factor:
> ReplicationParams{class=org.apache.cassandra.locator.MetaStrategy,
> datacenter1=1{
> {{However after doing a reconfigurecms to create a replication factor of 3,
> it seems that there is still only one member of cms.}}
> {{bin/nodetool -p 7199 reconfigurecms datacenter1:3}}
> {{bin/nodetool -p 7199 describecms}}
> {{Cluster Metadata Service:}}
> {{Members: /127.0.0.1:7000}}
> {{Is Member: true}}
> {{Service State: LOCAL}}
> Is Migrating: false
> Epoch: 16
> Local Pending Count: 0
> Commits Paused: false
> Replication factor:
> ReplicationParams\{class=org.apache.cassandra.locator.MetaStrategy,
> datacenter1=3}
> Is this correct, should all 3 nodes be shown in the Members section ?
--
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-19216) CMS: Additional nodes are not added to CMS
[
https://issues.apache.org/jira/browse/CASSANDRA-19216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17817113#comment-17817113
]
Stefan Miklosovic edited comment on CASSANDRA-19216 at 2/13/24 6:55 PM:
*CASSANDRA-19216-trunk*
{noformat}
java17_pre-commit_tests
✓ j17_build4m 36s
✓ j17_cqlsh_dtests_py311_vnode 7m 0s
✓ j17_cqlsh_dtests_py387m 24s
✓ j17_cqlsh_dtests_py38_vnode 6m 59s
✓ j17_cqlshlib_cython_tests7m 37s
✓ j17_cqlshlib_tests 6m 34s
✓ j17_dtests 35m 48s
✓ j17_jvm_dtests_repeat0m 44s
✓ j17_jvm_dtests_vnode_repeat 0m 41s
✕ j17_cqlsh_dtests_py311 7m 21s
✕ j17_dtests_vnode 36m 5s
client_request_metrics_local_remote_test.TestClientRequestMetricsLocalRemote
test_write_and_read (1)
✕ j17_jvm_dtests 27m 47s
✕ j17_jvm_dtests_vnode21m 14s
junit.framework.TestSuite
org.apache.cassandra.fuzz.harry.integration.model.InJVMTokenAwareExecutorTest
TIMEOUTED (2)
org.apache.cassandra.distributed.test.log.BounceIndexRebuildTest
bounceTest (3)
org.apache.cassandra.distributed.test.NativeTransportEncryptionOptionsTest
testEndpointVerificationEnabledIpNotInSAN (4)
✕ j17_unit_tests 14m 27s
org.apache.cassandra.index.sai.cql.VectorUpdateDeleteTest updateTest (5)
✕ j17_utests_oa 13m 12s
org.apache.cassandra.net.ConnectionTest testTimeout (6)
org.apache.cassandra.index.sai.cql.VectorUpdateDeleteTest updateTest (7)
java17_separate_tests
java11_pre-commit_tests
java11_separate_tests
{noformat}
[java17_pre-commit_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/3855/workflows/7f1d89d8-eef0-4e3c-9ea6-9329056b142e]
[java17_separate_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/3855/workflows/d9c9516a-51de-4ce5-a6f5-dce8adf14f0b]
[java11_pre-commit_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/3855/workflows/38780648-8957-4f98-8294-cf97f0a488fc]
[java11_separate_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/3855/workflows/12ddd014-1926-4a1a-9a0a-bdb50ffbffe4]
(1) just flaky, it passes for j17_dtests
(2) this passes locally, probably just flaky
(3) does pass locally, I will create a ticket for this one, it just does not
wait for an index to be built
(4) CASSANDRA-19281
(5) CASSANDRA-19168
(6) CASSANDRA-16677
(7) CASSANDRA-19168
I have also run mutliplexer for these tests (500x each)
TriggeredReconfigureCMSTest
https://app.circleci.com/pipelines/github/instaclustr/cassandra/3853/workflows/2b4035d1-754e-4291-b145-a794f697798e/jobs/189543
ReconfigureCMSTest
https://app.circleci.com/pipelines/github/instaclustr/cassandra/3854/workflows/f08947f8-2ca5-425b-b48d-eb3e31679c22/jobs/189645
was (Author: smiklosovic):
*CASSANDRA-19216-trunk*
{noformat}
java17_pre-commit_tests
✓ j17_build4m 36s
✓ j17_cqlsh_dtests_py311_vnode 7m 0s
✓ j17_cqlsh_dtests_py387m 24s
✓ j17_cqlsh_dtests_py38_vnode 6m 59s
✓ j17_cqlshlib_cython_tests7m 37s
✓ j17_cqlshlib_tests 6m 34s
✓ j17_dtests 35m 48s
✓ j17_jvm_dtests_repeat0m 44s
✓ j17_jvm_dtests_vnode_repeat 0m 41s
✕ j17_cqlsh_dtests_py311 7m 21s
✕ j17_dtests_vnode 36m 5s
client_request_metrics_local_remote_test.TestClientRequestMetricsLocalRemote
test_write_and_read (1)
✕ j17_jvm_dtests 27m 47s
✕ j17_jvm_dtests_vnode21m 14s
junit.framework.TestSuite
org.apache.cassandra.fuzz.harry.integration.model.InJVMTokenAwareExecutorTest
TIMEOUTED (2)
org.apache.cassandra.distributed.test.log.BounceIndexRebuildTest
bounceTest (3)
org.apache.cassandra.distributed.test.NativeTransportEncryptionOptionsTest
testEndpointVerificationEnabledIpNotInSAN (4)
✕ j17_unit_tests 14m 27s
org.apache.cassandra.index.sai.cql.VectorUpdateDeleteTest updateTest (5)
✕ j17_utests_oa 13m 12s
org.apache.cassandra.net.ConnectionTest testTimeout (6)
[jira] [Comment Edited] (CASSANDRA-19216) CMS: Additional nodes are not added to CMS
[
https://issues.apache.org/jira/browse/CASSANDRA-19216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17817113#comment-17817113
]
Stefan Miklosovic edited comment on CASSANDRA-19216 at 2/13/24 6:53 PM:
*CASSANDRA-19216-trunk*
{noformat}
java17_pre-commit_tests
✓ j17_build4m 36s
✓ j17_cqlsh_dtests_py311_vnode 7m 0s
✓ j17_cqlsh_dtests_py387m 24s
✓ j17_cqlsh_dtests_py38_vnode 6m 59s
✓ j17_cqlshlib_cython_tests7m 37s
✓ j17_cqlshlib_tests 6m 34s
✓ j17_dtests 35m 48s
✓ j17_jvm_dtests_repeat0m 44s
✓ j17_jvm_dtests_vnode_repeat 0m 41s
✕ j17_cqlsh_dtests_py311 7m 21s
✕ j17_dtests_vnode 36m 5s
client_request_metrics_local_remote_test.TestClientRequestMetricsLocalRemote
test_write_and_read (1)
✕ j17_jvm_dtests 27m 47s
✕ j17_jvm_dtests_vnode21m 14s
junit.framework.TestSuite
org.apache.cassandra.fuzz.harry.integration.model.InJVMTokenAwareExecutorTest
TIMEOUTED (2)
org.apache.cassandra.distributed.test.log.BounceIndexRebuildTest
bounceTest (3)
org.apache.cassandra.distributed.test.NativeTransportEncryptionOptionsTest
testEndpointVerificationEnabledIpNotInSAN (4)
✕ j17_unit_tests 14m 27s
org.apache.cassandra.index.sai.cql.VectorUpdateDeleteTest updateTest (5)
✕ j17_utests_oa 13m 12s
org.apache.cassandra.net.ConnectionTest testTimeout (6)
org.apache.cassandra.index.sai.cql.VectorUpdateDeleteTest updateTest (7)
java17_separate_tests
java11_pre-commit_tests
java11_separate_tests
{noformat}
[java17_pre-commit_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/3855/workflows/7f1d89d8-eef0-4e3c-9ea6-9329056b142e]
[java17_separate_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/3855/workflows/d9c9516a-51de-4ce5-a6f5-dce8adf14f0b]
[java11_pre-commit_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/3855/workflows/38780648-8957-4f98-8294-cf97f0a488fc]
[java11_separate_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/3855/workflows/12ddd014-1926-4a1a-9a0a-bdb50ffbffe4]
(1) todo
(2) this passes locally, probably just flaky
(3) does pass locally, I will create a ticket for this one, it just does not
wait for an index to be built
(4) CASSANDRA-19281
(5) CASSANDRA-19168
(6) CASSANDRA-16677
(7) CASSANDRA-19168
was (Author: smiklosovic):
*CASSANDRA-19216-trunk*
{noformat}
java17_pre-commit_tests
✓ j17_build4m 36s
✓ j17_cqlsh_dtests_py311_vnode 7m 0s
✓ j17_cqlsh_dtests_py387m 24s
✓ j17_cqlsh_dtests_py38_vnode 6m 59s
✓ j17_cqlshlib_cython_tests7m 37s
✓ j17_cqlshlib_tests 6m 34s
✓ j17_dtests 35m 48s
✓ j17_jvm_dtests_repeat0m 44s
✓ j17_jvm_dtests_vnode_repeat 0m 41s
✕ j17_cqlsh_dtests_py311 7m 21s
✕ j17_dtests_vnode 36m 5s
client_request_metrics_local_remote_test.TestClientRequestMetricsLocalRemote
test_write_and_read (1)
✕ j17_jvm_dtests 27m 47s
✕ j17_jvm_dtests_vnode21m 14s
junit.framework.TestSuite
org.apache.cassandra.fuzz.harry.integration.model.InJVMTokenAwareExecutorTest
TIMEOUTED (2)
org.apache.cassandra.distributed.test.log.BounceIndexRebuildTest
bounceTest (3)
org.apache.cassandra.distributed.test.NativeTransportEncryptionOptionsTest
testEndpointVerificationEnabledIpNotInSAN (4)
✕ j17_unit_tests 14m 27s
org.apache.cassandra.index.sai.cql.VectorUpdateDeleteTest updateTest (5)
✕ j17_utests_oa 13m 12s
org.apache.cassandra.net.ConnectionTest testTimeout (6)
org.apache.cassandra.index.sai.cql.VectorUpdateDeleteTest updateTest (7)
java17_separate_tests
java11_pre-commit_tests
java11_separate_tests
{noformat}
[java17_pre-commit_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/3855/workflows/7f1d89d8-eef0-4e3c-9ea6-9329056b142e]
[jira] [Comment Edited] (CASSANDRA-19216) CMS: Additional nodes are not added to CMS
[
https://issues.apache.org/jira/browse/CASSANDRA-19216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17817113#comment-17817113
]
Stefan Miklosovic edited comment on CASSANDRA-19216 at 2/13/24 6:53 PM:
*CASSANDRA-19216-trunk*
{noformat}
java17_pre-commit_tests
✓ j17_build4m 36s
✓ j17_cqlsh_dtests_py311_vnode 7m 0s
✓ j17_cqlsh_dtests_py387m 24s
✓ j17_cqlsh_dtests_py38_vnode 6m 59s
✓ j17_cqlshlib_cython_tests7m 37s
✓ j17_cqlshlib_tests 6m 34s
✓ j17_dtests 35m 48s
✓ j17_jvm_dtests_repeat0m 44s
✓ j17_jvm_dtests_vnode_repeat 0m 41s
✕ j17_cqlsh_dtests_py311 7m 21s
✕ j17_dtests_vnode 36m 5s
client_request_metrics_local_remote_test.TestClientRequestMetricsLocalRemote
test_write_and_read (1)
✕ j17_jvm_dtests 27m 47s
✕ j17_jvm_dtests_vnode21m 14s
junit.framework.TestSuite
org.apache.cassandra.fuzz.harry.integration.model.InJVMTokenAwareExecutorTest
TIMEOUTED (2)
org.apache.cassandra.distributed.test.log.BounceIndexRebuildTest
bounceTest (3)
org.apache.cassandra.distributed.test.NativeTransportEncryptionOptionsTest
testEndpointVerificationEnabledIpNotInSAN (4)
✕ j17_unit_tests 14m 27s
org.apache.cassandra.index.sai.cql.VectorUpdateDeleteTest updateTest (5)
✕ j17_utests_oa 13m 12s
org.apache.cassandra.net.ConnectionTest testTimeout (6)
org.apache.cassandra.index.sai.cql.VectorUpdateDeleteTest updateTest (7)
java17_separate_tests
java11_pre-commit_tests
java11_separate_tests
{noformat}
[java17_pre-commit_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/3855/workflows/7f1d89d8-eef0-4e3c-9ea6-9329056b142e]
[java17_separate_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/3855/workflows/d9c9516a-51de-4ce5-a6f5-dce8adf14f0b]
[java11_pre-commit_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/3855/workflows/38780648-8957-4f98-8294-cf97f0a488fc]
[java11_separate_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/3855/workflows/12ddd014-1926-4a1a-9a0a-bdb50ffbffe4]
(1) todo
(2) this pass locally, probably just flaky
(3) does pass locally, I will create a ticket for this one, it just does not
wait for an index to be built
(4) CASSANDRA-19281
(5) CASSANDRA-19168
(6) CASSANDRA-16677
(7) CASSANDRA-19168
was (Author: smiklosovic):
*CASSANDRA-19216-trunk*
{noformat}
java17_pre-commit_tests
✓ j17_build4m 36s
✓ j17_cqlsh_dtests_py311_vnode 7m 0s
✓ j17_cqlsh_dtests_py387m 24s
✓ j17_cqlsh_dtests_py38_vnode 6m 59s
✓ j17_cqlshlib_cython_tests7m 37s
✓ j17_cqlshlib_tests 6m 34s
✓ j17_dtests 35m 48s
✓ j17_jvm_dtests_repeat0m 44s
✓ j17_jvm_dtests_vnode_repeat 0m 41s
✕ j17_cqlsh_dtests_py311 7m 21s
✕ j17_dtests_vnode 36m 5s
client_request_metrics_local_remote_test.TestClientRequestMetricsLocalRemote
test_write_and_read (1)
✕ j17_jvm_dtests 27m 47s
✕ j17_jvm_dtests_vnode21m 14s
junit.framework.TestSuite
org.apache.cassandra.fuzz.harry.integration.model.InJVMTokenAwareExecutorTest
TIMEOUTED (2)
org.apache.cassandra.distributed.test.log.BounceIndexRebuildTest
bounceTest (3)
org.apache.cassandra.distributed.test.NativeTransportEncryptionOptionsTest
testEndpointVerificationEnabledIpNotInSAN (4)
✕ j17_unit_tests 14m 27s
org.apache.cassandra.index.sai.cql.VectorUpdateDeleteTest updateTest (5)
✕ j17_utests_oa 13m 12s
org.apache.cassandra.net.ConnectionTest testTimeout (6)
org.apache.cassandra.index.sai.cql.VectorUpdateDeleteTest updateTest (7)
java17_separate_tests
java11_pre-commit_tests
java11_separate_tests
{noformat}
[java17_pre-commit_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/3855/workflows/7f1d89d8-eef0-4e3c-9ea6-9329056b142e]
[jira] [Commented] (CASSANDRA-19216) CMS: Additional nodes are not added to CMS
[
https://issues.apache.org/jira/browse/CASSANDRA-19216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17817113#comment-17817113
]
Stefan Miklosovic commented on CASSANDRA-19216:
---
*CASSANDRA-19216-trunk*
{noformat}
java17_pre-commit_tests
✓ j17_build4m 36s
✓ j17_cqlsh_dtests_py311_vnode 7m 0s
✓ j17_cqlsh_dtests_py387m 24s
✓ j17_cqlsh_dtests_py38_vnode 6m 59s
✓ j17_cqlshlib_cython_tests7m 37s
✓ j17_cqlshlib_tests 6m 34s
✓ j17_dtests 35m 48s
✓ j17_jvm_dtests_repeat0m 44s
✓ j17_jvm_dtests_vnode_repeat 0m 41s
✕ j17_cqlsh_dtests_py311 7m 21s
✕ j17_dtests_vnode 36m 5s
client_request_metrics_local_remote_test.TestClientRequestMetricsLocalRemote
test_write_and_read (1)
✕ j17_jvm_dtests 27m 47s
✕ j17_jvm_dtests_vnode21m 14s
junit.framework.TestSuite
org.apache.cassandra.fuzz.harry.integration.model.InJVMTokenAwareExecutorTest
TIMEOUTED (2)
org.apache.cassandra.distributed.test.log.BounceIndexRebuildTest
bounceTest (3)
org.apache.cassandra.distributed.test.NativeTransportEncryptionOptionsTest
testEndpointVerificationEnabledIpNotInSAN (4)
✕ j17_unit_tests 14m 27s
org.apache.cassandra.index.sai.cql.VectorUpdateDeleteTest updateTest (5)
✕ j17_utests_oa 13m 12s
org.apache.cassandra.net.ConnectionTest testTimeout (6)
org.apache.cassandra.index.sai.cql.VectorUpdateDeleteTest updateTest (7)
java17_separate_tests
java11_pre-commit_tests
java11_separate_tests
{noformat}
[java17_pre-commit_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/3855/workflows/7f1d89d8-eef0-4e3c-9ea6-9329056b142e]
[java17_separate_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/3855/workflows/d9c9516a-51de-4ce5-a6f5-dce8adf14f0b]
[java11_pre-commit_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/3855/workflows/38780648-8957-4f98-8294-cf97f0a488fc]
[java11_separate_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/3855/workflows/12ddd014-1926-4a1a-9a0a-bdb50ffbffe4]
(1)
(1)
(1)
(1)
(1)
(1)
> CMS: Additional nodes are not added to CMS
> --
>
> Key: CASSANDRA-19216
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19216
> Project: Cassandra
> Issue Type: Bug
> Components: Transactional Cluster Metadata
>Reporter: Paul Chandler
>Assignee: Marcus Eriksson
>Priority: Normal
> Fix For: 5.1-alpha1
>
> Attachments: ci_summary.html, result_details.tar.gz
>
>
> When creating a 3 node cluster on a local machine using 3 loopback addresses
> 127.0.0.1
> 127.0.0.2
> 127.0.0.3
> The nodes are created correctly and the first node is assigned as a CMS node
> as shown:
> {{bin/nodetool p 7199 status{-}{-}}}
> {{{}Datacenter:
> datacenter1{}}}{{{}==={}}}{{{}Status=Up/Down{}}}{{{}|/
> State=Normal/Leaving/Joining/Moving{}}}{{{}- Address Load Tokens
> Owns (effective) Host ID Rack{}}}
> {{UN 127.0.0.3 75.55 KiB 16 76.0%
> 6d194555-f6eb-41d0-c000-0003 rack1}}
> {{UN 127.0.0.2 67.97 KiB 16 59.3%
> 6d194555-f6eb-41d0-c000-0002 rack1}}
> {{UN 127.0.0.1 81 KiB 16 64.7%
> 6d194555-f6eb-41d0-c000-0001 rack1}}
> {{bin/nodetool -p 7199 describecms}}
> {{Cluster Metadata Service:}}
> {{Members: /127.0.0.1:7000}}
> {{Is Member: true}}
> {{Service State: LOCAL}}
> {{Is Migrating: false}}
> {{Epoch: 14}}
> {{Local Pending Count: 0}}
> {{Commits Paused: false}}
> {{{}Replication factor:
> ReplicationParams{class=org.apache.cassandra.locator.MetaStrategy,
> datacenter1=1{
> {{However after doing a reconfigurecms to create a replication factor of 3,
> it seems that there is still only one member of cms.}}
> {{bin/nodetool -p 7199 reconfigurecms datacenter1:3}}
> {{bin/nodetool -p 7199 describecms}}
> {{Cluster Metadata Service:}}
> {{Members: /127.0.0.1:7000}}
> {{Is Member: true}}
> {{Service State: LOCAL}}
> Is Migrating: false
> Epoch: 16
> Local Pending Count: 0
> Commits Paused: false
> Replication factor:
> ReplicationParams\{class=org.apache.cassandra.locator.MetaStrategy,
> datacenter1=3}
> Is this correct, should all 3 nodes be shown in the Members section ?
--
This message
[jira] [Commented] (CASSANDRA-19366) Expose mode of authentication in system_views.clients, nodetool clientstats, and ClientMetrics
[
https://issues.apache.org/jira/browse/CASSANDRA-19366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17817112#comment-17817112
]
Andy Tolbert commented on CASSANDRA-19366:
--
Thank you [~smiklosovic] and [~frankgh] for all of your help in reviewing and
getting this committed!
> Expose mode of authentication in system_views.clients, nodetool clientstats,
> and ClientMetrics
> --
>
> Key: CASSANDRA-19366
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19366
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Encryption, Messaging/Client, Observability/JMX,
> Observability/Metrics, Tool/nodetool
>Reporter: Andy Tolbert
>Assignee: Andy Tolbert
>Priority: Normal
> Fix For: 5.1
>
> Attachments: CASSANDRA-19366-trunk-1_test_results-1.tgz,
> CASSANDRA-19366-trunk-1_test_results.tgz,
> CASSANDRA-19366-trunk-1_test_results_summary.html,
> CASSANDRA-19366-trunk-6_ci_summary.html
>
> Time Spent: 4h
> Remaining Estimate: 0h
>
> CASSANDRA-18554 added support for mTLS-authenticated clients. Part of this
> contribution introduced {{{}MutualTlsWithPasswordFallbackAuthenticator{}}},
> which enables Cassandra to support either password and mTLS-authenticated
> connections.
> As an operator, it would be useful to know which connections are mTLS
> authenticated, and which are password authenticated, as a possible mode of
> operation is migrating users from one from of authentication to another. It
> would also be useful to know if that if authentication attempts are failing
> which mode of authentication is unsuccessful.
> Proposing to add the following:
> * Add a {{mode: string}} and {{metadata: map}} to
> {{{}AuthenticatedUser{}}}. Update existing {{IAuthenticator}} implementations
> to pass {{mode}} (e.g. {{password}} , {{{}mtls{}}}), and optionally pass a
> {{metadata}} map (e.g. this can include the extracted {{identity}} from a
> client certificate for {{mtls}} authentication).
> * Update nodetool clientstats to add a new option flag {{{}--metadata{}}},
> which when passed exposes these new fields on {{{}AuthenticatedUser{}}}. (Not
> added to existing output to maintain compatibility, much like
> {{-client-options}} did.
> * Update {{system_views.clients}} to include columns for these new fields.
> * Add new metrics to {{{}ClientMetrics{}}}:
> ** Track authentication success and failures by mode. (Note: The metrics
> present by authentication mode scope are contextual based on the
> Authenticator used (e.g. only {{scope=Password}} will be present for
> {{{}PasswordAuthenticator{}}})
> {noformat}
> Existing:
> org.apache.cassandra.metrics:name=AuthSuccess,type=Client
> org.apache.cassandra.metrics:name=AuthFailure,type=Client
> New:
> org.apache.cassandra.metrics:name=AuthSuccess,scope=MutualTls,type=Client
> org.apache.cassandra.metrics:name=AuthSuccess,scope=Password,type=Client
> org.apache.cassandra.metrics:name=AuthFailure,scope=MutualTls,type=Client
> org.apache.cassandra.metrics:name=AuthFailure,scope=Password,type=Client
> {noformat}
> *
> ** Track connection counts by mode:
> {noformat}
> Existing:
> org.apache.cassandra.metrics:name=ConnectedNativeClients,type=Client
> org.apache.cassandra.metrics:name=connectedNativeClients,type=Client
> (previously deprecated but still maintained)
> New:
> org.apache.cassandra.metrics:name=ConnectedNativeClients,scope=MutualTls,type=Client
> org.apache.cassandra.metrics:name=ConnectedNativeClients,scope=Password,type=Client
> {noformat}
> *
> ** A metric to track encrypted vs. non-encrypted connections:
> {noformat}
> org.apache.cassandra.metrics:name=ConnectedNativeClients,scope=Encrypted,type=Client
> org.apache.cassandra.metrics:name=ConnectedNativeClients,scope=Unencrypted,type=Client
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
(cassandra-website) branch asf-staging updated (a8caf5efd -> 8a641fca7)
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 a8caf5efd generate docs for aa8a03c7 new 8a641fca7 generate docs for aa8a03c7 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 (a8caf5efd) \ N -- N -- N refs/heads/asf-staging (8a641fca7) 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: .../5.1/cassandra/managing/operating/metrics.html | 180 - .../managing/tools/nodetool/clientstats.html | 8 +- .../cassandra/managing/operating/metrics.html | 180 - .../managing/tools/nodetool/clientstats.html | 8 +- content/search-index.js| 2 +- site-ui/build/ui-bundle.zip| Bin 4883646 -> 4883646 bytes 6 files changed, 361 insertions(+), 17 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-19285) Flaky Host replacement tests and shrink tests (Instance class loader is already closed)
[
https://issues.apache.org/jira/browse/CASSANDRA-19285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17817099#comment-17817099
]
Yifan Cai edited comment on CASSANDRA-19285 at 2/13/24 6:05 PM:
PR: https://github.com/apache/cassandra-analytics/pull/39
CI (Repeat 100 times for HostReplacementMultiDCTest):
https://app.circleci.com/pipelines/github/yifan-c/cassandra-analytics?branch=CASSANDRA-19285%2Ftrunk
The test flakiness is caused by inspecting a class whose classloader
(InstanceClassLoader) has been closed already. The fix is to include such class
in the sharedClassLoader.
The classes are reached by Spark SizeEstimator, when it estimates the broadcast
variable. In the test scenarios containing cassandra instance shutdown, there
is a chance that it picks the class that is loaded by the closed instance
classloader, causing the exception.
was (Author: yifanc):
PR: https://github.com/apache/cassandra-analytics/pull/39
CI (Repeat 100 times for HostReplacementMultiDCTest):
https://app.circleci.com/pipelines/github/yifan-c/cassandra-analytics?branch=CASSANDRA-19285%2Ftrunk
> Flaky Host replacement tests and shrink tests (Instance class loader is
> already closed)
> ---
>
> Key: CASSANDRA-19285
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19285
> Project: Cassandra
> Issue Type: Bug
> Components: Analytics Library
>Reporter: Francisco Guerrero
>Assignee: Yifan Cai
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> During Circle CI runs there are some flaky integration tests, some noticed are
> * HostReplacementMultiDCTest
> * HostReplacementMultiDCFailureTest
> * HostReplacementFailureTest
> * LeavingSingleFailureTest
> Some of the error message I see in these tests are e.g.
> {code:java}
> java.lang.RuntimeException: java.lang.IllegalStateException: Can't load
> org.apache.cassandra.utils.concurrent.Ref$OnLeak. Instance class loader is
> already closed.
> {code}
> On repeated run, these tests pass.
--
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-19285) Flaky Host replacement tests and shrink tests (Instance class loader is already closed)
[
https://issues.apache.org/jira/browse/CASSANDRA-19285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yifan Cai updated CASSANDRA-19285:
--
Authors: Yifan Cai (was: Yifan Cai)
Test and Documentation Plan: ci (was: The patch retries on
{{BindException}} while provisioning a cluster for shared cluster integration
tests.)
Status: Patch Available (was: Open)
PR: https://github.com/apache/cassandra-analytics/pull/39
CI (Repeat 100 times for HostReplacementMultiDCTest):
https://app.circleci.com/pipelines/github/yifan-c/cassandra-analytics?branch=CASSANDRA-19285%2Ftrunk
> Flaky Host replacement tests and shrink tests (Instance class loader is
> already closed)
> ---
>
> Key: CASSANDRA-19285
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19285
> Project: Cassandra
> Issue Type: Bug
> Components: Analytics Library
>Reporter: Francisco Guerrero
>Assignee: Yifan Cai
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> During Circle CI runs there are some flaky integration tests, some noticed are
> * HostReplacementMultiDCTest
> * HostReplacementMultiDCFailureTest
> * HostReplacementFailureTest
> * LeavingSingleFailureTest
> Some of the error message I see in these tests are e.g.
> {code:java}
> java.lang.RuntimeException: java.lang.IllegalStateException: Can't load
> org.apache.cassandra.utils.concurrent.Ref$OnLeak. Instance class loader is
> already closed.
> {code}
> On repeated run, these tests pass.
--
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
[PR] CASSANDRA-19285 Fix flaky Host replacement tests and shrink tests [cassandra-analytics]
yifan-c opened a new pull request, #39: URL: https://github.com/apache/cassandra-analytics/pull/39 The flakiness is caused by inspecting a class whose classloader is already closed. The fix is to include the those classes in the sharedClassLoader, so that the classLoader is not closed during the test. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19285) Flaky Host replacement tests and shrink tests (Instance class loader is already closed)
[
https://issues.apache.org/jira/browse/CASSANDRA-19285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yifan Cai updated CASSANDRA-19285:
--
Reviewers: (was: Yifan Cai)
> Flaky Host replacement tests and shrink tests (Instance class loader is
> already closed)
> ---
>
> Key: CASSANDRA-19285
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19285
> Project: Cassandra
> Issue Type: Bug
> Components: Analytics Library
>Reporter: Francisco Guerrero
>Assignee: Yifan Cai
>Priority: Normal
>
> During Circle CI runs there are some flaky integration tests, some noticed are
> * HostReplacementMultiDCTest
> * HostReplacementMultiDCFailureTest
> * HostReplacementFailureTest
> * LeavingSingleFailureTest
> Some of the error message I see in these tests are e.g.
> {code:java}
> java.lang.RuntimeException: java.lang.IllegalStateException: Can't load
> org.apache.cassandra.utils.concurrent.Ref$OnLeak. Instance class loader is
> already closed.
> {code}
> On repeated run, these tests pass.
--
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-19285) Flaky Host replacement tests and shrink tests (Instance class loader is already closed)
[
https://issues.apache.org/jira/browse/CASSANDRA-19285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yifan Cai updated CASSANDRA-19285:
--
Bug Category: Parent values: Code(13163)Level 1 values: Bug - Unclear
Impact(13164) (was: Parent values: Code(13163))
Assignee: Yifan Cai
Status: Open (was: Triage Needed)
> Flaky Host replacement tests and shrink tests (Instance class loader is
> already closed)
> ---
>
> Key: CASSANDRA-19285
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19285
> Project: Cassandra
> Issue Type: Bug
> Components: Analytics Library
>Reporter: Francisco Guerrero
>Assignee: Yifan Cai
>Priority: Normal
>
> During Circle CI runs there are some flaky integration tests, some noticed are
> * HostReplacementMultiDCTest
> * HostReplacementMultiDCFailureTest
> * HostReplacementFailureTest
> * LeavingSingleFailureTest
> Some of the error message I see in these tests are e.g.
> {code:java}
> java.lang.RuntimeException: java.lang.IllegalStateException: Can't load
> org.apache.cassandra.utils.concurrent.Ref$OnLeak. Instance class loader is
> already closed.
> {code}
> On repeated run, these tests pass.
--
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-19366) Expose mode of authentication in system_views.clients, nodetool clientstats, and ClientMetrics
[
https://issues.apache.org/jira/browse/CASSANDRA-19366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17817080#comment-17817080
]
Francisco Guerrero commented on CASSANDRA-19366:
For posterity, I already +1'd the PR.
> Expose mode of authentication in system_views.clients, nodetool clientstats,
> and ClientMetrics
> --
>
> Key: CASSANDRA-19366
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19366
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Encryption, Messaging/Client, Observability/JMX,
> Observability/Metrics, Tool/nodetool
>Reporter: Andy Tolbert
>Assignee: Andy Tolbert
>Priority: Normal
> Fix For: 5.1
>
> Attachments: CASSANDRA-19366-trunk-1_test_results-1.tgz,
> CASSANDRA-19366-trunk-1_test_results.tgz,
> CASSANDRA-19366-trunk-1_test_results_summary.html,
> CASSANDRA-19366-trunk-6_ci_summary.html
>
> Time Spent: 4h
> Remaining Estimate: 0h
>
> CASSANDRA-18554 added support for mTLS-authenticated clients. Part of this
> contribution introduced {{{}MutualTlsWithPasswordFallbackAuthenticator{}}},
> which enables Cassandra to support either password and mTLS-authenticated
> connections.
> As an operator, it would be useful to know which connections are mTLS
> authenticated, and which are password authenticated, as a possible mode of
> operation is migrating users from one from of authentication to another. It
> would also be useful to know if that if authentication attempts are failing
> which mode of authentication is unsuccessful.
> Proposing to add the following:
> * Add a {{mode: string}} and {{metadata: map}} to
> {{{}AuthenticatedUser{}}}. Update existing {{IAuthenticator}} implementations
> to pass {{mode}} (e.g. {{password}} , {{{}mtls{}}}), and optionally pass a
> {{metadata}} map (e.g. this can include the extracted {{identity}} from a
> client certificate for {{mtls}} authentication).
> * Update nodetool clientstats to add a new option flag {{{}--metadata{}}},
> which when passed exposes these new fields on {{{}AuthenticatedUser{}}}. (Not
> added to existing output to maintain compatibility, much like
> {{-client-options}} did.
> * Update {{system_views.clients}} to include columns for these new fields.
> * Add new metrics to {{{}ClientMetrics{}}}:
> ** Track authentication success and failures by mode. (Note: The metrics
> present by authentication mode scope are contextual based on the
> Authenticator used (e.g. only {{scope=Password}} will be present for
> {{{}PasswordAuthenticator{}}})
> {noformat}
> Existing:
> org.apache.cassandra.metrics:name=AuthSuccess,type=Client
> org.apache.cassandra.metrics:name=AuthFailure,type=Client
> New:
> org.apache.cassandra.metrics:name=AuthSuccess,scope=MutualTls,type=Client
> org.apache.cassandra.metrics:name=AuthSuccess,scope=Password,type=Client
> org.apache.cassandra.metrics:name=AuthFailure,scope=MutualTls,type=Client
> org.apache.cassandra.metrics:name=AuthFailure,scope=Password,type=Client
> {noformat}
> *
> ** Track connection counts by mode:
> {noformat}
> Existing:
> org.apache.cassandra.metrics:name=ConnectedNativeClients,type=Client
> org.apache.cassandra.metrics:name=connectedNativeClients,type=Client
> (previously deprecated but still maintained)
> New:
> org.apache.cassandra.metrics:name=ConnectedNativeClients,scope=MutualTls,type=Client
> org.apache.cassandra.metrics:name=ConnectedNativeClients,scope=Password,type=Client
> {noformat}
> *
> ** A metric to track encrypted vs. non-encrypted connections:
> {noformat}
> org.apache.cassandra.metrics:name=ConnectedNativeClients,scope=Encrypted,type=Client
> org.apache.cassandra.metrics:name=ConnectedNativeClients,scope=Unencrypted,type=Client
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-19168) Test Failure: VectorUpdateDeleteTest fails with heap_buffers
[
https://issues.apache.org/jira/browse/CASSANDRA-19168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17817046#comment-17817046
]
Ekaterina Dimitrova edited comment on CASSANDRA-19168 at 2/13/24 4:43 PM:
--
Thanks!
The patch was squashed and updated with your suggestion (new branch for 5.0 so
we easily compare with the PR):
5.0 - [https://github.com/ekaterinadimitrova2/cassandra/tree/C-19168-5.0-final]
trunk - [https://github.com/ekaterinadimitrova2/cassandra/tree/C-19168-trunk]
Running CI at the moment:
5.0 -
[https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra?branch=C-19168-5.0-final]
trunk -
[https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra?branch=C-19168-trunk]
I also ran the updateTest with all possible options for
memtable_allocation_type locally on both branches; it completed successfully.
*5.0 CI failures:*
truncateWhileUpgrading-_jdk17 - possible related to CASSANDRA-18635, checking
with Berenguer
*trunk CI failures:*
- test_consistent_range_movement_true_with_replica_down_should_fail - seems
unrelated, I will check and open a ticket
-
testOptionalMtlsModeDoNotAllowNonSSLConnections-cassandra.testtag_IS_UNDEFINED
- known from CASSANDRA-19239
- test_move_single_node_localhost - known from CASSANDRA-19226
- test_authorization_handle_unavailable - known from CASSANDRA-19217
- org.apache.cassandra.simulator.test.HarrySimulatorTest - known from
CASSANDRA-19279
- test_stop_failure_policy - known from CASSANDRA-19100
- optionalTlsConnectionAllowedToRegularPortTest-cassandra.testtag_IS_UNDEFINED
and
testOptionalMtlsModeDoNotAllowNonSSLConnections-cassandra.testtag_IS_UNDEFINED
- known from CASSANDRA-19239
was (Author: e.dimitrova):
Thanks!
The patch was squashed and updated with your suggestion (new branch for 5.0 so
we easily compare with the PR):
5.0 - https://github.com/ekaterinadimitrova2/cassandra/tree/C-19168-5.0-final
trunk - https://github.com/ekaterinadimitrova2/cassandra/tree/C-19168-trunk
Running CI at the moment:
5.0 -
https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra?branch=C-19168-5.0-final
trunk -
https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra?branch=C-19168-trunk
I also ran the updateTest with all possible options for
memtable_allocation_type locally on both branches; it completed successfully.
> Test Failure: VectorUpdateDeleteTest fails with heap_buffers
>
>
> Key: CASSANDRA-19168
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19168
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Vector Search
>Reporter: Branimir Lambov
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
>
> When {{memtable_allocation_type}} is set to {{heap_buffers}}, {{updateTest}}
> fails with
> {code}
> junit.framework.AssertionFailedError: Result set does not contain a row with
> pk = 0
> at
> org.apache.cassandra.index.sai.cql.VectorTypeTest.assertContainsInt(VectorTypeTest.java:133)
> at
> org.apache.cassandra.index.sai.cql.VectorUpdateDeleteTest.updateTest(VectorUpdateDeleteTest.java:308)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19100) commitlog_test.py::TestCommitLog::test_stop_failure_policy failed
[
https://issues.apache.org/jira/browse/CASSANDRA-19100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17817072#comment-17817072
]
Ekaterina Dimitrova commented on CASSANDRA-19100:
-
seen also here -
[test_stop_failure_policy|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2647/workflows/23eb5e2b-9c8c-431f-93ae-60e7891ef1fd/jobs/56169/tests#failed-test-0]
> commitlog_test.py::TestCommitLog::test_stop_failure_policy failed
> -
>
> Key: CASSANDRA-19100
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19100
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Jacek Lewandowski
>Priority: Normal
> Fix For: 5.0.x, 5.x
>
>
> https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/1121/workflows/fce907b1-0526-4d4d-beb5-b6620737a5f3/jobs/50905/tests
> {noformat}
> AssertionError: Cannot find the commitlog failure message in logs
> assert []
> self =
> def test_stop_failure_policy(self):
> """
> Test the stop commitlog failure policy (default one)
> """
> self.prepare()
>
> self._provoke_commitlog_failure()
> failure = self.node1.grep_log("Failed .+ commit log segments. Commit
> disk failure policy is stop; terminating thread")
> logger.debug(failure)
> > assert failure, "Cannot find the commitlog failure message in logs"
> E AssertionError: Cannot find the commitlog failure message in logs
> E assert []
> commitlog_test.py:325: AssertionError
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19217) Test failure: auth_test.TestAuthUnavailable
[ https://issues.apache.org/jira/browse/CASSANDRA-19217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17817068#comment-17817068 ] Ekaterina Dimitrova commented on CASSANDRA-19217: - Seen also here https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2647/workflows/23eb5e2b-9c8c-431f-93ae-60e7891ef1fd/jobs/56146/tests#failed-test-0 > Test failure: auth_test.TestAuthUnavailable > --- > > Key: CASSANDRA-19217 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19217 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest/java >Reporter: Jacek Lewandowski >Priority: Normal > Fix For: 5.x > > > https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/1233/workflows/bb617340-f1da-4550-9c87-5541469972c4/jobs/62551/tests -- 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-19226) Test Failure: pushed_notifications_test.TestPushedNotifications.test_move_single_node_localhost
[
https://issues.apache.org/jira/browse/CASSANDRA-19226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17817064#comment-17817064
]
Ekaterina Dimitrova commented on CASSANDRA-19226:
-
Seen also here -
https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2647/workflows/23eb5e2b-9c8c-431f-93ae-60e7891ef1fd/jobs/56170/tests#failed-test-0
> Test Failure:
> pushed_notifications_test.TestPushedNotifications.test_move_single_node_localhost
> ---
>
> Key: CASSANDRA-19226
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19226
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Jacek Lewandowski
>Priority: Normal
> Fix For: 5.1
>
>
> https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/1252/workflows/234ccc92-65f2-4adb-a68a-a5505398f4d0/jobs/63791/tests
> {noformat}
> AssertionError: assert 'MOVED_NODE' == 'NEW_NODE'
> - NEW_NODE
> + MOVED_NODE
> self = 0x7f4f60868dd0>
> @pytest.mark.no_vnodes
> def test_move_single_node_localhost(self):
> """
> Test that we don't get NODE_MOVED notifications from nodes other than
> the local one,
> when rpc_address is set to localhost (127.0.0.1) Pre 4.0.
> Test that we get NODE_MOVED notifications from nodes other than the
> local one,
> when rpc_address is set to localhost (127.0.0.1) Post 4.0.
> @jira_ticket CASSANDRA-10052
> @jira_ticket CASSANDRA-15677
>
> To set-up this test we override the rpc_address to "localhost
> (127.0.0.1)" for all nodes, and
> therefore we must change the rpc port or else processes won't start.
> """
> cluster = self.cluster
> cluster.populate(3)
>
> self.change_rpc_address_to_localhost()
>
> cluster.start()
>
> waiters = [NotificationWaiter(self, node, ["TOPOLOGY_CHANGE"])
>for node in list(self.cluster.nodes.values())]
>
> # The first node sends NEW_NODE for the other 2 nodes during startup,
> in case they are
> # late due to network delays let's block a bit longer
> logger.debug("Waiting for unwanted notifications...")
> waiters[0].wait_for_notifications(timeout=30, num_notifications=2)
> waiters[0].clear_notifications()
>
> logger.debug("Issuing move command")
> node1 = list(self.cluster.nodes.values())[0]
> node1.move("123")
>
> version = self.cluster.cassandra_version()
> for waiter in waiters:
> logger.debug("Waiting for notification from
> {}".format(waiter.address,))
> notifications = waiter.wait_for_notifications(30.0)
> if version >= '4.0':
> # CASSANDRA-15677 Post 4.0 we'll get the notifications. Check
> that they are for the right node.
> assert 1 == len(notifications), notifications
> notification = notifications[0]
> change_type = notification["change_type"]
> address, port = notification["address"]
> > assert "MOVED_NODE" == change_type
> E AssertionError: assert 'MOVED_NODE' == 'NEW_NODE'
> E - NEW_NODE
> E + MOVED_NODE
> pushed_notifications_test.py:163: AssertionError
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18635) Test failure: org.apache.cassandra.distributed.test.UpgradeSSTablesTest
[
https://issues.apache.org/jira/browse/CASSANDRA-18635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17817058#comment-17817058
]
Ekaterina Dimitrova edited comment on CASSANDRA-18635 at 2/13/24 4:13 PM:
--
[~Bereng] , I just hit this failure from the same class:
truncateWhileUpgrading-_jdk17
{code:java}
junit.framework.AssertionFailedError at
org.apache.cassandra.distributed.test.UpgradeSSTablesTest.truncateWhileUpgrading(UpgradeSSTablesTest.java:220)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method) at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43){code}
[https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2646/workflows/bc2bba74-9e56-4bea-8de7-4ff840c4f450/jobs/56028/tests#failed-test-0]
Not sure whether it can be related to what you do here, checking before moving
to opening a new ticket, etc. Please advise.
was (Author: e.dimitrova):
[~Bereng] , I just hit this failure from the same class:
truncateWhileUpgrading-_jdk17
{code:java}
junit.framework.AssertionFailedError at
org.apache.cassandra.distributed.test.UpgradeSSTablesTest.truncateWhileUpgrading(UpgradeSSTablesTest.java:220)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method) at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43){code}
[https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2646/workflows/bc2bba74-9e56-4bea-8de7-4ff840c4f450/jobs/56028/tests#failed-test-0]
Not sure whether it can be related to what you do here, checking before moving
to opening a new ticket, etc. Please advise.
> Test failure: org.apache.cassandra.distributed.test.UpgradeSSTablesTest
> ---
>
> Key: CASSANDRA-18635
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18635
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: Brandon Williams
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
>
> Seen here:
> https://app.circleci.com/pipelines/github/driftx/cassandra/1095/workflows/6114e2e3-8dcc-4bb0-b664-ae7d82c3349f/jobs/33405/tests
> {noformat}
> junit.framework.AssertionFailedError: expected:<0> but was:<2>
> at
> org.apache.cassandra.distributed.test.UpgradeSSTablesTest.upgradeSSTablesInterruptsOngoingCompaction(UpgradeSSTablesTest.java:86)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18635) Test failure: org.apache.cassandra.distributed.test.UpgradeSSTablesTest
[
https://issues.apache.org/jira/browse/CASSANDRA-18635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17817058#comment-17817058
]
Ekaterina Dimitrova commented on CASSANDRA-18635:
-
[~Bereng] , I just hit this failure from the same class:
truncateWhileUpgrading-_jdk17
{code:java}
junit.framework.AssertionFailedError at
org.apache.cassandra.distributed.test.UpgradeSSTablesTest.truncateWhileUpgrading(UpgradeSSTablesTest.java:220)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method) at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43){code}
[https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2646/workflows/bc2bba74-9e56-4bea-8de7-4ff840c4f450/jobs/56028/tests#failed-test-0]
Not sure whether it can be related to what you do here, checking before moving
to opening a new ticket, etc. Please advise.
> Test failure: org.apache.cassandra.distributed.test.UpgradeSSTablesTest
> ---
>
> Key: CASSANDRA-18635
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18635
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: Brandon Williams
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
>
> Seen here:
> https://app.circleci.com/pipelines/github/driftx/cassandra/1095/workflows/6114e2e3-8dcc-4bb0-b664-ae7d82c3349f/jobs/33405/tests
> {noformat}
> junit.framework.AssertionFailedError: expected:<0> but was:<2>
> at
> org.apache.cassandra.distributed.test.UpgradeSSTablesTest.upgradeSSTablesInterruptsOngoingCompaction(UpgradeSSTablesTest.java:86)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19392) deprecate dual ports support (native_transport_port_ssl)
[ https://issues.apache.org/jira/browse/CASSANDRA-19392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17817053#comment-17817053 ] Brandon Williams commented on CASSANDRA-19392: -- I think that is wise, since it sounds like a recipe for a "but it worked in dev" scenario. > deprecate dual ports support (native_transport_port_ssl) > - > > Key: CASSANDRA-19392 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19392 > Project: Cassandra > Issue Type: Task > Components: Legacy/Core >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 5.0-beta > > Time Spent: 10m > Remaining Estimate: 0h > > We decided (1) to deprecate dual ports support in 5.0 (and eventually remove > it in trunk). This ticket will track the work towards the deprecation for 5.0. > (1) https://lists.apache.org/thread/dow196gspwgp2og576zh3lotvt6mc3lv -- 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-19392) deprecate dual ports support (native_transport_port_ssl)
[ https://issues.apache.org/jira/browse/CASSANDRA-19392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17817051#comment-17817051 ] Stefan Miklosovic commented on CASSANDRA-19392: --- We can log that this feature is effectively not functioning properly except an extreme corner case when there is just one node in whole cluster. > deprecate dual ports support (native_transport_port_ssl) > - > > Key: CASSANDRA-19392 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19392 > Project: Cassandra > Issue Type: Task > Components: Legacy/Core >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 5.0-beta > > Time Spent: 10m > Remaining Estimate: 0h > > We decided (1) to deprecate dual ports support in 5.0 (and eventually remove > it in trunk). This ticket will track the work towards the deprecation for 5.0. > (1) https://lists.apache.org/thread/dow196gspwgp2og576zh3lotvt6mc3lv -- 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-19392) deprecate dual ports support (native_transport_port_ssl)
[ https://issues.apache.org/jira/browse/CASSANDRA-19392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17817049#comment-17817049 ] Brandon Williams commented on CASSANDRA-19392: -- This looks good to me. Should we also communicate that setting this doesn't work anyway? > deprecate dual ports support (native_transport_port_ssl) > - > > Key: CASSANDRA-19392 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19392 > Project: Cassandra > Issue Type: Task > Components: Legacy/Core >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 5.0-beta > > Time Spent: 10m > Remaining Estimate: 0h > > We decided (1) to deprecate dual ports support in 5.0 (and eventually remove > it in trunk). This ticket will track the work towards the deprecation for 5.0. > (1) https://lists.apache.org/thread/dow196gspwgp2og576zh3lotvt6mc3lv -- 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-19353) Cancel Signal when unused in Local Log
[ https://issues.apache.org/jira/browse/CASSANDRA-19353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17817048#comment-17817048 ] Sam Tunnicliffe commented on CASSANDRA-19353: - +1 > Cancel Signal when unused in Local Log > -- > > Key: CASSANDRA-19353 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19353 > Project: Cassandra > Issue Type: Bug > Components: Transactional Cluster Metadata >Reporter: Alex Petrov >Assignee: Alex Petrov >Priority: Normal > Attachments: ci_summary.html, result_details.tar.gz > > -- 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-19168) Test Failure: VectorUpdateDeleteTest fails with heap_buffers
[
https://issues.apache.org/jira/browse/CASSANDRA-19168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17817046#comment-17817046
]
Ekaterina Dimitrova commented on CASSANDRA-19168:
-
Thanks!
The patch was squashed and updated with your suggestion (new branch for 5.0 so
we easily compare with the PR):
5.0 - https://github.com/ekaterinadimitrova2/cassandra/tree/C-19168-5.0-final
trunk - https://github.com/ekaterinadimitrova2/cassandra/tree/C-19168-trunk
Running CI at the moment:
5.0 -
https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra?branch=C-19168-5.0-final
trunk -
https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra?branch=C-19168-trunk
I also ran the updateTest with all possible options for
memtable_allocation_type locally on both branches; it completed successfully.
> Test Failure: VectorUpdateDeleteTest fails with heap_buffers
>
>
> Key: CASSANDRA-19168
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19168
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Vector Search
>Reporter: Branimir Lambov
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
>
> When {{memtable_allocation_type}} is set to {{heap_buffers}}, {{updateTest}}
> fails with
> {code}
> junit.framework.AssertionFailedError: Result set does not contain a row with
> pk = 0
> at
> org.apache.cassandra.index.sai.cql.VectorTypeTest.assertContainsInt(VectorTypeTest.java:133)
> at
> org.apache.cassandra.index.sai.cql.VectorUpdateDeleteTest.updateTest(VectorUpdateDeleteTest.java:308)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19384) Avoid exposing intermediate node state during startup
[ https://issues.apache.org/jira/browse/CASSANDRA-19384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sam Tunnicliffe updated CASSANDRA-19384: Status: Changes Suggested (was: Review In Progress) left a few minor comments on the PR > Avoid exposing intermediate node state during startup > - > > Key: CASSANDRA-19384 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19384 > Project: Cassandra > Issue Type: Bug > Components: Transactional Cluster Metadata >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Attachments: ci_summary.html, result_details.tar.gz > > Time Spent: 20m > Remaining Estimate: 0h > > During startup we replay the local log, during this time we might expose > intermediate node states (via JMX for example). -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19384) Avoid exposing intermediate node state during startup
[ https://issues.apache.org/jira/browse/CASSANDRA-19384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sam Tunnicliffe updated CASSANDRA-19384: Reviewers: Alex Petrov, Sam Tunnicliffe, Sam Tunnicliffe (was: Alex Petrov, Sam Tunnicliffe) Alex Petrov, Sam Tunnicliffe, Sam Tunnicliffe (was: Alex Petrov, Sam Tunnicliffe) Status: Review In Progress (was: Patch Available) > Avoid exposing intermediate node state during startup > - > > Key: CASSANDRA-19384 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19384 > Project: Cassandra > Issue Type: Bug > Components: Transactional Cluster Metadata >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Attachments: ci_summary.html, result_details.tar.gz > > Time Spent: 10m > Remaining Estimate: 0h > > During startup we replay the local log, during this time we might expose > intermediate node states (via JMX for 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-19168) Test Failure: VectorUpdateDeleteTest fails with heap_buffers
[
https://issues.apache.org/jira/browse/CASSANDRA-19168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17816999#comment-17816999
]
Andres de la Peña commented on CASSANDRA-19168:
---
Changes look good to me, +1. I'm just leaving a tiny suggestion on the PR.
> Test Failure: VectorUpdateDeleteTest fails with heap_buffers
>
>
> Key: CASSANDRA-19168
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19168
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Vector Search
>Reporter: Branimir Lambov
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
>
> When {{memtable_allocation_type}} is set to {{heap_buffers}}, {{updateTest}}
> fails with
> {code}
> junit.framework.AssertionFailedError: Result set does not contain a row with
> pk = 0
> at
> org.apache.cassandra.index.sai.cql.VectorTypeTest.assertContainsInt(VectorTypeTest.java:133)
> at
> org.apache.cassandra.index.sai.cql.VectorUpdateDeleteTest.updateTest(VectorUpdateDeleteTest.java:308)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19168) Test Failure: VectorUpdateDeleteTest fails with heap_buffers
[
https://issues.apache.org/jira/browse/CASSANDRA-19168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-19168:
--
Reviewers: Andres de la Peña, Andres de la Peña (was: Andres de la Peña)
Andres de la Peña, Andres de la Peña (was: Andres de la Peña)
Status: Review In Progress (was: Patch Available)
> Test Failure: VectorUpdateDeleteTest fails with heap_buffers
>
>
> Key: CASSANDRA-19168
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19168
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Vector Search
>Reporter: Branimir Lambov
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
>
> When {{memtable_allocation_type}} is set to {{heap_buffers}}, {{updateTest}}
> fails with
> {code}
> junit.framework.AssertionFailedError: Result set does not contain a row with
> pk = 0
> at
> org.apache.cassandra.index.sai.cql.VectorTypeTest.assertContainsInt(VectorTypeTest.java:133)
> at
> org.apache.cassandra.index.sai.cql.VectorUpdateDeleteTest.updateTest(VectorUpdateDeleteTest.java:308)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19168) Test Failure: VectorUpdateDeleteTest fails with heap_buffers
[
https://issues.apache.org/jira/browse/CASSANDRA-19168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-19168:
--
Reviewers: Andres de la Peña
> Test Failure: VectorUpdateDeleteTest fails with heap_buffers
>
>
> Key: CASSANDRA-19168
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19168
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Vector Search
>Reporter: Branimir Lambov
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
>
> When {{memtable_allocation_type}} is set to {{heap_buffers}}, {{updateTest}}
> fails with
> {code}
> junit.framework.AssertionFailedError: Result set does not contain a row with
> pk = 0
> at
> org.apache.cassandra.index.sai.cql.VectorTypeTest.assertContainsInt(VectorTypeTest.java:133)
> at
> org.apache.cassandra.index.sai.cql.VectorUpdateDeleteTest.updateTest(VectorUpdateDeleteTest.java:308)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19392) deprecate dual ports support (native_transport_port_ssl)
[ https://issues.apache.org/jira/browse/CASSANDRA-19392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-19392: -- Test and Documentation Plan: CI Status: Patch Available (was: In Progress) > deprecate dual ports support (native_transport_port_ssl) > - > > Key: CASSANDRA-19392 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19392 > Project: Cassandra > Issue Type: Task > Components: Legacy/Core >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 5.0-beta > > Time Spent: 10m > Remaining Estimate: 0h > > We decided (1) to deprecate dual ports support in 5.0 (and eventually remove > it in trunk). This ticket will track the work towards the deprecation for 5.0. > (1) https://lists.apache.org/thread/dow196gspwgp2og576zh3lotvt6mc3lv -- 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-19392) deprecate dual ports support (native_transport_port_ssl)
[ https://issues.apache.org/jira/browse/CASSANDRA-19392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-19392: -- Status: Needs Committer (was: Patch Available) > deprecate dual ports support (native_transport_port_ssl) > - > > Key: CASSANDRA-19392 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19392 > Project: Cassandra > Issue Type: Task > Components: Legacy/Core >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 5.0-beta > > Time Spent: 10m > Remaining Estimate: 0h > > We decided (1) to deprecate dual ports support in 5.0 (and eventually remove > it in trunk). This ticket will track the work towards the deprecation for 5.0. > (1) https://lists.apache.org/thread/dow196gspwgp2og576zh3lotvt6mc3lv -- 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-19392) deprecate dual ports support (native_transport_port_ssl)
[ https://issues.apache.org/jira/browse/CASSANDRA-19392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-19392: -- Change Category: Operability Complexity: Normal Component/s: Legacy/Core Status: Open (was: Triage Needed) > deprecate dual ports support (native_transport_port_ssl) > - > > Key: CASSANDRA-19392 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19392 > Project: Cassandra > Issue Type: Task > Components: Legacy/Core >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 5.0-beta > > > We decided (1) to deprecate dual ports support in 5.0 (and eventually remove > it in trunk). This ticket will track the work towards the deprecation for 5.0. > (1) https://lists.apache.org/thread/dow196gspwgp2og576zh3lotvt6mc3lv -- 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-19392) deprecate dual ports support (native_transport_port_ssl)
[ https://issues.apache.org/jira/browse/CASSANDRA-19392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-19392: -- Fix Version/s: 5.0-beta > deprecate dual ports support (native_transport_port_ssl) > - > > Key: CASSANDRA-19392 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19392 > Project: Cassandra > Issue Type: Task >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 5.0-beta > > > We decided (1) to deprecate dual ports support in 5.0 (and eventually remove > it in trunk). This ticket will track the work towards the deprecation for 5.0. > (1) https://lists.apache.org/thread/dow196gspwgp2og576zh3lotvt6mc3lv -- 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-19392) deprecate dual ports support (native_transport_port_ssl)
Stefan Miklosovic created CASSANDRA-19392: - Summary: deprecate dual ports support (native_transport_port_ssl) Key: CASSANDRA-19392 URL: https://issues.apache.org/jira/browse/CASSANDRA-19392 Project: Cassandra Issue Type: Task Reporter: Stefan Miklosovic Assignee: Stefan Miklosovic We decided (1) to deprecate dual ports support in 5.0 (and eventually remove it in trunk). This ticket will track the work towards the deprecation for 5.0. (1) https://lists.apache.org/thread/dow196gspwgp2og576zh3lotvt6mc3lv -- 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-16999) add native_port_ssl to system_views.peers table
[ https://issues.apache.org/jira/browse/CASSANDRA-16999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-16999: -- Resolution: Won't Fix Status: Resolved (was: Open) > add native_port_ssl to system_views.peers table > --- > > Key: CASSANDRA-16999 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16999 > Project: Cassandra > Issue Type: Bug > Components: Local/Other >Reporter: Steve Lacerda >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 5.x > > Time Spent: 1h 20m > Remaining Estimate: 0h > > system.peers_v2 includes a “native_port” but has no notion of > native_transport_port vs. native_transport_port_ssl. Given this limited > information, there’s no clear way for the driver to know that different ports > are being used for SSL vs. non-SSL or which of those two ports is identified > by “native_port”. > > The issue we ran into is that the java driver, since it has no notion of the > transport port SSL, the driver was only using the contact points and was not > load balancing. > > The customer had both set: > native_transport_port: 9042 > native_transport_port_ssl: 9142 > > They were attempting to connect to 9142, but that was failing. They could > only use 9042, and so their applications load balancing was failing. We found > that any node that was a contact point was connecting, but the other nodes > were never acting as coordinators. > > There are still issues in the driver, for which I have created JAVA-2967, > which also refers to JAVA-2638, but the system.peers and system.peers_v2 > tables should both contain native_transport_port and > native_transport_port_ssl. > > -- 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-16999) add native_port_ssl to system_views.peers table
[ https://issues.apache.org/jira/browse/CASSANDRA-16999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17816985#comment-17816985 ] Stefan Miklosovic commented on CASSANDRA-16999: --- for the reference, we decided to deprecate dual ports in 5.0 and remove this feature in trunk in favor of using single port capable to handle both un/encrypted traffic. ML for the reference: https://lists.apache.org/thread/dow196gspwgp2og576zh3lotvt6mc3lv I will close this ticket as wont fix and create a new one where deprecation will be implemented. We have still time in trunk to remove it completely as 5.0 release is closer. > add native_port_ssl to system_views.peers table > --- > > Key: CASSANDRA-16999 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16999 > Project: Cassandra > Issue Type: Bug > Components: Local/Other >Reporter: Steve Lacerda >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 5.x > > Time Spent: 1h 20m > Remaining Estimate: 0h > > system.peers_v2 includes a “native_port” but has no notion of > native_transport_port vs. native_transport_port_ssl. Given this limited > information, there’s no clear way for the driver to know that different ports > are being used for SSL vs. non-SSL or which of those two ports is identified > by “native_port”. > > The issue we ran into is that the java driver, since it has no notion of the > transport port SSL, the driver was only using the contact points and was not > load balancing. > > The customer had both set: > native_transport_port: 9042 > native_transport_port_ssl: 9142 > > They were attempting to connect to 9142, but that was failing. They could > only use 9042, and so their applications load balancing was failing. We found > that any node that was a contact point was connecting, but the other nodes > were never acting as coordinators. > > There are still issues in the driver, for which I have created JAVA-2967, > which also refers to JAVA-2638, but the system.peers and system.peers_v2 > tables should both contain native_transport_port and > native_transport_port_ssl. > > -- 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-16999) add native_port_ssl to system_views.peers table
[ https://issues.apache.org/jira/browse/CASSANDRA-16999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17816984#comment-17816984 ] Brandon Williams commented on CASSANDRA-16999: -- bq. So let's deprecate it before 5.0 comes out and remove it in 5.x? I think we're agreeing here but there's nothing to be removed? It does not exist after 3.11 currently, so there is nothing to do as far as code. > add native_port_ssl to system_views.peers table > --- > > Key: CASSANDRA-16999 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16999 > Project: Cassandra > Issue Type: Bug > Components: Local/Other >Reporter: Steve Lacerda >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 5.x > > Time Spent: 1h 20m > Remaining Estimate: 0h > > system.peers_v2 includes a “native_port” but has no notion of > native_transport_port vs. native_transport_port_ssl. Given this limited > information, there’s no clear way for the driver to know that different ports > are being used for SSL vs. non-SSL or which of those two ports is identified > by “native_port”. > > The issue we ran into is that the java driver, since it has no notion of the > transport port SSL, the driver was only using the contact points and was not > load balancing. > > The customer had both set: > native_transport_port: 9042 > native_transport_port_ssl: 9142 > > They were attempting to connect to 9142, but that was failing. They could > only use 9042, and so their applications load balancing was failing. We found > that any node that was a contact point was connecting, but the other nodes > were never acting as coordinators. > > There are still issues in the driver, for which I have created JAVA-2967, > which also refers to JAVA-2638, but the system.peers and system.peers_v2 > tables should both contain native_transport_port and > native_transport_port_ssl. > > -- 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-16999) add native_port_ssl to system_views.peers table
[ https://issues.apache.org/jira/browse/CASSANDRA-16999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17816980#comment-17816980 ] Sam Tunnicliffe commented on CASSANDRA-16999: - bq. We should not leave features (dual port) broken even single port is preferable. So let's deprecate it before 5.0 comes out and remove it in 5.x? > add native_port_ssl to system_views.peers table > --- > > Key: CASSANDRA-16999 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16999 > Project: Cassandra > Issue Type: Bug > Components: Local/Other >Reporter: Steve Lacerda >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 5.x > > Time Spent: 1h 20m > Remaining Estimate: 0h > > system.peers_v2 includes a “native_port” but has no notion of > native_transport_port vs. native_transport_port_ssl. Given this limited > information, there’s no clear way for the driver to know that different ports > are being used for SSL vs. non-SSL or which of those two ports is identified > by “native_port”. > > The issue we ran into is that the java driver, since it has no notion of the > transport port SSL, the driver was only using the contact points and was not > load balancing. > > The customer had both set: > native_transport_port: 9042 > native_transport_port_ssl: 9142 > > They were attempting to connect to 9142, but that was failing. They could > only use 9042, and so their applications load balancing was failing. We found > that any node that was a contact point was connecting, but the other nodes > were never acting as coordinators. > > There are still issues in the driver, for which I have created JAVA-2967, > which also refers to JAVA-2638, but the system.peers and system.peers_v2 > tables should both contain native_transport_port and > native_transport_port_ssl. > > -- 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-16999) add native_port_ssl to system_views.peers table
[ https://issues.apache.org/jira/browse/CASSANDRA-16999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17816979#comment-17816979 ] Stefan Miklosovic commented on CASSANDRA-16999: --- I think we should support this. Even there is 10559. If we dont, then the question is for what we have _ssl port there at all if no driver can connect to that and utilize this feature. We should not leave features (dual port) broken even single port is preferable. > add native_port_ssl to system_views.peers table > --- > > Key: CASSANDRA-16999 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16999 > Project: Cassandra > Issue Type: Bug > Components: Local/Other >Reporter: Steve Lacerda >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 5.x > > Time Spent: 1h 20m > Remaining Estimate: 0h > > system.peers_v2 includes a “native_port” but has no notion of > native_transport_port vs. native_transport_port_ssl. Given this limited > information, there’s no clear way for the driver to know that different ports > are being used for SSL vs. non-SSL or which of those two ports is identified > by “native_port”. > > The issue we ran into is that the java driver, since it has no notion of the > transport port SSL, the driver was only using the contact points and was not > load balancing. > > The customer had both set: > native_transport_port: 9042 > native_transport_port_ssl: 9142 > > They were attempting to connect to 9142, but that was failing. They could > only use 9042, and so their applications load balancing was failing. We found > that any node that was a contact point was connecting, but the other nodes > were never acting as coordinators. > > There are still issues in the driver, for which I have created JAVA-2967, > which also refers to JAVA-2638, but the system.peers and system.peers_v2 > tables should both contain native_transport_port and > native_transport_port_ssl. > > -- 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-16999) add native_port_ssl to system_views.peers table
[ https://issues.apache.org/jira/browse/CASSANDRA-16999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17816977#comment-17816977 ] Brandon Williams commented on CASSANDRA-16999: -- I'm not sure we need this at all after CASSANDRA-10559. > add native_port_ssl to system_views.peers table > --- > > Key: CASSANDRA-16999 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16999 > Project: Cassandra > Issue Type: Bug > Components: Local/Other >Reporter: Steve Lacerda >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 5.x > > Time Spent: 1h 20m > Remaining Estimate: 0h > > system.peers_v2 includes a “native_port” but has no notion of > native_transport_port vs. native_transport_port_ssl. Given this limited > information, there’s no clear way for the driver to know that different ports > are being used for SSL vs. non-SSL or which of those two ports is identified > by “native_port”. > > The issue we ran into is that the java driver, since it has no notion of the > transport port SSL, the driver was only using the contact points and was not > load balancing. > > The customer had both set: > native_transport_port: 9042 > native_transport_port_ssl: 9142 > > They were attempting to connect to 9142, but that was failing. They could > only use 9042, and so their applications load balancing was failing. We found > that any node that was a contact point was connecting, but the other nodes > were never acting as coordinators. > > There are still issues in the driver, for which I have created JAVA-2967, > which also refers to JAVA-2638, but the system.peers and system.peers_v2 > tables should both contain native_transport_port and > native_transport_port_ssl. > > -- 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-16999) system.peers and system.peers_v2 do not contain the native_transport and/or native_transport_port_ssl
[ https://issues.apache.org/jira/browse/CASSANDRA-16999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17816976#comment-17816976 ] Stefan Miklosovic edited comment on CASSANDRA-16999 at 2/13/24 12:09 PM: - I am working just on a patch for trunk based on TCM, almost there. was (Author: smiklosovic): I am working just for a patch for trunk based on TCM, almost there. > system.peers and system.peers_v2 do not contain the native_transport and/or > native_transport_port_ssl > - > > Key: CASSANDRA-16999 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16999 > Project: Cassandra > Issue Type: Bug > Components: Local/Other >Reporter: Steve Lacerda >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x > > Time Spent: 1h 20m > Remaining Estimate: 0h > > system.peers_v2 includes a “native_port” but has no notion of > native_transport_port vs. native_transport_port_ssl. Given this limited > information, there’s no clear way for the driver to know that different ports > are being used for SSL vs. non-SSL or which of those two ports is identified > by “native_port”. > > The issue we ran into is that the java driver, since it has no notion of the > transport port SSL, the driver was only using the contact points and was not > load balancing. > > The customer had both set: > native_transport_port: 9042 > native_transport_port_ssl: 9142 > > They were attempting to connect to 9142, but that was failing. They could > only use 9042, and so their applications load balancing was failing. We found > that any node that was a contact point was connecting, but the other nodes > were never acting as coordinators. > > There are still issues in the driver, for which I have created JAVA-2967, > which also refers to JAVA-2638, but the system.peers and system.peers_v2 > tables should both contain native_transport_port and > native_transport_port_ssl. > > -- 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-16999) add native_port_ssl to system_views.peers table
[ https://issues.apache.org/jira/browse/CASSANDRA-16999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-16999: -- Summary: add native_port_ssl to system_views.peers table (was: system.peers and system.peers_v2 do not contain the native_transport and/or native_transport_port_ssl) > add native_port_ssl to system_views.peers table > --- > > Key: CASSANDRA-16999 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16999 > Project: Cassandra > Issue Type: Bug > Components: Local/Other >Reporter: Steve Lacerda >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 5.x > > Time Spent: 1h 20m > Remaining Estimate: 0h > > system.peers_v2 includes a “native_port” but has no notion of > native_transport_port vs. native_transport_port_ssl. Given this limited > information, there’s no clear way for the driver to know that different ports > are being used for SSL vs. non-SSL or which of those two ports is identified > by “native_port”. > > The issue we ran into is that the java driver, since it has no notion of the > transport port SSL, the driver was only using the contact points and was not > load balancing. > > The customer had both set: > native_transport_port: 9042 > native_transport_port_ssl: 9142 > > They were attempting to connect to 9142, but that was failing. They could > only use 9042, and so their applications load balancing was failing. We found > that any node that was a contact point was connecting, but the other nodes > were never acting as coordinators. > > There are still issues in the driver, for which I have created JAVA-2967, > which also refers to JAVA-2638, but the system.peers and system.peers_v2 > tables should both contain native_transport_port and > native_transport_port_ssl. > > -- 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-16999) system.peers and system.peers_v2 do not contain the native_transport and/or native_transport_port_ssl
[ https://issues.apache.org/jira/browse/CASSANDRA-16999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-16999: -- Fix Version/s: (was: 4.0.x) (was: 4.1.x) (was: 5.0.x) > system.peers and system.peers_v2 do not contain the native_transport and/or > native_transport_port_ssl > - > > Key: CASSANDRA-16999 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16999 > Project: Cassandra > Issue Type: Bug > Components: Local/Other >Reporter: Steve Lacerda >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 5.x > > Time Spent: 1h 20m > Remaining Estimate: 0h > > system.peers_v2 includes a “native_port” but has no notion of > native_transport_port vs. native_transport_port_ssl. Given this limited > information, there’s no clear way for the driver to know that different ports > are being used for SSL vs. non-SSL or which of those two ports is identified > by “native_port”. > > The issue we ran into is that the java driver, since it has no notion of the > transport port SSL, the driver was only using the contact points and was not > load balancing. > > The customer had both set: > native_transport_port: 9042 > native_transport_port_ssl: 9142 > > They were attempting to connect to 9142, but that was failing. They could > only use 9042, and so their applications load balancing was failing. We found > that any node that was a contact point was connecting, but the other nodes > were never acting as coordinators. > > There are still issues in the driver, for which I have created JAVA-2967, > which also refers to JAVA-2638, but the system.peers and system.peers_v2 > tables should both contain native_transport_port and > native_transport_port_ssl. > > -- 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-16999) system.peers and system.peers_v2 do not contain the native_transport and/or native_transport_port_ssl
[ https://issues.apache.org/jira/browse/CASSANDRA-16999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-16999: -- Status: In Progress (was: Patch Available) > system.peers and system.peers_v2 do not contain the native_transport and/or > native_transport_port_ssl > - > > Key: CASSANDRA-16999 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16999 > Project: Cassandra > Issue Type: Bug > Components: Local/Other >Reporter: Steve Lacerda >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x > > Time Spent: 1h 20m > Remaining Estimate: 0h > > system.peers_v2 includes a “native_port” but has no notion of > native_transport_port vs. native_transport_port_ssl. Given this limited > information, there’s no clear way for the driver to know that different ports > are being used for SSL vs. non-SSL or which of those two ports is identified > by “native_port”. > > The issue we ran into is that the java driver, since it has no notion of the > transport port SSL, the driver was only using the contact points and was not > load balancing. > > The customer had both set: > native_transport_port: 9042 > native_transport_port_ssl: 9142 > > They were attempting to connect to 9142, but that was failing. They could > only use 9042, and so their applications load balancing was failing. We found > that any node that was a contact point was connecting, but the other nodes > were never acting as coordinators. > > There are still issues in the driver, for which I have created JAVA-2967, > which also refers to JAVA-2638, but the system.peers and system.peers_v2 > tables should both contain native_transport_port and > native_transport_port_ssl. > > -- 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-16999) system.peers and system.peers_v2 do not contain the native_transport and/or native_transport_port_ssl
[ https://issues.apache.org/jira/browse/CASSANDRA-16999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17816976#comment-17816976 ] Stefan Miklosovic commented on CASSANDRA-16999: --- I am working just for a patch for trunk based on TCM, almost there. > system.peers and system.peers_v2 do not contain the native_transport and/or > native_transport_port_ssl > - > > Key: CASSANDRA-16999 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16999 > Project: Cassandra > Issue Type: Bug > Components: Local/Other >Reporter: Steve Lacerda >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x > > Time Spent: 1h 20m > Remaining Estimate: 0h > > system.peers_v2 includes a “native_port” but has no notion of > native_transport_port vs. native_transport_port_ssl. Given this limited > information, there’s no clear way for the driver to know that different ports > are being used for SSL vs. non-SSL or which of those two ports is identified > by “native_port”. > > The issue we ran into is that the java driver, since it has no notion of the > transport port SSL, the driver was only using the contact points and was not > load balancing. > > The customer had both set: > native_transport_port: 9042 > native_transport_port_ssl: 9142 > > They were attempting to connect to 9142, but that was failing. They could > only use 9042, and so their applications load balancing was failing. We found > that any node that was a contact point was connecting, but the other nodes > were never acting as coordinators. > > There are still issues in the driver, for which I have created JAVA-2967, > which also refers to JAVA-2638, but the system.peers and system.peers_v2 > tables should both contain native_transport_port and > native_transport_port_ssl. > > -- 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-19335) Default nodetool tablestats to Human-Readable Output
[ https://issues.apache.org/jira/browse/CASSANDRA-19335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17816975#comment-17816975 ] Brandon Williams commented on CASSANDRA-19335: -- No, the next step is updating ccm to fix the tests. > Default nodetool tablestats to Human-Readable Output > > > Key: CASSANDRA-19335 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19335 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool >Reporter: Leo Toff >Assignee: Leo Toff >Priority: Low > Fix For: 5.x > > Time Spent: 50m > Remaining Estimate: 0h > > *Current Behavior* > The current implementation of nodetool tablestats in Apache Cassandra outputs > statistics in a format that is not immediately human-readable. This output > primarily includes raw byte counts, which require additional calculation or > conversion to be easily understood by users. This can be inefficient and > time-consuming, especially for users who frequently monitor these statistics > for performance tuning or maintenance purposes. > *Proposed Change* > We propose that nodetool tablestats should, by default, provide its output in > a human-readable format. This change would involve converting byte counts > into more understandable units (KiB, MiB, GiB). The tool could still retain > the option to display raw data for those who need it, perhaps through a flag > such as --no-human-readable or --raw. > *Considerations* > The change should maintain backward compatibility, ensuring that scripts or > tools relying on the current output format can continue to function correctly. > We should provide adequate documentation and examples of both the new default > output and how to access the raw data format, if needed. > *Alignment* > Discussion in the dev mailing list: > [https://lists.apache.org/thread/mlp715kxho5b6f1ql9omlzmmnh4qfby9] > *Related work* > Previous work in the series: > # https://issues.apache.org/jira/browse/CASSANDRA-19015 > # https://issues.apache.org/jira/browse/CASSANDRA-19104 -- 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-19335) Default nodetool tablestats to Human-Readable Output
[ https://issues.apache.org/jira/browse/CASSANDRA-19335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17816974#comment-17816974 ] Stefan Miklosovic commented on CASSANDRA-19335: --- Where are we at? So the plan here is to update dtests in such a way the tests will not be broken, right? Is the common technique of checking what Cassandra version we are running and expecting one or the other output applicable here? > Default nodetool tablestats to Human-Readable Output > > > Key: CASSANDRA-19335 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19335 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool >Reporter: Leo Toff >Assignee: Leo Toff >Priority: Low > Fix For: 5.x > > Time Spent: 50m > Remaining Estimate: 0h > > *Current Behavior* > The current implementation of nodetool tablestats in Apache Cassandra outputs > statistics in a format that is not immediately human-readable. This output > primarily includes raw byte counts, which require additional calculation or > conversion to be easily understood by users. This can be inefficient and > time-consuming, especially for users who frequently monitor these statistics > for performance tuning or maintenance purposes. > *Proposed Change* > We propose that nodetool tablestats should, by default, provide its output in > a human-readable format. This change would involve converting byte counts > into more understandable units (KiB, MiB, GiB). The tool could still retain > the option to display raw data for those who need it, perhaps through a flag > such as --no-human-readable or --raw. > *Considerations* > The change should maintain backward compatibility, ensuring that scripts or > tools relying on the current output format can continue to function correctly. > We should provide adequate documentation and examples of both the new default > output and how to access the raw data format, if needed. > *Alignment* > Discussion in the dev mailing list: > [https://lists.apache.org/thread/mlp715kxho5b6f1ql9omlzmmnh4qfby9] > *Related work* > Previous work in the series: > # https://issues.apache.org/jira/browse/CASSANDRA-19015 > # https://issues.apache.org/jira/browse/CASSANDRA-19104 -- 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-19201) Refactor cqlshmain global constants
[ https://issues.apache.org/jira/browse/CASSANDRA-19201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17816964#comment-17816964 ] Stefan Miklosovic commented on CASSANDRA-19201: --- Yeah, I will take a look around end of the week. Thank you for the reminder. > Refactor cqlshmain global constants > --- > > Key: CASSANDRA-19201 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19201 > Project: Cassandra > Issue Type: Task > Components: CQL/Interpreter >Reporter: Brad Schoening >Assignee: Brad Schoening >Priority: Low > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > Refactor global constants > * move globals CASSANDRA_CQL_HTML and cqlruleset > * move module level defaults (DEFAULT_) into Shell class > * move setup_cqlruleset into cqlshhandling > Remove unused exceptions > * FunctionNotFound(Exception) > * AggregateNotFound(Exception) -- 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-19366) Expose mode of authentication in system_views.clients, nodetool clientstats, and ClientMetrics
[
https://issues.apache.org/jira/browse/CASSANDRA-19366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-19366:
--
Fix Version/s: 5.1
(was: 5.x)
Source Control Link:
https://github.com/apache/cassandra/commit/4120b8ce4f1bc7bd7ce101e4e298fc2211a21fe0
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
> Expose mode of authentication in system_views.clients, nodetool clientstats,
> and ClientMetrics
> --
>
> Key: CASSANDRA-19366
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19366
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Encryption, Messaging/Client, Observability/JMX,
> Observability/Metrics, Tool/nodetool
>Reporter: Andy Tolbert
>Assignee: Andy Tolbert
>Priority: Normal
> Fix For: 5.1
>
> Attachments: CASSANDRA-19366-trunk-1_test_results-1.tgz,
> CASSANDRA-19366-trunk-1_test_results.tgz,
> CASSANDRA-19366-trunk-1_test_results_summary.html,
> CASSANDRA-19366-trunk-6_ci_summary.html
>
> Time Spent: 3h 50m
> Remaining Estimate: 0h
>
> CASSANDRA-18554 added support for mTLS-authenticated clients. Part of this
> contribution introduced {{{}MutualTlsWithPasswordFallbackAuthenticator{}}},
> which enables Cassandra to support either password and mTLS-authenticated
> connections.
> As an operator, it would be useful to know which connections are mTLS
> authenticated, and which are password authenticated, as a possible mode of
> operation is migrating users from one from of authentication to another. It
> would also be useful to know if that if authentication attempts are failing
> which mode of authentication is unsuccessful.
> Proposing to add the following:
> * Add a {{mode: string}} and {{metadata: map}} to
> {{{}AuthenticatedUser{}}}. Update existing {{IAuthenticator}} implementations
> to pass {{mode}} (e.g. {{password}} , {{{}mtls{}}}), and optionally pass a
> {{metadata}} map (e.g. this can include the extracted {{identity}} from a
> client certificate for {{mtls}} authentication).
> * Update nodetool clientstats to add a new option flag {{{}--metadata{}}},
> which when passed exposes these new fields on {{{}AuthenticatedUser{}}}. (Not
> added to existing output to maintain compatibility, much like
> {{-client-options}} did.
> * Update {{system_views.clients}} to include columns for these new fields.
> * Add new metrics to {{{}ClientMetrics{}}}:
> ** Track authentication success and failures by mode. (Note: The metrics
> present by authentication mode scope are contextual based on the
> Authenticator used (e.g. only {{scope=Password}} will be present for
> {{{}PasswordAuthenticator{}}})
> {noformat}
> Existing:
> org.apache.cassandra.metrics:name=AuthSuccess,type=Client
> org.apache.cassandra.metrics:name=AuthFailure,type=Client
> New:
> org.apache.cassandra.metrics:name=AuthSuccess,scope=MutualTls,type=Client
> org.apache.cassandra.metrics:name=AuthSuccess,scope=Password,type=Client
> org.apache.cassandra.metrics:name=AuthFailure,scope=MutualTls,type=Client
> org.apache.cassandra.metrics:name=AuthFailure,scope=Password,type=Client
> {noformat}
> *
> ** Track connection counts by mode:
> {noformat}
> Existing:
> org.apache.cassandra.metrics:name=ConnectedNativeClients,type=Client
> org.apache.cassandra.metrics:name=connectedNativeClients,type=Client
> (previously deprecated but still maintained)
> New:
> org.apache.cassandra.metrics:name=ConnectedNativeClients,scope=MutualTls,type=Client
> org.apache.cassandra.metrics:name=ConnectedNativeClients,scope=Password,type=Client
> {noformat}
> *
> ** A metric to track encrypted vs. non-encrypted connections:
> {noformat}
> org.apache.cassandra.metrics:name=ConnectedNativeClients,scope=Encrypted,type=Client
> org.apache.cassandra.metrics:name=ConnectedNativeClients,scope=Unencrypted,type=Client
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-19344) Test Failure: org.apache.cassandra.distributed.test.TransientRangeMovementTest.testRemoveNode-_jdk17
[
https://issues.apache.org/jira/browse/CASSANDRA-19344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sam Tunnicliffe reassigned CASSANDRA-19344:
---
Assignee: Sam Tunnicliffe
> Test Failure:
> org.apache.cassandra.distributed.test.TransientRangeMovementTest.testRemoveNode-_jdk17
>
>
> Key: CASSANDRA-19344
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19344
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Sam Tunnicliffe
>Priority: Normal
> Fix For: 5.x
>
>
> The test can fail in two different ways:
> {code:java}
> junit.framework.AssertionFailedError: NOT IN CURRENT: 31 -- [(00,20),
> (31,50)] at
> org.apache.cassandra.distributed.test.TransientRangeMovementTest.assertAllContained(TransientRangeMovementTest.java:203)
> at
> org.apache.cassandra.distributed.test.TransientRangeMovementTest.testRemoveNode(TransientRangeMovementTest.java:183)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method) at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43){code}
> as in here -
> [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2639/workflows/32b92ce7-5e9d-4efb-8362-d200d2414597/jobs/55139/tests#failed-test-0]
> and
> {code:java}
> junit.framework.AssertionFailedError: nodetool command [removenode,
> 6d194555-f6eb-41d0-c000-0003, --force] was not successful stdout:
> stderr: error: Node /127.0.0.4:7012 is alive and owns this ID. Use
> decommission command to remove it from the ring -- StackTrace --
> java.lang.UnsupportedOperationException: Node /127.0.0.4:7012 is alive and
> owns this ID. Use decommission command to remove it from the ring at
> org.apache.cassandra.tcm.sequences.SingleNodeSequences.removeNode(SingleNodeSequences.java:110)
> at
> org.apache.cassandra.service.StorageService.removeNode(StorageService.java:3682)
> at org.apache.cassandra.tools.NodeProbe.removeNode(NodeProbe.java:1020) at
> org.apache.cassandra.tools.nodetool.RemoveNode.execute(RemoveNode.java:51) at
> org.apache.cassandra.tools.NodeTool$NodeToolCmd.runInternal(NodeTool.java:388)
> at org.apache.cassandra.tools.NodeTool$NodeToolCmd.run(NodeTool.java:373) at
> org.apache.cassandra.tools.NodeTool.execute(NodeTool.java:272) at
> org.apache.cassandra.distributed.impl.Instance$DTestNodeTool.execute(Instance.java:1129)
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$nodetoolResult$51(Instance.java:1038)
> at org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:61) at
> org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:71) at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:833) Notifications: Error:
> java.lang.UnsupportedOperationException: Node /127.0.0.4:7012 is alive and
> owns this ID. Use decommission command to remove it from the ring at
> org.apache.cassandra.tcm.sequences.SingleNodeSequences.removeNode(SingleNodeSequences.java:110)
> at
> org.apache.cassandra.service.StorageService.removeNode(StorageService.java:3682)
> at org.apache.cassandra.tools.NodeProbe.removeNode(NodeProbe.java:1020) at
> org.apache.cassandra.tools.nodetool.RemoveNode.execute(RemoveNode.java:51) at
> org.apache.cassandra.tools.NodeTool$NodeToolCmd.runInternal(NodeTool.java:388)
> at org.apache.cassandra.tools.NodeTool$NodeToolCmd.run(NodeTool.java:373) at
> org.apache.cassandra.tools.NodeTool.execute(NodeTool.java:272) at
> org.apache.cassandra.distributed.impl.Instance$DTestNodeTool.execute(Instance.java:1129)
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$nodetoolResult$51(Instance.java:1038)
> at org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:61) at
> org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:71) at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:833) at
> org.apache.cassandra.distributed.api.NodeToolResult$Asserts.fail(NodeToolResult.java:214)
> at
>
[jira] [Updated] (CASSANDRA-19216) CMS: Additional nodes are not added to CMS
[
https://issues.apache.org/jira/browse/CASSANDRA-19216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-19216:
--
Reviewers: Sam Tunnicliffe, Stefan Miklosovic (was: Alex Petrov, Sam
Tunnicliffe)
> CMS: Additional nodes are not added to CMS
> --
>
> Key: CASSANDRA-19216
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19216
> Project: Cassandra
> Issue Type: Bug
> Components: Transactional Cluster Metadata
>Reporter: Paul Chandler
>Assignee: Marcus Eriksson
>Priority: Normal
> Fix For: 5.1-alpha1
>
> Attachments: ci_summary.html, result_details.tar.gz
>
>
> When creating a 3 node cluster on a local machine using 3 loopback addresses
> 127.0.0.1
> 127.0.0.2
> 127.0.0.3
> The nodes are created correctly and the first node is assigned as a CMS node
> as shown:
> {{bin/nodetool p 7199 status{-}{-}}}
> {{{}Datacenter:
> datacenter1{}}}{{{}==={}}}{{{}Status=Up/Down{}}}{{{}|/
> State=Normal/Leaving/Joining/Moving{}}}{{{}- Address Load Tokens
> Owns (effective) Host ID Rack{}}}
> {{UN 127.0.0.3 75.55 KiB 16 76.0%
> 6d194555-f6eb-41d0-c000-0003 rack1}}
> {{UN 127.0.0.2 67.97 KiB 16 59.3%
> 6d194555-f6eb-41d0-c000-0002 rack1}}
> {{UN 127.0.0.1 81 KiB 16 64.7%
> 6d194555-f6eb-41d0-c000-0001 rack1}}
> {{bin/nodetool -p 7199 describecms}}
> {{Cluster Metadata Service:}}
> {{Members: /127.0.0.1:7000}}
> {{Is Member: true}}
> {{Service State: LOCAL}}
> {{Is Migrating: false}}
> {{Epoch: 14}}
> {{Local Pending Count: 0}}
> {{Commits Paused: false}}
> {{{}Replication factor:
> ReplicationParams{class=org.apache.cassandra.locator.MetaStrategy,
> datacenter1=1{
> {{However after doing a reconfigurecms to create a replication factor of 3,
> it seems that there is still only one member of cms.}}
> {{bin/nodetool -p 7199 reconfigurecms datacenter1:3}}
> {{bin/nodetool -p 7199 describecms}}
> {{Cluster Metadata Service:}}
> {{Members: /127.0.0.1:7000}}
> {{Is Member: true}}
> {{Service State: LOCAL}}
> Is Migrating: false
> Epoch: 16
> Local Pending Count: 0
> Commits Paused: false
> Replication factor:
> ReplicationParams\{class=org.apache.cassandra.locator.MetaStrategy,
> datacenter1=3}
> Is this correct, should all 3 nodes be shown in the Members section ?
--
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-19216) CMS: Additional nodes are not added to CMS
[
https://issues.apache.org/jira/browse/CASSANDRA-19216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-19216:
--
Reviewers: Sam Tunnicliffe, Stefan Miklosovic, Stefan Miklosovic (was: Sam
Tunnicliffe, Stefan Miklosovic)
Sam Tunnicliffe, Stefan Miklosovic, Stefan Miklosovic (was: Sam
Tunnicliffe, Stefan Miklosovic)
Status: Review In Progress (was: Patch Available)
> CMS: Additional nodes are not added to CMS
> --
>
> Key: CASSANDRA-19216
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19216
> Project: Cassandra
> Issue Type: Bug
> Components: Transactional Cluster Metadata
>Reporter: Paul Chandler
>Assignee: Marcus Eriksson
>Priority: Normal
> Fix For: 5.1-alpha1
>
> Attachments: ci_summary.html, result_details.tar.gz
>
>
> When creating a 3 node cluster on a local machine using 3 loopback addresses
> 127.0.0.1
> 127.0.0.2
> 127.0.0.3
> The nodes are created correctly and the first node is assigned as a CMS node
> as shown:
> {{bin/nodetool p 7199 status{-}{-}}}
> {{{}Datacenter:
> datacenter1{}}}{{{}==={}}}{{{}Status=Up/Down{}}}{{{}|/
> State=Normal/Leaving/Joining/Moving{}}}{{{}- Address Load Tokens
> Owns (effective) Host ID Rack{}}}
> {{UN 127.0.0.3 75.55 KiB 16 76.0%
> 6d194555-f6eb-41d0-c000-0003 rack1}}
> {{UN 127.0.0.2 67.97 KiB 16 59.3%
> 6d194555-f6eb-41d0-c000-0002 rack1}}
> {{UN 127.0.0.1 81 KiB 16 64.7%
> 6d194555-f6eb-41d0-c000-0001 rack1}}
> {{bin/nodetool -p 7199 describecms}}
> {{Cluster Metadata Service:}}
> {{Members: /127.0.0.1:7000}}
> {{Is Member: true}}
> {{Service State: LOCAL}}
> {{Is Migrating: false}}
> {{Epoch: 14}}
> {{Local Pending Count: 0}}
> {{Commits Paused: false}}
> {{{}Replication factor:
> ReplicationParams{class=org.apache.cassandra.locator.MetaStrategy,
> datacenter1=1{
> {{However after doing a reconfigurecms to create a replication factor of 3,
> it seems that there is still only one member of cms.}}
> {{bin/nodetool -p 7199 reconfigurecms datacenter1:3}}
> {{bin/nodetool -p 7199 describecms}}
> {{Cluster Metadata Service:}}
> {{Members: /127.0.0.1:7000}}
> {{Is Member: true}}
> {{Service State: LOCAL}}
> Is Migrating: false
> Epoch: 16
> Local Pending Count: 0
> Commits Paused: false
> Replication factor:
> ReplicationParams\{class=org.apache.cassandra.locator.MetaStrategy,
> datacenter1=3}
> Is this correct, should all 3 nodes be shown in the Members section ?
--
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-19348) Fix serialization version check in InProgressSequences
[ https://issues.apache.org/jira/browse/CASSANDRA-19348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sam Tunnicliffe updated CASSANDRA-19348: Reviewers: Alex Petrov, Sam Tunnicliffe, Sam Tunnicliffe (was: Alex Petrov, Sam Tunnicliffe) Alex Petrov, Sam Tunnicliffe, Sam Tunnicliffe (was: Alex Petrov, Sam Tunnicliffe) Status: Review In Progress (was: Patch Available) +1 pending CI > Fix serialization version check in InProgressSequences > -- > > Key: CASSANDRA-19348 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19348 > Project: Cassandra > Issue Type: Bug > Components: Transactional Cluster Metadata >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Fix For: 5.x > > -- 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-19348) Fix serialization version check in InProgressSequences
[ https://issues.apache.org/jira/browse/CASSANDRA-19348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sam Tunnicliffe updated CASSANDRA-19348: Test and Documentation Plan: CI Status: Patch Available (was: In Progress) > Fix serialization version check in InProgressSequences > -- > > Key: CASSANDRA-19348 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19348 > Project: Cassandra > Issue Type: Bug > Components: Transactional Cluster Metadata >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Fix For: 5.x > > -- 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-19390) Transformation.Kind should contain an explicit integer id
[ https://issues.apache.org/jira/browse/CASSANDRA-19390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sam Tunnicliffe updated CASSANDRA-19390: Status: Ready to Commit (was: Review In Progress) +1 pending CI > Transformation.Kind should contain an explicit integer id > - > > Key: CASSANDRA-19390 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19390 > Project: Cassandra > Issue Type: Improvement > Components: Transactional Cluster Metadata >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Low > Fix For: 5.x > > -- 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-19391) Flush metadata snapshot table on every write
[ https://issues.apache.org/jira/browse/CASSANDRA-19391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sam Tunnicliffe updated CASSANDRA-19391: Status: Ready to Commit (was: Review In Progress) > Flush metadata snapshot table on every write > > > Key: CASSANDRA-19391 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19391 > Project: Cassandra > Issue Type: Improvement > Components: Transactional Cluster Metadata >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Low > Fix For: 5.x > > > We depend on the latest snapshot when starting up, flushing avoids gaps > between latest snapshot and the most recent local log entry -- 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-19216) CMS: Additional nodes are not added to CMS
[
https://issues.apache.org/jira/browse/CASSANDRA-19216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17816926#comment-17816926
]
Stefan Miklosovic commented on CASSANDRA-19216:
---
I ll run CI and eventually take care of the merge.
> CMS: Additional nodes are not added to CMS
> --
>
> Key: CASSANDRA-19216
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19216
> Project: Cassandra
> Issue Type: Bug
> Components: Transactional Cluster Metadata
>Reporter: Paul Chandler
>Assignee: Marcus Eriksson
>Priority: Normal
> Fix For: 5.1-alpha1
>
> Attachments: ci_summary.html, result_details.tar.gz
>
>
> When creating a 3 node cluster on a local machine using 3 loopback addresses
> 127.0.0.1
> 127.0.0.2
> 127.0.0.3
> The nodes are created correctly and the first node is assigned as a CMS node
> as shown:
> {{bin/nodetool p 7199 status{-}{-}}}
> {{{}Datacenter:
> datacenter1{}}}{{{}==={}}}{{{}Status=Up/Down{}}}{{{}|/
> State=Normal/Leaving/Joining/Moving{}}}{{{}- Address Load Tokens
> Owns (effective) Host ID Rack{}}}
> {{UN 127.0.0.3 75.55 KiB 16 76.0%
> 6d194555-f6eb-41d0-c000-0003 rack1}}
> {{UN 127.0.0.2 67.97 KiB 16 59.3%
> 6d194555-f6eb-41d0-c000-0002 rack1}}
> {{UN 127.0.0.1 81 KiB 16 64.7%
> 6d194555-f6eb-41d0-c000-0001 rack1}}
> {{bin/nodetool -p 7199 describecms}}
> {{Cluster Metadata Service:}}
> {{Members: /127.0.0.1:7000}}
> {{Is Member: true}}
> {{Service State: LOCAL}}
> {{Is Migrating: false}}
> {{Epoch: 14}}
> {{Local Pending Count: 0}}
> {{Commits Paused: false}}
> {{{}Replication factor:
> ReplicationParams{class=org.apache.cassandra.locator.MetaStrategy,
> datacenter1=1{
> {{However after doing a reconfigurecms to create a replication factor of 3,
> it seems that there is still only one member of cms.}}
> {{bin/nodetool -p 7199 reconfigurecms datacenter1:3}}
> {{bin/nodetool -p 7199 describecms}}
> {{Cluster Metadata Service:}}
> {{Members: /127.0.0.1:7000}}
> {{Is Member: true}}
> {{Service State: LOCAL}}
> Is Migrating: false
> Epoch: 16
> Local Pending Count: 0
> Commits Paused: false
> Replication factor:
> ReplicationParams\{class=org.apache.cassandra.locator.MetaStrategy,
> datacenter1=3}
> Is this correct, should all 3 nodes be shown in the Members section ?
--
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-19391) Flush metadata snapshot table on every write
[ https://issues.apache.org/jira/browse/CASSANDRA-19391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sam Tunnicliffe updated CASSANDRA-19391: Status: Review In Progress (was: Patch Available) +1 pending CI > Flush metadata snapshot table on every write > > > Key: CASSANDRA-19391 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19391 > Project: Cassandra > Issue Type: Improvement > Components: Transactional Cluster Metadata >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Low > Fix For: 5.x > > > We depend on the latest snapshot when starting up, flushing avoids gaps > between latest snapshot and the most recent local log entry -- 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-19390) Transformation.Kind should contain an explicit integer id
[ https://issues.apache.org/jira/browse/CASSANDRA-19390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sam Tunnicliffe updated CASSANDRA-19390: Status: Review In Progress (was: Patch Available) > Transformation.Kind should contain an explicit integer id > - > > Key: CASSANDRA-19390 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19390 > Project: Cassandra > Issue Type: Improvement > Components: Transactional Cluster Metadata >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Low > Fix For: 5.x > > -- 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-19216) CMS: Additional nodes are not added to CMS
[
https://issues.apache.org/jira/browse/CASSANDRA-19216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17816920#comment-17816920
]
Sam Tunnicliffe commented on CASSANDRA-19216:
-
Sorry for taking so long to review. The patch LGTM and as far as I can see, any
failures in the CI results appear unrelated. Might be worth rebasing and
re-running CI though before commit.
+1 from me if that looks ok.
> CMS: Additional nodes are not added to CMS
> --
>
> Key: CASSANDRA-19216
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19216
> Project: Cassandra
> Issue Type: Bug
> Components: Transactional Cluster Metadata
>Reporter: Paul Chandler
>Assignee: Marcus Eriksson
>Priority: Normal
> Fix For: 5.1-alpha1
>
> Attachments: ci_summary.html, result_details.tar.gz
>
>
> When creating a 3 node cluster on a local machine using 3 loopback addresses
> 127.0.0.1
> 127.0.0.2
> 127.0.0.3
> The nodes are created correctly and the first node is assigned as a CMS node
> as shown:
> {{bin/nodetool p 7199 status{-}{-}}}
> {{{}Datacenter:
> datacenter1{}}}{{{}==={}}}{{{}Status=Up/Down{}}}{{{}|/
> State=Normal/Leaving/Joining/Moving{}}}{{{}- Address Load Tokens
> Owns (effective) Host ID Rack{}}}
> {{UN 127.0.0.3 75.55 KiB 16 76.0%
> 6d194555-f6eb-41d0-c000-0003 rack1}}
> {{UN 127.0.0.2 67.97 KiB 16 59.3%
> 6d194555-f6eb-41d0-c000-0002 rack1}}
> {{UN 127.0.0.1 81 KiB 16 64.7%
> 6d194555-f6eb-41d0-c000-0001 rack1}}
> {{bin/nodetool -p 7199 describecms}}
> {{Cluster Metadata Service:}}
> {{Members: /127.0.0.1:7000}}
> {{Is Member: true}}
> {{Service State: LOCAL}}
> {{Is Migrating: false}}
> {{Epoch: 14}}
> {{Local Pending Count: 0}}
> {{Commits Paused: false}}
> {{{}Replication factor:
> ReplicationParams{class=org.apache.cassandra.locator.MetaStrategy,
> datacenter1=1{
> {{However after doing a reconfigurecms to create a replication factor of 3,
> it seems that there is still only one member of cms.}}
> {{bin/nodetool -p 7199 reconfigurecms datacenter1:3}}
> {{bin/nodetool -p 7199 describecms}}
> {{Cluster Metadata Service:}}
> {{Members: /127.0.0.1:7000}}
> {{Is Member: true}}
> {{Service State: LOCAL}}
> Is Migrating: false
> Epoch: 16
> Local Pending Count: 0
> Commits Paused: false
> Replication factor:
> ReplicationParams\{class=org.apache.cassandra.locator.MetaStrategy,
> datacenter1=3}
> Is this correct, should all 3 nodes be shown in the Members section ?
--
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-19120) local consistencies may get timeout if blocking read repair is sending the read repair mutation to other DC
[ https://issues.apache.org/jira/browse/CASSANDRA-19120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17816889#comment-17816889 ] Stefan Miklosovic commented on CASSANDRA-19120: --- I run CI before your current latest changes in 4.0 and looked fine. I do not think that the latest minor changes introduced any error. Feel free to update the branches, I will do the final builds after that. > local consistencies may get timeout if blocking read repair is sending the > read repair mutation to other DC > > > Key: CASSANDRA-19120 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19120 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Repair >Reporter: Runtian Liu >Assignee: Runtian Liu >Priority: Normal > Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x > > Attachments: image-2023-11-29-15-26-08-056.png, signature.asc > > Time Spent: 10m > Remaining Estimate: 0h > > For a two DCs cluster setup. When a new node is being added to DC1, for > blocking read repair triggered by local_quorum in DC1, it will require to > send read repair mutation to an extra node(1)(2). The selector for read > repair may select *ANY* node that has not been contacted before(3) instead of > selecting the DC1 nodes. If a node from DC2 is selected, this will cause 100% > timeout because of the bug described below: > When we initialized the latch(4) for blocking read repair, the shouldBlockOn > function will only return true for local nodes(5), the blockFor value will be > reduced if a local node doesn't require repair(6). The blockFor is same as > the number of read repair mutation sent out. But when the coordinator node > receives the response from the target nodes, the latch only count down for > nodes in same DC(7). The latch will wait till timeout and the read request > will timeout. > This can be reproduced if you have a constant load on a 3 + 3 cluster when > adding a node. If you have someway to trigger blocking read repair(maybe by > adding load using stress tool). If you use local_quorum consistency with a > constant read after write load in the same DC that you are adding node. You > will see read timeout issue from time to time because of the bug described > above > > I think for read repair when selecting the extra node to do repair, we should > prefer local nodes than the nodes from other region. Also, we need to fix the > latch part so even if we send mutation to the nodes in other DC, we don't get > a timeout. > (1)[https://github.com/apache/cassandra/blob/cassandra-4.0.11/src/java/org/apache/cassandra/locator/ReplicaPlans.java#L455] > (2)[https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/ConsistencyLevel.java#L183] > (3)[https://github.com/apache/cassandra/blob/cassandra-4.0.11/src/java/org/apache/cassandra/locator/ReplicaPlans.java#L458] > (4)[https://github.com/apache/cassandra/blob/cassandra-4.0.11/src/java/org/apache/cassandra/service/reads/repair/BlockingPartitionRepair.java#L96] > (5)[https://github.com/apache/cassandra/blob/cassandra-4.0.11/src/java/org/apache/cassandra/service/reads/repair/BlockingPartitionRepair.java#L71] > (6)[https://github.com/apache/cassandra/blob/cassandra-4.0.11/src/java/org/apache/cassandra/service/reads/repair/BlockingPartitionRepair.java#L88] > (7)[https://github.com/apache/cassandra/blob/cassandra-4.0.11/src/java/org/apache/cassandra/service/reads/repair/BlockingPartitionRepair.java#L113] > -- 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
