[jira] [Commented] (CASSANDRA-19454) Revert switch to approximate time in Dispatcher to avoid mixing with nanoTime() in downstream timeout calculations
[
https://issues.apache.org/jira/browse/CASSANDRA-19454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17822779#comment-17822779
]
Arun Ganesh commented on CASSANDRA-19454:
-
Hey [~maedhroz],
I understand you've worked on this before. But, if it's fine with you, I'd like
to work on this. I'm a new contributor, and most of the other low hanging fruit
issues are either taken or seem intimidating.
Thanks!
> Revert switch to approximate time in Dispatcher to avoid mixing with
> nanoTime() in downstream timeout calculations
> --
>
> Key: CASSANDRA-19454
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19454
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 5.0.x, 5.x
>
>
> CASSANDRA-15241 changed {{Dispatcher}} to use the {{approxTime}}
> implementation of {{MonotonicClock}} rather than {{nanoTime()}}, but clock
> drift between the two, can potentially cause queries to time out more
> quickly. We should be able to revert the {{Dispatcher}} to use {{nanoTime()}}
> again and similarly change {{QueriesTable} to {{nanoTime()}} as well for
> consistency.
--
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-19452 Use constant reference time during bulk read process [cassandra-analytics]
yifan-c commented on code in PR #44:
URL:
https://github.com/apache/cassandra-analytics/pull/44#discussion_r1509875090
##
cassandra-bridge/src/main/java/org/apache/cassandra/spark/utils/ReaderTimeProvider.java:
##
@@ -0,0 +1,50 @@
+/*
+ * 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.spark.utils;
+
+/**
+ * A {@link TimeProvider} used by reader. It decides the reference epoch on
instantiation and distribute to executors
+ */
+public class ReaderTimeProvider implements TimeProvider
+{
+private static final long serialVersionUID = 880314923071431541L;
Review Comment:
yeah. Forgot to remove the field. The class was serializable.
--
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
Re: [PR] CASSANDRA-19452 Use constant reference time during bulk read process [cassandra-analytics]
yifan-c commented on code in PR #44:
URL:
https://github.com/apache/cassandra-analytics/pull/44#discussion_r1509874100
##
cassandra-bridge/src/main/java/org/apache/cassandra/spark/utils/TimeProvider.java:
##
@@ -19,16 +19,37 @@
package org.apache.cassandra.spark.utils;
+import java.util.concurrent.TimeUnit;
+
/**
* Provides current time
*/
-@FunctionalInterface
public interface TimeProvider
{
-TimeProvider INSTANCE = () -> (int)
Math.floorDiv(System.currentTimeMillis(), 1000L);
+TimeProvider DEFAULT = new TimeProvider()
+{
+private final int referenceEpoch = nowInSeconds();
Review Comment:
The reason of using a single time point is applicable to SBR in general.
The expectation of bulk read is no different than a single point read. It is
surprising if data visibility changes (caused by the advancing time) during the
read.
Bulk read is essentially a transformation from a collection of sstable to a
collection of mutations. The time reference has to be the same in order to get
the same collection of mutations deterministically. The existing behavior is a
bug, especially when TTL is considered. It has little to do with test setup or
prod use case.
--
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
Re: [PR] CASSANDRA-19452 Use constant reference time during bulk read process [cassandra-analytics]
frankgh commented on code in PR #44:
URL:
https://github.com/apache/cassandra-analytics/pull/44#discussion_r1509746490
##
cassandra-bridge/src/main/java/org/apache/cassandra/spark/utils/ReaderTimeProvider.java:
##
@@ -0,0 +1,50 @@
+/*
+ * 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.spark.utils;
+
+/**
+ * A {@link TimeProvider} used by reader. It decides the reference epoch on
instantiation and distribute to executors
+ */
+public class ReaderTimeProvider implements TimeProvider
+{
+private static final long serialVersionUID = 880314923071431541L;
+
+private final int referenceEpoch;
Review Comment:
Explicitly define this variable
```suggestion
private final int referenceEpochInSeconds;
```
##
cassandra-bridge/src/main/java/org/apache/cassandra/spark/utils/ReaderTimeProvider.java:
##
@@ -0,0 +1,50 @@
+/*
+ * 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.spark.utils;
+
+/**
+ * A {@link TimeProvider} used by reader. It decides the reference epoch on
instantiation and distribute to executors
+ */
+public class ReaderTimeProvider implements TimeProvider
+{
+private static final long serialVersionUID = 880314923071431541L;
Review Comment:
probably not needed since we only serialize the int
##
cassandra-bridge/src/main/java/org/apache/cassandra/spark/utils/TimeProvider.java:
##
@@ -19,16 +19,37 @@
package org.apache.cassandra.spark.utils;
+import java.util.concurrent.TimeUnit;
+
/**
* Provides current time
*/
-@FunctionalInterface
public interface TimeProvider
{
-TimeProvider INSTANCE = () -> (int)
Math.floorDiv(System.currentTimeMillis(), 1000L);
+TimeProvider DEFAULT = new TimeProvider()
+{
+private final int referenceEpoch = nowInSeconds();
Review Comment:
maybe we can preserve existing behavior by returning the current seconds
every time.
```
@Override
public int referenceEpochInSeconds()
{
return nowInSeconds();
}
```
One clarification, SBR when running with the CassandraDataLayer, reads a
snapshot. The same is not true for when you are using the `LocalDataLayer` for
example.
--
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
Re: [PR] CASSANDRA-19418 - Changes to report additional bulk analytics job stats for instrumentation [cassandra-analytics]
frankgh commented on code in PR #41:
URL:
https://github.com/apache/cassandra-analytics/pull/41#discussion_r1509715774
##
cassandra-analytics-core/src/main/java/org/apache/cassandra/spark/bulkwriter/BulkWriterContext.java:
##
@@ -21,7 +21,9 @@
import java.io.Serializable;
-public interface BulkWriterContext extends Serializable
+import org.apache.cassandra.spark.common.Reportable;
+
+public interface BulkWriterContext extends Serializable, Reportable
Review Comment:
I don't think this belongs in the `BulkWriterContext`. The context is
something we share with executors. However the job stats are tracked from the
driver only. I would avoid adding anything else to the BulkWriterContext
##
cassandra-analytics-core/src/main/java/org/apache/cassandra/spark/common/Reportable.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.spark.common;
Review Comment:
should this be in a stats or metrics package instead?
##
cassandra-analytics-core/src/main/java/org/apache/cassandra/spark/bulkwriter/RingInstance.java:
##
@@ -49,6 +49,7 @@ public RingInstance(ReplicaMetadata replica)
.datacenter(replica.datacenter())
.state(replica.state())
.status(replica.status())
+ .token("")
Review Comment:
why this change?
##
cassandra-analytics-core/src/main/java/org/apache/cassandra/spark/bulkwriter/CassandraBulkSourceRelation.java:
##
@@ -107,17 +112,25 @@ private void persist(@NotNull JavaPairRDD sortedRDD, Str
{
try
{
-sortedRDD.foreachPartition(writeRowsInPartition(broadcastContext,
columnNames));
+List results = sortedRDD
+
.mapPartitions(partitionsFlatMapFunc(broadcastContext, columnNames))
+ .collect();
+long rowCount = results.stream().mapToLong(res ->
res.rowCount).sum();
+long totalBytesWritten = results.stream().mapToLong(res ->
res.bytesWritten).sum();
+LOGGER.info("Bulk writer has written {} rows and {} bytes",
rowCount, totalBytesWritten);
+recordSuccessfulJobStats(rowCount, totalBytesWritten);
}
catch (Throwable throwable)
{
+recordFailureStats(throwable.getMessage());
LOGGER.error("Bulk Write Failed", throwable);
throw new RuntimeException("Bulk Write to Cassandra has failed",
throwable);
}
finally
{
try
{
+writerContext.publishJobStats();
Review Comment:
I don't think this will do what you think it will do. This object _should_
be treated as a read-only object from the point of view of the executors. Data
won't propagate back to the driver once the executors complete
##
cassandra-analytics-core/src/main/java/org/apache/cassandra/spark/common/Reportable.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.spark.common;
+
+import java.util.Map;
+
+/**
+ * Interface to provide functionality to report Spark Job Statistics and/or
properties
+ * that can optionally be instrumented. The default implementation merely logs
these
+ * stats at the end of the job.
+ */
Re: [PR] CASSANDRA-19424 Check for expired certificate during start up validation [cassandra-analytics]
frankgh commented on code in PR #43:
URL:
https://github.com/apache/cassandra-analytics/pull/43#discussion_r1509704327
##
cassandra-analytics-core/src/test/java/org/apache/cassandra/spark/validation/KeyStoreValidationTests.java:
##
@@ -97,4 +98,15 @@ public void testValidKeyStore()
Throwable throwable = validation.perform();
assertNull(throwable);
}
+
+@Test
+public void testExpiredKeyStore()
+{
+SecretsProvider secrets = TestSecretsProvider.forKeyStore("PKCS12",
"keystore-expired.p12", "qwerty");
+KeyStoreValidation validation = new KeyStoreValidation(secrets);
+
+Throwable throwable = validation.perform();
+assertInstanceOf(RuntimeException.class, throwable);
+assertThat(throwable.getMessage()).startsWith("Certificate expired,
valid NotAfter: ");
Review Comment:
the error message is odd, Should we just say:
`Certificate expired. NotAfter:` instead?
##
cassandra-analytics-core/src/main/java/org/apache/cassandra/spark/validation/KeyStoreValidation.java:
##
@@ -81,6 +85,15 @@ public void validate()
throw new RuntimeException("KeyStore is empty");
}
+for (Enumeration aliases = keyStore.aliases();
aliases.hasMoreElements();)
+{
+Certificate cert =
keyStore.getCertificate(aliases.nextElement());
+if (cert instanceof X509Certificate && !(cert instanceof
PemX509Certificate))
Review Comment:
I don't think we need to worry about `PemX509Certificate`s.
--
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-19454) Revert switch to approximate time in Dispatcher to avoid mixing with nanoTime() in downstream timeout calculations
[
https://issues.apache.org/jira/browse/CASSANDRA-19454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-19454:
Bug Category: Parent values: Availability(12983)
Complexity: Low Hanging Fruit
Component/s: Messaging/Client
Discovered By: Code Inspection
Fix Version/s: 5.0.x
5.x
Severity: Low
Status: Open (was: Triage Needed)
> Revert switch to approximate time in Dispatcher to avoid mixing with
> nanoTime() in downstream timeout calculations
> --
>
> Key: CASSANDRA-19454
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19454
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 5.0.x, 5.x
>
>
> CASSANDRA-15241 changed {{Dispatcher}} to use the {{approxTime}}
> implementation of {{MonotonicClock}} rather than {{nanoTime()}}, but clock
> drift between the two, can potentially cause queries to time out more
> quickly. We should be able to revert the {{Dispatcher}} to use {{nanoTime()}}
> again and similarly change {{QueriesTable} to {{nanoTime()}} as well for
> consistency.
--
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-19454) Revert switch to approximate time in Dispatcher to avoid mixing with nanoTime() in downstream timeout calculations
Caleb Rackliffe created CASSANDRA-19454:
---
Summary: Revert switch to approximate time in Dispatcher to avoid
mixing with nanoTime() in downstream timeout calculations
Key: CASSANDRA-19454
URL: https://issues.apache.org/jira/browse/CASSANDRA-19454
Project: Cassandra
Issue Type: Bug
Reporter: Caleb Rackliffe
Assignee: Caleb Rackliffe
CASSANDRA-15241 changed {{Dispatcher}} to use the {{approxTime}} implementation
of {{MonotonicClock}} rather than {{nanoTime()}}, but clock drift between the
two, can potentially cause queries to time out more quickly. We should be able
to revert the {{Dispatcher}} to use {{nanoTime()}} again and similarly change
{{QueriesTable} to {{nanoTime()}} as well for consistency.
--
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-18473) Storage Attached Indexes (Phase 2)
[ https://issues.apache.org/jira/browse/CASSANDRA-18473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Rackliffe updated CASSANDRA-18473: Source Control Link: https://github.com/apache/cassandra/commit/f7984627e7dd5794dabc099f49ecf80ca3631803 Resolution: Fixed Status: Resolved (was: Ready to Commit) This epic is now complete. All known 5.0-blocking issues have been resolved. While there are still some areas to explore around query performance and resource usage, the completion of a first round of Harry-based fuzz tests means we should now have a reasonable level of confidence in SAI's correctness. Thanks to everyone who contributed! > Storage Attached Indexes (Phase 2) > -- > > Key: CASSANDRA-18473 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18473 > Project: Cassandra > Issue Type: Epic > Components: Feature/2i Index >Reporter: Caleb Rackliffe >Assignee: Caleb Rackliffe >Priority: Normal > Labels: SAI > Fix For: 5.0-rc > > > At the completion of CASSANDRA-16052, we should be able to release the core > capabilities of SAI in a stable, production-ready package. Once that begins > to gain traction, we'll be able to make improvements and add features for the > next major release. The major initial theme of this epic is likely to be > performance, but it will likely expand to include features like basic text > analysis, etc. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18473) Storage Attached Indexes (Phase 2)
[ https://issues.apache.org/jira/browse/CASSANDRA-18473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Rackliffe updated CASSANDRA-18473: Reviewers: Alex Petrov, Andres de la Peña, Caleb Rackliffe, Jonathan Ellis, Mike Adamson, Piotr Kolaczkowski, Stefan Miklosovic, Zhao Yang Status: Review In Progress (was: Patch Available) > Storage Attached Indexes (Phase 2) > -- > > Key: CASSANDRA-18473 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18473 > Project: Cassandra > Issue Type: Epic > Components: Feature/2i Index >Reporter: Caleb Rackliffe >Assignee: Caleb Rackliffe >Priority: Normal > Labels: SAI > Fix For: 5.0-rc > > > At the completion of CASSANDRA-16052, we should be able to release the core > capabilities of SAI in a stable, production-ready package. Once that begins > to gain traction, we'll be able to make improvements and add features for the > next major release. The major initial theme of this epic is likely to be > performance, but it will likely expand to include features like basic text > analysis, etc. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18473) Storage Attached Indexes (Phase 2)
[ https://issues.apache.org/jira/browse/CASSANDRA-18473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Rackliffe updated CASSANDRA-18473: Status: Ready to Commit (was: Review In Progress) > Storage Attached Indexes (Phase 2) > -- > > Key: CASSANDRA-18473 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18473 > Project: Cassandra > Issue Type: Epic > Components: Feature/2i Index >Reporter: Caleb Rackliffe >Assignee: Caleb Rackliffe >Priority: Normal > Labels: SAI > Fix For: 5.0-rc > > > At the completion of CASSANDRA-16052, we should be able to release the core > capabilities of SAI in a stable, production-ready package. Once that begins > to gain traction, we'll be able to make improvements and add features for the > next major release. The major initial theme of this epic is likely to be > performance, but it will likely expand to include features like basic text > analysis, etc. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18473) Storage Attached Indexes (Phase 2)
[ https://issues.apache.org/jira/browse/CASSANDRA-18473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Rackliffe updated CASSANDRA-18473: Test and Documentation Plan: see sub-tasks... Status: Patch Available (was: In Progress) > Storage Attached Indexes (Phase 2) > -- > > Key: CASSANDRA-18473 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18473 > Project: Cassandra > Issue Type: Epic > Components: Feature/2i Index >Reporter: Caleb Rackliffe >Assignee: Caleb Rackliffe >Priority: Normal > Labels: SAI > Fix For: 5.0-rc > > > At the completion of CASSANDRA-16052, we should be able to release the core > capabilities of SAI in a stable, production-ready package. Once that begins > to gain traction, we'll be able to make improvements and add features for the > next major release. The major initial theme of this epic is likely to be > performance, but it will likely expand to include features like basic text > analysis, etc. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18275) Harry model and in-JVM test for partition-restricted 2i queries
[ https://issues.apache.org/jira/browse/CASSANDRA-18275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Rackliffe updated CASSANDRA-18275: Source Control Link: https://github.com/apache/cassandra/commit/001f70367e32bd44dc03c30d5533e549bbaea67e Resolution: Fixed Status: Resolved (was: Ready to Commit) Committed as https://github.com/apache/cassandra/commit/001f70367e32bd44dc03c30d5533e549bbaea67e > Harry model and in-JVM test for partition-restricted 2i queries > --- > > Key: CASSANDRA-18275 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18275 > Project: Cassandra > Issue Type: Task > Components: Feature/2i Index, Test/fuzz >Reporter: Caleb Rackliffe >Assignee: Caleb Rackliffe >Priority: Normal > Labels: pull-request-available > Fix For: 5.x > > Time Spent: 40m > Remaining Estimate: 0h > > The smallest useful scope for Harry testing w/ 2i would be to cover queries > within large partitions. Creating a model to do this should also be easier > than it would be for the “global” query case, so it seems like a good place > to start. The goal here should be to create something that can simply be run > for a specified amount of time as an in-JVM test and be run going forward as > part of our normal CI process. -- 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: Harry model and in-JVM tests for partition-restricted 2i queries
This is an automated email from the ASF dual-hosted git repository.
maedhroz 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 001f70367e Harry model and in-JVM tests for partition-restricted 2i
queries
001f70367e is described below
commit 001f70367e32bd44dc03c30d5533e549bbaea67e
Author: Caleb Rackliffe
AuthorDate: Thu Jan 11 23:13:56 2024 -0600
Harry model and in-JVM tests for partition-restricted 2i queries
patch by Caleb Rackliffe; reviewed by Alex Petrov for CASSANDRA-18275
Co-authored-by: Caleb Rackliffe
Co-authored-by: Alex Petrov
---
CHANGES.txt| 1 +
.../cassandra/fuzz/sai/MultiNodeSAITest.java | 102 +++
.../cassandra/fuzz/sai/SingleNodeSAITest.java | 310 +
.../cassandra/fuzz/sai/StaticsTortureTest.java | 264 ++
.../org/apache/cassandra/harry/ddl/SchemaSpec.java | 35 ++-
.../cassandra/harry/model/AgainstSutChecker.java | 32 ++-
.../apache/cassandra/harry/model/SelectHelper.java | 39 +--
.../harry/model/reconciler/PartitionState.java | 1 -
.../harry/operations/CompiledStatement.java| 7 +
.../cassandra/harry/operations/FilteringQuery.java | 6 +
.../cassandra/harry/sut/injvm/InJvmSutBase.java| 11 +-
11 files changed, 770 insertions(+), 38 deletions(-)
diff --git a/CHANGES.txt b/CHANGES.txt
index fbbc57216b..f3c3096705 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
5.1
+ * Harry model and in-JVM tests for partition-restricted 2i queries
(CASSANDRA-18275)
* Refactor cqlshmain global constants (CASSANDRA-19201)
* Remove native_transport_port_ssl (CASSANDRA-19397)
* Make nodetool reconfigurecms sync by default and add --cancel to be able to
cancel ongoing reconfigurations (CASSANDRA-19216)
diff --git
a/test/distributed/org/apache/cassandra/fuzz/sai/MultiNodeSAITest.java
b/test/distributed/org/apache/cassandra/fuzz/sai/MultiNodeSAITest.java
new file mode 100644
index 00..b45b6f782b
--- /dev/null
+++ b/test/distributed/org/apache/cassandra/fuzz/sai/MultiNodeSAITest.java
@@ -0,0 +1,102 @@
+/*
+ * 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.fuzz.sai;
+
+import org.junit.Before;
+import org.junit.BeforeClass;
+
+import org.apache.cassandra.distributed.Cluster;
+import org.apache.cassandra.distributed.test.sai.SAIUtil;
+import org.apache.cassandra.harry.ddl.SchemaSpec;
+import org.apache.cassandra.harry.sut.injvm.InJvmSut;
+import org.apache.cassandra.harry.sut.injvm.InJvmSutBase;
+
+import static org.apache.cassandra.distributed.api.Feature.GOSSIP;
+import static org.apache.cassandra.distributed.api.Feature.NETWORK;
+
+public class MultiNodeSAITest extends SingleNodeSAITest
+{
+/**
+ * Chosing a fetch size has implications for how well this test will
excercise paging, short-read protection, and
+ * other important parts of the distributed query apparatus. This should
be set low enough to ensure a significant
+ * number of queries during validation page, but not too low that more
expesive queries time out and fail the test.
+ */
+private static final int FETCH_SIZE = 10;
+
+@BeforeClass
+public static void before() throws Throwable
+{
+cluster = Cluster.build()
+ .withNodes(2)
+ // At lower fetch sizes, queries w/ hundreds or
thousands of matches can take a very long time.
+ .withConfig(InJvmSutBase.defaultConfig().andThen(c ->
c.set("range_request_timeout", "180s").set("read_request_timeout", "180s")
+
.with(GOSSIP).with(NETWORK)))
+ .createWithoutStarting();
+cluster.setUncaughtExceptionsFilter(t -> {
+logger.error("Caught exception, reporting during shutdown.
Ignoring.", t);
+return true;
+});
+cluster.startup();
+cluster = init(cluster);
+sut = new InJvmSut(cluster) {
+@Override
+public
[jira] [Updated] (CASSANDRA-18275) Harry model and in-JVM test for partition-restricted 2i queries
[ https://issues.apache.org/jira/browse/CASSANDRA-18275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Rackliffe updated CASSANDRA-18275: Status: Ready to Commit (was: Review In Progress) > Harry model and in-JVM test for partition-restricted 2i queries > --- > > Key: CASSANDRA-18275 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18275 > Project: Cassandra > Issue Type: Task > Components: Feature/2i Index, Test/fuzz >Reporter: Caleb Rackliffe >Assignee: Caleb Rackliffe >Priority: Normal > Labels: pull-request-available > Fix For: 5.x > > Time Spent: 20m > Remaining Estimate: 0h > > The smallest useful scope for Harry testing w/ 2i would be to cover queries > within large partitions. Creating a model to do this should also be easier > than it would be for the “global” query case, so it seems like a good place > to start. The goal here should be to create something that can simply be run > for a specified amount of time as an in-JVM test and be run going forward as > part of our normal CI process. -- 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-18275) Harry model and in-JVM test for partition-restricted 2i queries
[ https://issues.apache.org/jira/browse/CASSANDRA-18275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Rackliffe updated CASSANDRA-18275: Authors: Alex Petrov, Caleb Rackliffe (was: Alex Petrov) > Harry model and in-JVM test for partition-restricted 2i queries > --- > > Key: CASSANDRA-18275 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18275 > Project: Cassandra > Issue Type: Task > Components: Feature/2i Index, Test/fuzz >Reporter: Caleb Rackliffe >Assignee: Caleb Rackliffe >Priority: Normal > Labels: pull-request-available > Fix For: 5.x > > Time Spent: 20m > Remaining Estimate: 0h > > The smallest useful scope for Harry testing w/ 2i would be to cover queries > within large partitions. Creating a model to do this should also be easier > than it would be for the “global” query case, so it seems like a good place > to start. The goal here should be to create something that can simply be run > for a specified amount of time as an in-JVM test and be run going forward as > part of our normal CI process. -- 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-18275) Harry model and in-JVM test for partition-restricted 2i queries
[ https://issues.apache.org/jira/browse/CASSANDRA-18275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Rackliffe updated CASSANDRA-18275: Test and Documentation Plan: This patch is itself a bunch of new tests :) Status: Patch Available (was: In Progress) > Harry model and in-JVM test for partition-restricted 2i queries > --- > > Key: CASSANDRA-18275 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18275 > Project: Cassandra > Issue Type: Task > Components: Feature/2i Index, Test/fuzz >Reporter: Caleb Rackliffe >Assignee: Caleb Rackliffe >Priority: Normal > Labels: pull-request-available > Fix For: 5.x > > Time Spent: 20m > Remaining Estimate: 0h > > The smallest useful scope for Harry testing w/ 2i would be to cover queries > within large partitions. Creating a model to do this should also be easier > than it would be for the “global” query case, so it seems like a good place > to start. The goal here should be to create something that can simply be run > for a specified amount of time as an in-JVM test and be run going forward as > part of our normal CI process. -- 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-18275) Harry model and in-JVM test for partition-restricted 2i queries
[ https://issues.apache.org/jira/browse/CASSANDRA-18275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Rackliffe updated CASSANDRA-18275: Reviewers: Alex Petrov (was: Caleb Rackliffe) Status: Review In Progress (was: Patch Available) > Harry model and in-JVM test for partition-restricted 2i queries > --- > > Key: CASSANDRA-18275 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18275 > Project: Cassandra > Issue Type: Task > Components: Feature/2i Index, Test/fuzz >Reporter: Caleb Rackliffe >Assignee: Caleb Rackliffe >Priority: Normal > Labels: pull-request-available > Fix For: 5.x > > Time Spent: 20m > Remaining Estimate: 0h > > The smallest useful scope for Harry testing w/ 2i would be to cover queries > within large partitions. Creating a model to do this should also be easier > than it would be for the “global” query case, so it seems like a good place > to start. The goal here should be to create something that can simply be run > for a specified amount of time as an in-JVM test and be run going forward as > part of our normal CI process. -- 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-18275) Harry model and in-JVM test for partition-restricted 2i queries
[ https://issues.apache.org/jira/browse/CASSANDRA-18275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17822703#comment-17822703 ] Alex Petrov commented on CASSANDRA-18275: - +1, thank you for porting and extending these! > Harry model and in-JVM test for partition-restricted 2i queries > --- > > Key: CASSANDRA-18275 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18275 > Project: Cassandra > Issue Type: Task > Components: Feature/2i Index, Test/fuzz >Reporter: Caleb Rackliffe >Assignee: Caleb Rackliffe >Priority: Normal > Labels: pull-request-available > Fix For: 5.x > > Time Spent: 20m > Remaining Estimate: 0h > > The smallest useful scope for Harry testing w/ 2i would be to cover queries > within large partitions. Creating a model to do this should also be easier > than it would be for the “global” query case, so it seems like a good place > to start. The goal here should be to create something that can simply be run > for a specified amount of time as an in-JVM test and be run going forward as > part of our normal CI process. -- 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-19242) Update cqlsh version in 5.x
[ https://issues.apache.org/jira/browse/CASSANDRA-19242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brad Schoening updated CASSANDRA-19242: --- Fix Version/s: 5.1 (was: 5.x) > Update cqlsh version in 5.x > --- > > Key: CASSANDRA-19242 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19242 > Project: Cassandra > Issue Type: Task > Components: CQL/Interpreter >Reporter: Brad Schoening >Assignee: Brad Schoening >Priority: Normal > Fix For: 5.1 > > Time Spent: 20m > Remaining Estimate: 0h > > The cqlsh in version 5.0 is 6.2.0, so the version should be incremented on > trunk (5.1) to 6.3.0. -- 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 revert-3154-CASSANDRA-19242 deleted (was 67de93aa3f)
This is an automated email from the ASF dual-hosted git repository. brads pushed a change to branch revert-3154-CASSANDRA-19242 in repository https://gitbox.apache.org/repos/asf/cassandra.git was 67de93aa3f Revert "bumped CQLSH version 6.2 > 6.3" This change permanently discards the following revisions: discard 67de93aa3f Revert "bumped CQLSH version 6.2 > 6.3" discard 42bacdf75d Revert "Update version in readme" - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19242) Update cqlsh version in 5.x
[ https://issues.apache.org/jira/browse/CASSANDRA-19242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brad Schoening updated CASSANDRA-19242: --- Source Control Link: https://github.com/apache/cassandra/pull/3154/commits/88774fcd6b057de263737b351be4c04e616f5b34 Resolution: Fixed Status: Resolved (was: Ready to Commit) > Update cqlsh version in 5.x > --- > > Key: CASSANDRA-19242 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19242 > Project: Cassandra > Issue Type: Task > Components: CQL/Interpreter >Reporter: Brad Schoening >Assignee: Brad Schoening >Priority: Normal > Fix For: 5.x > > Time Spent: 20m > Remaining Estimate: 0h > > The cqlsh in version 5.0 is 6.2.0, so the version should be incremented on > trunk (5.1) to 6.3.0. -- 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-19429) Remove lock contention generated by getCapacity function in SSTableReader
[
https://issues.apache.org/jira/browse/CASSANDRA-19429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17822669#comment-17822669
]
Dipietro Salvatore commented on CASSANDRA-19429:
if you encounter problems to find r8g.24xl instances due to availability
constrains, you can test it on r7i.24xl or r7g.16xl instance type.
The gain results should be slightly less than r8g.24xl but anyway close to 2x
based on our tests
> Remove lock contention generated by getCapacity function in SSTableReader
> -
>
> Key: CASSANDRA-19429
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19429
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
>Reporter: Dipietro Salvatore
>Assignee: Dipietro Salvatore
>Priority: Normal
> Fix For: 4.0.x, 4.1.x
>
> Attachments: Screenshot 2024-02-26 at 10.27.10.png, Screenshot
> 2024-02-27 at 11.29.41.png, asprof_cass4.1.3__lock_20240216052912lock.html
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Profiling Cassandra 4.1.3 on large AWS instances, a high number of lock
> acquires is measured in the `getCapacity` function from
> `org/apache/cassandra/cache/InstrumentingCache` (1.9M lock acquires per 60
> seconds). Based on our tests on r8g.24xlarge instances (using Ubuntu 22.04),
> this limits the CPU utilization of the system to under 50% when testing at
> full load and therefore limits the achieved throughput.
> Removing the lock contention from the SSTableReader.java file by replacing
> the call to `getCapacity` with `size` achieves up to 2.95x increase in
> throughput on r8g.24xlarge and 2x on r7i.24xlarge:
> |Instance type|Cass 4.1.3|Cass 4.1.3 patched|
> |r8g.24xlarge|168k ops|496k ops (2.95x)|
> |r7i.24xlarge|153k ops|304k ops (1.98x)|
>
> Instructions to reproduce:
> {code:java}
> ## Requirements for Ubuntu 22.04
> sudo apt install -y ant git openjdk-11-jdk
> ## Build and run
> CASSANDRA_USE_JDK11=true ant realclean && CASSANDRA_USE_JDK11=true ant jar &&
> CASSANDRA_USE_JDK11=true ant stress-build && rm -rf data && bin/cassandra -f
> -R
> # Run
> bin/cqlsh -e 'drop table if exists keyspace1.standard1;' && \
> bin/cqlsh -e 'drop keyspace if exists keyspace1;' && \
> bin/nodetool clearsnapshot --all && tools/bin/cassandra-stress write
> n=1000 cl=ONE -rate threads=384 -node 127.0.0.1 -log file=cload.log
> -graph file=cload.html && \
> bin/nodetool compact keyspace1 && sleep 30s && \
> tools/bin/cassandra-stress mixed ratio\(write=10,read=90\) duration=10m
> cl=ONE -rate threads=406 -node localhost -log file=result.log -graph
> file=graph.html
> {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-19242) Update cqlsh version in 5.x
[ https://issues.apache.org/jira/browse/CASSANDRA-19242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17822581#comment-17822581 ] Brad Schoening commented on CASSANDRA-19242: [~smiklosovic] I made a mistake on the commit message. I'll ensure to squish change messages next time and review further the how_to_commit link. > Update cqlsh version in 5.x > --- > > Key: CASSANDRA-19242 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19242 > Project: Cassandra > Issue Type: Task > Components: CQL/Interpreter >Reporter: Brad Schoening >Assignee: Brad Schoening >Priority: Normal > Fix For: 5.x > > Time Spent: 20m > Remaining Estimate: 0h > > The cqlsh in version 5.0 is 6.2.0, so the version should be incremented on > trunk (5.1) to 6.3.0. -- 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-19242) Update cqlsh version in 5.x
[ https://issues.apache.org/jira/browse/CASSANDRA-19242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17822580#comment-17822580 ] Stefan Miklosovic commented on CASSANDRA-19242: --- Hi [~bschoeni], I see you have added two commits to trunk. Is there any particular reason why you have not squashed all your changes into one commit and then followed the instruction with the commit message as I mentioned above? There is also detailed procedure how to commit like this https://cassandra.apache.org/_/development/how_to_commit.html Please dont hesitate to reach to me if anything is not clear! > Update cqlsh version in 5.x > --- > > Key: CASSANDRA-19242 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19242 > Project: Cassandra > Issue Type: Task > Components: CQL/Interpreter >Reporter: Brad Schoening >Assignee: Brad Schoening >Priority: Normal > Fix For: 5.x > > Time Spent: 20m > Remaining Estimate: 0h > > The cqlsh in version 5.0 is 6.2.0, so the version should be incremented on > trunk (5.1) to 6.3.0. -- 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-19453) Enabling remote JMX fails to start
[
https://issues.apache.org/jira/browse/CASSANDRA-19453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-19453:
-
Resolution: Invalid
Status: Resolved (was: Open)
my JAVA_HOME was pointed incorrectly
> Enabling remote JMX fails to start
> --
>
> Key: CASSANDRA-19453
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19453
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Brandon Williams
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
>
> If you set LOCAL_JMX to something other than 'yes' in conf/cassandra-env.sh,
> you receive:
> {noformat}
> Exception (java.lang.ExceptionInInitializerError) encountered during startup:
> null
> java.lang.ExceptionInInitializerError
> at
> org.apache.cassandra.utils.JMXServerUtils.configureJmxAuthentication(JMXServerUtils.java:188)
> at
> org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:106)
> at
> org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:154)
> at
> org.apache.cassandra.service.CassandraDaemon.maybeInitJmx(CassandraDaemon.java:172)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:240)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:721)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:855)
> Caused by: java.lang.RuntimeException: java.lang.IllegalAccessException:
> access to public member failed:
> com.sun.jmx.remote.security.JMXPluggableAuthenticator.[Ljava.lang.Object;@afb5821/invokeSpecial,
> from class
> org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper
> (unnamed module @51dcb805)
> at
> org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper.(JMXServerUtils.java:306)
> ... 7 more
> Caused by: java.lang.IllegalAccessException: access to public member failed:
> com.sun.jmx.remote.security.JMXPluggableAuthenticator.[Ljava.lang.Object;@afb5821/invokeSpecial,
> from class
> org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper
> (unnamed module @51dcb805)
> at
> java.base/java.lang.invoke.MemberName.makeAccessException(MemberName.java:955)
> at
> java.base/java.lang.invoke.MethodHandles$Lookup.checkAccess(MethodHandles.java:3882)
> at
> java.base/java.lang.invoke.MethodHandles$Lookup.getDirectConstructorCommon(MethodHandles.java:4117)
> at
> java.base/java.lang.invoke.MethodHandles$Lookup.getDirectConstructorNoSecurityManager(MethodHandles.java:4111)
> at
> java.base/java.lang.invoke.MethodHandles$Lookup.unreflectConstructor(MethodHandles.java:3433)
> at
> org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper.(JMXServerUtils.java:302)
> ... 7 more
> ERROR [main] 2024-03-01 06:16:00,028 CassandraDaemon.java:877 - Exception
> encountered during startup
> java.lang.ExceptionInInitializerError: null
> at
> org.apache.cassandra.utils.JMXServerUtils.configureJmxAuthentication(JMXServerUtils.java:188)
> at
> org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:106)
> at
> org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:154)
> at
> org.apache.cassandra.service.CassandraDaemon.maybeInitJmx(CassandraDaemon.java:172)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:240)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:721)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:855)
> Caused by: java.lang.RuntimeException: java.lang.IllegalAccessException:
> access to public member failed:
> com.sun.jmx.remote.security.JMXPluggableAuthenticator.[Ljava.lang.Object;@afb5821/invokeSpecial,
> from class
> org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper
> (unnamed module @51dcb805)
> at
> org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper.(JMXServerUtils.java:306)
> ... 7 common frames omitted
> Caused by: java.lang.IllegalAccessException: access to public member failed:
> com.sun.jmx.remote.security.JMXPluggableAuthenticator.[Ljava.lang.Object;@afb5821/invokeSpecial,
> from class
> org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper
> (unnamed module @51dcb805)
> at
> java.base/java.lang.invoke.MemberName.makeAccessException(MemberName.java:955)
> at
> java.base/java.lang.invoke.MethodHandles$Lookup.checkAccess(MethodHandles.java:3882)
> at
>
(cassandra) 02/02: Revert "bumped CQLSH version 6.2 > 6.3"
This is an automated email from the ASF dual-hosted git repository. brads pushed a commit to branch revert-3154-CASSANDRA-19242 in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 67de93aa3fc0d1a7d3f92b4d7c4a13167f6f3c45 Author: Brad Schoening <5796692+bschoen...@users.noreply.github.com> AuthorDate: Fri Mar 1 08:37:11 2024 -0500 Revert "bumped CQLSH version 6.2 > 6.3" This reverts commit 94bfbaf3485115adfb1fafe905269a9ca60ece65. --- pylib/cqlshlib/cqlshmain.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pylib/cqlshlib/cqlshmain.py b/pylib/cqlshlib/cqlshmain.py index 95623c17c1..57cb16bb46 100755 --- a/pylib/cqlshlib/cqlshmain.py +++ b/pylib/cqlshlib/cqlshmain.py @@ -61,7 +61,7 @@ except ImportError: build_version = 'UNKNOWN' UTF8 = 'utf-8' -version = "6.3.0" +version = "6.2.0" readline = None try: - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
(cassandra) 01/02: Revert "Update version in readme"
This is an automated email from the ASF dual-hosted git repository. brads pushed a commit to branch revert-3154-CASSANDRA-19242 in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 42bacdf75d7d4967fd9480cb64fd86fee3545a34 Author: Brad Schoening <5796692+bschoen...@users.noreply.github.com> AuthorDate: Fri Mar 1 08:37:11 2024 -0500 Revert "Update version in readme" This reverts commit 85eb68a9b2d708880d8a24b312b1bedc1f7afcf9. --- README.asc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.asc b/README.asc index cd12f6537e..be26f9d97b 100644 --- a/README.asc +++ b/README.asc @@ -42,7 +42,7 @@ be sitting in front of a prompt: Connected to Test Cluster at localhost:9160. -[cqlsh 6.3.0 | Cassandra 5.0-SNAPSHOT | CQL spec 3.4.7 | Native protocol v5] +[cqlsh 6.2.0 | Cassandra 5.0-SNAPSHOT | CQL spec 3.4.7 | Native protocol v5] Use HELP for help. cqlsh> - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
(cassandra) branch trunk updated (58f0e2146b -> 85eb68a9b2)
This is an automated email from the ASF dual-hosted git repository. brads pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git from 58f0e2146b Merge branch 'cassandra-5.0' into trunk new 94bfbaf348 bumped CQLSH version 6.2 > 6.3 new 85eb68a9b2 Update version in readme The 2 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: README.asc | 2 +- pylib/cqlshlib/cqlshmain.py | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
(cassandra) 01/02: bumped CQLSH version 6.2 > 6.3
This is an automated email from the ASF dual-hosted git repository. brads pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 94bfbaf3485115adfb1fafe905269a9ca60ece65 Author: Brad Schoening AuthorDate: Wed Feb 28 18:08:37 2024 -0500 bumped CQLSH version 6.2 > 6.3 --- pylib/cqlshlib/cqlshmain.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pylib/cqlshlib/cqlshmain.py b/pylib/cqlshlib/cqlshmain.py index 57cb16bb46..95623c17c1 100755 --- a/pylib/cqlshlib/cqlshmain.py +++ b/pylib/cqlshlib/cqlshmain.py @@ -61,7 +61,7 @@ except ImportError: build_version = 'UNKNOWN' UTF8 = 'utf-8' -version = "6.2.0" +version = "6.3.0" readline = None try: - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
(cassandra) branch revert-3154-CASSANDRA-19242 created (now 67de93aa3f)
This is an automated email from the ASF dual-hosted git repository. brads pushed a change to branch revert-3154-CASSANDRA-19242 in repository https://gitbox.apache.org/repos/asf/cassandra.git at 67de93aa3f Revert "bumped CQLSH version 6.2 > 6.3" This branch includes the following new commits: new 42bacdf75d Revert "Update version in readme" new 67de93aa3f Revert "bumped CQLSH version 6.2 > 6.3" The 2 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. - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
(cassandra) 02/02: Update version in readme
This is an automated email from the ASF dual-hosted git repository. brads pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 85eb68a9b2d708880d8a24b312b1bedc1f7afcf9 Author: Brad Schoening AuthorDate: Thu Feb 29 10:29:55 2024 -0500 Update version in readme --- README.asc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.asc b/README.asc index be26f9d97b..cd12f6537e 100644 --- a/README.asc +++ b/README.asc @@ -42,7 +42,7 @@ be sitting in front of a prompt: Connected to Test Cluster at localhost:9160. -[cqlsh 6.2.0 | Cassandra 5.0-SNAPSHOT | CQL spec 3.4.7 | Native protocol v5] +[cqlsh 6.3.0 | Cassandra 5.0-SNAPSHOT | CQL spec 3.4.7 | Native protocol v5] Use HELP for help. cqlsh> - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19453) Enabling remote JMX fails to start
[
https://issues.apache.org/jira/browse/CASSANDRA-19453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17822571#comment-17822571
]
Brandon Williams commented on CASSANDRA-19453:
--
Oh, I am using java 11, which is probably relevant.
> Enabling remote JMX fails to start
> --
>
> Key: CASSANDRA-19453
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19453
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Brandon Williams
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
>
> If you set LOCAL_JMX to something other than 'yes' in conf/cassandra-env.sh,
> you receive:
> {noformat}
> Exception (java.lang.ExceptionInInitializerError) encountered during startup:
> null
> java.lang.ExceptionInInitializerError
> at
> org.apache.cassandra.utils.JMXServerUtils.configureJmxAuthentication(JMXServerUtils.java:188)
> at
> org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:106)
> at
> org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:154)
> at
> org.apache.cassandra.service.CassandraDaemon.maybeInitJmx(CassandraDaemon.java:172)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:240)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:721)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:855)
> Caused by: java.lang.RuntimeException: java.lang.IllegalAccessException:
> access to public member failed:
> com.sun.jmx.remote.security.JMXPluggableAuthenticator.[Ljava.lang.Object;@afb5821/invokeSpecial,
> from class
> org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper
> (unnamed module @51dcb805)
> at
> org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper.(JMXServerUtils.java:306)
> ... 7 more
> Caused by: java.lang.IllegalAccessException: access to public member failed:
> com.sun.jmx.remote.security.JMXPluggableAuthenticator.[Ljava.lang.Object;@afb5821/invokeSpecial,
> from class
> org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper
> (unnamed module @51dcb805)
> at
> java.base/java.lang.invoke.MemberName.makeAccessException(MemberName.java:955)
> at
> java.base/java.lang.invoke.MethodHandles$Lookup.checkAccess(MethodHandles.java:3882)
> at
> java.base/java.lang.invoke.MethodHandles$Lookup.getDirectConstructorCommon(MethodHandles.java:4117)
> at
> java.base/java.lang.invoke.MethodHandles$Lookup.getDirectConstructorNoSecurityManager(MethodHandles.java:4111)
> at
> java.base/java.lang.invoke.MethodHandles$Lookup.unreflectConstructor(MethodHandles.java:3433)
> at
> org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper.(JMXServerUtils.java:302)
> ... 7 more
> ERROR [main] 2024-03-01 06:16:00,028 CassandraDaemon.java:877 - Exception
> encountered during startup
> java.lang.ExceptionInInitializerError: null
> at
> org.apache.cassandra.utils.JMXServerUtils.configureJmxAuthentication(JMXServerUtils.java:188)
> at
> org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:106)
> at
> org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:154)
> at
> org.apache.cassandra.service.CassandraDaemon.maybeInitJmx(CassandraDaemon.java:172)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:240)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:721)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:855)
> Caused by: java.lang.RuntimeException: java.lang.IllegalAccessException:
> access to public member failed:
> com.sun.jmx.remote.security.JMXPluggableAuthenticator.[Ljava.lang.Object;@afb5821/invokeSpecial,
> from class
> org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper
> (unnamed module @51dcb805)
> at
> org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper.(JMXServerUtils.java:306)
> ... 7 common frames omitted
> Caused by: java.lang.IllegalAccessException: access to public member failed:
> com.sun.jmx.remote.security.JMXPluggableAuthenticator.[Ljava.lang.Object;@afb5821/invokeSpecial,
> from class
> org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper
> (unnamed module @51dcb805)
> at
> java.base/java.lang.invoke.MemberName.makeAccessException(MemberName.java:955)
> at
> java.base/java.lang.invoke.MethodHandles$Lookup.checkAccess(MethodHandles.java:3882)
> at
>
[jira] [Commented] (CASSANDRA-19453) Enabling remote JMX fails to start
[
https://issues.apache.org/jira/browse/CASSANDRA-19453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17822569#comment-17822569
]
Brandon Williams commented on CASSANDRA-19453:
--
I don't know what to tell you
{quote}
ERROR [main] 2024-03-01 07:28:48,437 CassandraDaemon.java:877 - Exception
encountered during startup
java.lang.ExceptionInInitializerError: null
at
org.apache.cassandra.utils.JMXServerUtils.configureJmxAuthentication(JMXServerUtils.java:188)
at
org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:106)
at
org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:154)
at
org.apache.cassandra.service.CassandraDaemon.maybeInitJmx(CassandraDaemon.java:172)
at
org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:240)
at
org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:721)
at
org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:855)
Caused by: java.lang.RuntimeException: java.lang.IllegalAccessException: access
to public member failed:
com.sun.jmx.remote.security.JMXPluggableAuthenticator.[Ljava.lang.Object;@588ffeb/invokeSpecial,
from class
org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper
(unnamed module @4944252c)
at
org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper.(JMXServerUtils.java:306)
... 7 common frames omitted
Caused by: java.lang.IllegalAccessException: access to public member failed:
com.sun.jmx.remote.security.JMXPluggableAuthenticator.[Ljava.lang.Object;@588ffeb/invokeSpecial,
from class
org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper
(unnamed module @4944252c)
at
java.base/java.lang.invoke.MemberName.makeAccessException(MemberName.java:955)
at
java.base/java.lang.invoke.MethodHandles$Lookup.checkAccess(MethodHandles.java:3882)
at
java.base/java.lang.invoke.MethodHandles$Lookup.getDirectConstructorCommon(MethodHandles.java:4117)
at
java.base/java.lang.invoke.MethodHandles$Lookup.getDirectConstructorNoSecurityManager(MethodHandles.java:4111)
at
java.base/java.lang.invoke.MethodHandles$Lookup.unreflectConstructor(MethodHandles.java:3433)
at
org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper.(JMXServerUtils.java:302)
... 7 common frames omitted
drift@focal2:~/cassandra/5.0$ git diff
diff --git a/conf/cassandra-env.sh b/conf/cassandra-env.sh
index ba9f9d4596..d29ac83bc0 100644
--- a/conf/cassandra-env.sh
+++ b/conf/cassandra-env.sh
@@ -215,7 +215,7 @@ JVM_ON_OUT_OF_MEMORY_ERROR_OPT="-XX:OnOutOfMemoryError=kill
-9 %p"
# with authentication and/or ssl enabled. See
https://wiki.apache.org/cassandra/JmxSecurity
#
if [ "x$LOCAL_JMX" = "x" ]; then
-LOCAL_JMX=yes
+LOCAL_JMX=baz
fi
# Specifies the default port over which Cassandra will be available for
drift@focal2:~/cassandra/5.0$
{quote}
> Enabling remote JMX fails to start
> --
>
> Key: CASSANDRA-19453
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19453
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Brandon Williams
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
>
> If you set LOCAL_JMX to something other than 'yes' in conf/cassandra-env.sh,
> you receive:
> {noformat}
> Exception (java.lang.ExceptionInInitializerError) encountered during startup:
> null
> java.lang.ExceptionInInitializerError
> at
> org.apache.cassandra.utils.JMXServerUtils.configureJmxAuthentication(JMXServerUtils.java:188)
> at
> org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:106)
> at
> org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:154)
> at
> org.apache.cassandra.service.CassandraDaemon.maybeInitJmx(CassandraDaemon.java:172)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:240)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:721)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:855)
> Caused by: java.lang.RuntimeException: java.lang.IllegalAccessException:
> access to public member failed:
> com.sun.jmx.remote.security.JMXPluggableAuthenticator.[Ljava.lang.Object;@afb5821/invokeSpecial,
> from class
> org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper
> (unnamed module @51dcb805)
> at
> org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper.(JMXServerUtils.java:306)
> ... 7 more
> Caused by: java.lang.IllegalAccessException: access to public member failed:
>
[jira] [Comment Edited] (CASSANDRA-19453) Enabling remote JMX fails to start
[
https://issues.apache.org/jira/browse/CASSANDRA-19453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17822569#comment-17822569
]
Brandon Williams edited comment on CASSANDRA-19453 at 3/1/24 1:29 PM:
--
I don't know what to tell you
{noformat}
ERROR [main] 2024-03-01 07:28:48,437 CassandraDaemon.java:877 - Exception
encountered during startup
java.lang.ExceptionInInitializerError: null
at
org.apache.cassandra.utils.JMXServerUtils.configureJmxAuthentication(JMXServerUtils.java:188)
at
org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:106)
at
org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:154)
at
org.apache.cassandra.service.CassandraDaemon.maybeInitJmx(CassandraDaemon.java:172)
at
org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:240)
at
org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:721)
at
org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:855)
Caused by: java.lang.RuntimeException: java.lang.IllegalAccessException: access
to public member failed:
com.sun.jmx.remote.security.JMXPluggableAuthenticator.[Ljava.lang.Object;@588ffeb/invokeSpecial,
from class
org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper
(unnamed module @4944252c)
at
org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper.(JMXServerUtils.java:306)
... 7 common frames omitted
Caused by: java.lang.IllegalAccessException: access to public member failed:
com.sun.jmx.remote.security.JMXPluggableAuthenticator.[Ljava.lang.Object;@588ffeb/invokeSpecial,
from class
org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper
(unnamed module @4944252c)
at
java.base/java.lang.invoke.MemberName.makeAccessException(MemberName.java:955)
at
java.base/java.lang.invoke.MethodHandles$Lookup.checkAccess(MethodHandles.java:3882)
at
java.base/java.lang.invoke.MethodHandles$Lookup.getDirectConstructorCommon(MethodHandles.java:4117)
at
java.base/java.lang.invoke.MethodHandles$Lookup.getDirectConstructorNoSecurityManager(MethodHandles.java:4111)
at
java.base/java.lang.invoke.MethodHandles$Lookup.unreflectConstructor(MethodHandles.java:3433)
at
org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper.(JMXServerUtils.java:302)
... 7 common frames omitted
drift@focal2:~/cassandra/5.0$ git diff
diff --git a/conf/cassandra-env.sh b/conf/cassandra-env.sh
index ba9f9d4596..d29ac83bc0 100644
--- a/conf/cassandra-env.sh
+++ b/conf/cassandra-env.sh
@@ -215,7 +215,7 @@ JVM_ON_OUT_OF_MEMORY_ERROR_OPT="-XX:OnOutOfMemoryError=kill
-9 %p"
# with authentication and/or ssl enabled. See
https://wiki.apache.org/cassandra/JmxSecurity
#
if [ "x$LOCAL_JMX" = "x" ]; then
-LOCAL_JMX=yes
+LOCAL_JMX=baz
fi
# Specifies the default port over which Cassandra will be available for
drift@focal2:~/cassandra/5.0$
{noformat}
was (Author: brandon.williams):
I don't know what to tell you
{quote}
ERROR [main] 2024-03-01 07:28:48,437 CassandraDaemon.java:877 - Exception
encountered during startup
java.lang.ExceptionInInitializerError: null
at
org.apache.cassandra.utils.JMXServerUtils.configureJmxAuthentication(JMXServerUtils.java:188)
at
org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:106)
at
org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:154)
at
org.apache.cassandra.service.CassandraDaemon.maybeInitJmx(CassandraDaemon.java:172)
at
org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:240)
at
org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:721)
at
org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:855)
Caused by: java.lang.RuntimeException: java.lang.IllegalAccessException: access
to public member failed:
com.sun.jmx.remote.security.JMXPluggableAuthenticator.[Ljava.lang.Object;@588ffeb/invokeSpecial,
from class
org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper
(unnamed module @4944252c)
at
org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper.(JMXServerUtils.java:306)
... 7 common frames omitted
Caused by: java.lang.IllegalAccessException: access to public member failed:
com.sun.jmx.remote.security.JMXPluggableAuthenticator.[Ljava.lang.Object;@588ffeb/invokeSpecial,
from class
org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper
(unnamed module @4944252c)
at
java.base/java.lang.invoke.MemberName.makeAccessException(MemberName.java:955)
at
java.base/java.lang.invoke.MethodHandles$Lookup.checkAccess(MethodHandles.java:3882)
[jira] [Assigned] (CASSANDRA-19453) Enabling remote JMX fails to start
[
https://issues.apache.org/jira/browse/CASSANDRA-19453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic reassigned CASSANDRA-19453:
-
Assignee: (was: Stefan Miklosovic)
> Enabling remote JMX fails to start
> --
>
> Key: CASSANDRA-19453
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19453
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Brandon Williams
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
>
> If you set LOCAL_JMX to something other than 'yes' in conf/cassandra-env.sh,
> you receive:
> {noformat}
> Exception (java.lang.ExceptionInInitializerError) encountered during startup:
> null
> java.lang.ExceptionInInitializerError
> at
> org.apache.cassandra.utils.JMXServerUtils.configureJmxAuthentication(JMXServerUtils.java:188)
> at
> org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:106)
> at
> org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:154)
> at
> org.apache.cassandra.service.CassandraDaemon.maybeInitJmx(CassandraDaemon.java:172)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:240)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:721)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:855)
> Caused by: java.lang.RuntimeException: java.lang.IllegalAccessException:
> access to public member failed:
> com.sun.jmx.remote.security.JMXPluggableAuthenticator.[Ljava.lang.Object;@afb5821/invokeSpecial,
> from class
> org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper
> (unnamed module @51dcb805)
> at
> org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper.(JMXServerUtils.java:306)
> ... 7 more
> Caused by: java.lang.IllegalAccessException: access to public member failed:
> com.sun.jmx.remote.security.JMXPluggableAuthenticator.[Ljava.lang.Object;@afb5821/invokeSpecial,
> from class
> org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper
> (unnamed module @51dcb805)
> at
> java.base/java.lang.invoke.MemberName.makeAccessException(MemberName.java:955)
> at
> java.base/java.lang.invoke.MethodHandles$Lookup.checkAccess(MethodHandles.java:3882)
> at
> java.base/java.lang.invoke.MethodHandles$Lookup.getDirectConstructorCommon(MethodHandles.java:4117)
> at
> java.base/java.lang.invoke.MethodHandles$Lookup.getDirectConstructorNoSecurityManager(MethodHandles.java:4111)
> at
> java.base/java.lang.invoke.MethodHandles$Lookup.unreflectConstructor(MethodHandles.java:3433)
> at
> org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper.(JMXServerUtils.java:302)
> ... 7 more
> ERROR [main] 2024-03-01 06:16:00,028 CassandraDaemon.java:877 - Exception
> encountered during startup
> java.lang.ExceptionInInitializerError: null
> at
> org.apache.cassandra.utils.JMXServerUtils.configureJmxAuthentication(JMXServerUtils.java:188)
> at
> org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:106)
> at
> org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:154)
> at
> org.apache.cassandra.service.CassandraDaemon.maybeInitJmx(CassandraDaemon.java:172)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:240)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:721)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:855)
> Caused by: java.lang.RuntimeException: java.lang.IllegalAccessException:
> access to public member failed:
> com.sun.jmx.remote.security.JMXPluggableAuthenticator.[Ljava.lang.Object;@afb5821/invokeSpecial,
> from class
> org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper
> (unnamed module @51dcb805)
> at
> org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper.(JMXServerUtils.java:306)
> ... 7 common frames omitted
> Caused by: java.lang.IllegalAccessException: access to public member failed:
> com.sun.jmx.remote.security.JMXPluggableAuthenticator.[Ljava.lang.Object;@afb5821/invokeSpecial,
> from class
> org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper
> (unnamed module @51dcb805)
> at
> java.base/java.lang.invoke.MemberName.makeAccessException(MemberName.java:955)
> at
> java.base/java.lang.invoke.MethodHandles$Lookup.checkAccess(MethodHandles.java:3882)
> at
> java.base/java.lang.invoke.MethodHandles$Lookup.getDirectConstructorCommon(MethodHandles.java:4117)
>
[jira] [Commented] (CASSANDRA-19453) Enabling remote JMX fails to start
[
https://issues.apache.org/jira/browse/CASSANDRA-19453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17822567#comment-17822567
]
Stefan Miklosovic commented on CASSANDRA-19453:
---
If I have fully setup ssl like this (checkout LOCAL_JMX=baz) it will just jump
to else branch again and all will be just started fine.
{noformat}
LOCAL_JMX="baz"
if [ "x$LOCAL_JMX" = "x" ]; then
LOCAL_JMX=yes
fi
# Specifies the default port over which Cassandra will be available for
# JMX connections.
# For security reasons, you should not expose this port to the internet.
Firewall it if needed.
JMX_PORT="7199"
if [ "$LOCAL_JMX" = "yes" ]; then
JVM_OPTS="$JVM_OPTS -Dcassandra.jmx.local.port=$JMX_PORT"
JVM_OPTS="$JVM_OPTS -Dcom.sun.management.jmxremote.authenticate=false"
else
JVM_OPTS="$JVM_OPTS -Dcassandra.jmx.remote.port=$JMX_PORT"
# if ssl is enabled the same port cannot be used for both jmx and rmi so
either
# pick another value for this property or comment out to use a random port
(though see CASSANDRA-7087 for origins)
JVM_OPTS="$JVM_OPTS -Dcom.sun.management.jmxremote.rmi.port=7750"
# turn on JMX authentication. See below for further options
JVM_OPTS="$JVM_OPTS -Dcom.sun.management.jmxremote.authenticate=true"
# jmx ssl options
JVM_OPTS="$JVM_OPTS -Dcom.sun.management.jmxremote.ssl=true"
JVM_OPTS="$JVM_OPTS -Dcom.sun.management.jmxremote.ssl.need.client.auth=false"
JVM_OPTS="$JVM_OPTS -Dcom.sun.management.jmxremote.registry.ssl=true"
JVM_OPTS="$JVM_OPTS
-Dcom.sun.management.jmxremote.ssl.enabled.protocols=TLSv1.2"
JVM_OPTS="$JVM_OPTS
-Dcom.sun.management.jmxremote.ssl.enabled.cipher.suites=TLS_RSA_WITH_AES_256_CBC_SHA"
JVM_OPTS="$JVM_OPTS
-Djavax.net.ssl.keyStore=/submit/cassandra/ssl/$(hostname)-server-keystore.p12"
JVM_OPTS="$JVM_OPTS -Djavax.net.ssl.keyStorePassword=cassandra"
JVM_OPTS="$JVM_OPTS
-Djavax.net.ssl.trustStore=/submit/cassandra/ssl/server-truststore.jks"
JVM_OPTS="$JVM_OPTS -Djavax.net.ssl.trustStorePassword=cassandra"
fi
{noformat}
> Enabling remote JMX fails to start
> --
>
> Key: CASSANDRA-19453
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19453
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Brandon Williams
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
>
> If you set LOCAL_JMX to something other than 'yes' in conf/cassandra-env.sh,
> you receive:
> {noformat}
> Exception (java.lang.ExceptionInInitializerError) encountered during startup:
> null
> java.lang.ExceptionInInitializerError
> at
> org.apache.cassandra.utils.JMXServerUtils.configureJmxAuthentication(JMXServerUtils.java:188)
> at
> org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:106)
> at
> org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:154)
> at
> org.apache.cassandra.service.CassandraDaemon.maybeInitJmx(CassandraDaemon.java:172)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:240)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:721)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:855)
> Caused by: java.lang.RuntimeException: java.lang.IllegalAccessException:
> access to public member failed:
> com.sun.jmx.remote.security.JMXPluggableAuthenticator.[Ljava.lang.Object;@afb5821/invokeSpecial,
> from class
> org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper
> (unnamed module @51dcb805)
> at
> org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper.(JMXServerUtils.java:306)
> ... 7 more
> Caused by: java.lang.IllegalAccessException: access to public member failed:
> com.sun.jmx.remote.security.JMXPluggableAuthenticator.[Ljava.lang.Object;@afb5821/invokeSpecial,
> from class
> org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper
> (unnamed module @51dcb805)
> at
> java.base/java.lang.invoke.MemberName.makeAccessException(MemberName.java:955)
> at
> java.base/java.lang.invoke.MethodHandles$Lookup.checkAccess(MethodHandles.java:3882)
> at
> java.base/java.lang.invoke.MethodHandles$Lookup.getDirectConstructorCommon(MethodHandles.java:4117)
> at
> java.base/java.lang.invoke.MethodHandles$Lookup.getDirectConstructorNoSecurityManager(MethodHandles.java:4111)
> at
> java.base/java.lang.invoke.MethodHandles$Lookup.unreflectConstructor(MethodHandles.java:3433)
> at
> org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper.(JMXServerUtils.java:302)
> ... 7 more
> ERROR [main] 2024-03-01 06:16:00,028 CassandraDaemon.java:877 -
[jira] [Commented] (CASSANDRA-19453) Enabling remote JMX fails to start
[
https://issues.apache.org/jira/browse/CASSANDRA-19453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17822563#comment-17822563
]
Stefan Miklosovic commented on CASSANDRA-19453:
---
I just can't reproduce it.
When I set "LOCAL_JMX=baz" in cassandra-env.sh before "if [ "x$LOCAL_JMX" = "x"
]; then", then it will not be set to "yes" because it is not empty. Then if it
is not "yes" but "baz" it will go to else branch in the next if-else.
Node starts fine, then doing "nodetool status" will do
{noformat}
$ ./bin/nodetool status
error: Authentication failed! Credentials required
-- StackTrace --
java.lang.SecurityException: Authentication failed! Credentials required
at
java.management/com.sun.jmx.remote.security.JMXPluggableAuthenticator.authenticationFailure(JMXPluggableAuthenticator.java:212)
at
java.management/com.sun.jmx.remote.security.JMXPluggableAuthenticator.authenticate(JMXPluggableAuthenticator.java:164)
at
org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper.authenticate(JMXServerUtils.java:321)
at
java.management.rmi/javax.management.remote.rmi.RMIServerImpl.doNewClient(RMIServerImpl.java:231)
at
java.management.rmi/javax.management.remote.rmi.RMIServerImpl.newClient(RMIServerImpl.java:198)
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
java.rmi/sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:359)
at java.rmi/sun.rmi.transport.Transport$1.run(Transport.java:200)
at java.rmi/sun.rmi.transport.Transport$1.run(Transport.java:197)
at java.base/java.security.AccessController.doPrivileged(Native Method)
at java.rmi/sun.rmi.transport.Transport.serviceCall(Transport.java:196)
at
java.rmi/sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:562)
at
java.rmi/sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:796)
at
java.rmi/sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:677)
at java.base/java.security.AccessController.doPrivileged(Native Method)
at
java.rmi/sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:676)
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:829)
{noformat}
> Enabling remote JMX fails to start
> --
>
> Key: CASSANDRA-19453
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19453
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Brandon Williams
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
>
> If you set LOCAL_JMX to something other than 'yes' in conf/cassandra-env.sh,
> you receive:
> {noformat}
> Exception (java.lang.ExceptionInInitializerError) encountered during startup:
> null
> java.lang.ExceptionInInitializerError
> at
> org.apache.cassandra.utils.JMXServerUtils.configureJmxAuthentication(JMXServerUtils.java:188)
> at
> org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:106)
> at
> org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:154)
> at
> org.apache.cassandra.service.CassandraDaemon.maybeInitJmx(CassandraDaemon.java:172)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:240)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:721)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:855)
> Caused by: java.lang.RuntimeException: java.lang.IllegalAccessException:
> access to public member failed:
> com.sun.jmx.remote.security.JMXPluggableAuthenticator.[Ljava.lang.Object;@afb5821/invokeSpecial,
> from class
> org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper
> (unnamed module @51dcb805)
> at
> org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper.(JMXServerUtils.java:306)
> ... 7 more
> Caused by: java.lang.IllegalAccessException: access to public member failed:
> com.sun.jmx.remote.security.JMXPluggableAuthenticator.[Ljava.lang.Object;@afb5821/invokeSpecial,
> from class
>
[jira] [Assigned] (CASSANDRA-19453) Enabling remote JMX fails to start
[
https://issues.apache.org/jira/browse/CASSANDRA-19453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic reassigned CASSANDRA-19453:
-
Assignee: Stefan Miklosovic
> Enabling remote JMX fails to start
> --
>
> Key: CASSANDRA-19453
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19453
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Brandon Williams
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
>
> If you set LOCAL_JMX to something other than 'yes' in conf/cassandra-env.sh,
> you receive:
> {noformat}
> Exception (java.lang.ExceptionInInitializerError) encountered during startup:
> null
> java.lang.ExceptionInInitializerError
> at
> org.apache.cassandra.utils.JMXServerUtils.configureJmxAuthentication(JMXServerUtils.java:188)
> at
> org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:106)
> at
> org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:154)
> at
> org.apache.cassandra.service.CassandraDaemon.maybeInitJmx(CassandraDaemon.java:172)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:240)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:721)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:855)
> Caused by: java.lang.RuntimeException: java.lang.IllegalAccessException:
> access to public member failed:
> com.sun.jmx.remote.security.JMXPluggableAuthenticator.[Ljava.lang.Object;@afb5821/invokeSpecial,
> from class
> org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper
> (unnamed module @51dcb805)
> at
> org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper.(JMXServerUtils.java:306)
> ... 7 more
> Caused by: java.lang.IllegalAccessException: access to public member failed:
> com.sun.jmx.remote.security.JMXPluggableAuthenticator.[Ljava.lang.Object;@afb5821/invokeSpecial,
> from class
> org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper
> (unnamed module @51dcb805)
> at
> java.base/java.lang.invoke.MemberName.makeAccessException(MemberName.java:955)
> at
> java.base/java.lang.invoke.MethodHandles$Lookup.checkAccess(MethodHandles.java:3882)
> at
> java.base/java.lang.invoke.MethodHandles$Lookup.getDirectConstructorCommon(MethodHandles.java:4117)
> at
> java.base/java.lang.invoke.MethodHandles$Lookup.getDirectConstructorNoSecurityManager(MethodHandles.java:4111)
> at
> java.base/java.lang.invoke.MethodHandles$Lookup.unreflectConstructor(MethodHandles.java:3433)
> at
> org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper.(JMXServerUtils.java:302)
> ... 7 more
> ERROR [main] 2024-03-01 06:16:00,028 CassandraDaemon.java:877 - Exception
> encountered during startup
> java.lang.ExceptionInInitializerError: null
> at
> org.apache.cassandra.utils.JMXServerUtils.configureJmxAuthentication(JMXServerUtils.java:188)
> at
> org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:106)
> at
> org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:154)
> at
> org.apache.cassandra.service.CassandraDaemon.maybeInitJmx(CassandraDaemon.java:172)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:240)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:721)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:855)
> Caused by: java.lang.RuntimeException: java.lang.IllegalAccessException:
> access to public member failed:
> com.sun.jmx.remote.security.JMXPluggableAuthenticator.[Ljava.lang.Object;@afb5821/invokeSpecial,
> from class
> org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper
> (unnamed module @51dcb805)
> at
> org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper.(JMXServerUtils.java:306)
> ... 7 common frames omitted
> Caused by: java.lang.IllegalAccessException: access to public member failed:
> com.sun.jmx.remote.security.JMXPluggableAuthenticator.[Ljava.lang.Object;@afb5821/invokeSpecial,
> from class
> org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper
> (unnamed module @51dcb805)
> at
> java.base/java.lang.invoke.MemberName.makeAccessException(MemberName.java:955)
> at
> java.base/java.lang.invoke.MethodHandles$Lookup.checkAccess(MethodHandles.java:3882)
> at
>
[jira] [Updated] (CASSANDRA-19453) Enabling remote JMX fails to start
[
https://issues.apache.org/jira/browse/CASSANDRA-19453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-19453:
-
Bug Category: Parent values: Availability(12983)Level 1 values: Process
Crash(12992)
Complexity: Normal
Component/s: Local/Config
Discovered By: User Report
Fix Version/s: 5.0-rc
5.x
Severity: Normal
Status: Open (was: Triage Needed)
> Enabling remote JMX fails to start
> --
>
> Key: CASSANDRA-19453
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19453
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Brandon Williams
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
>
> If you set LOCAL_JMX to something other than 'yes' in conf/cassandra-env.sh,
> you receive:
> {noformat}
> Exception (java.lang.ExceptionInInitializerError) encountered during startup:
> null
> java.lang.ExceptionInInitializerError
> at
> org.apache.cassandra.utils.JMXServerUtils.configureJmxAuthentication(JMXServerUtils.java:188)
> at
> org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:106)
> at
> org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:154)
> at
> org.apache.cassandra.service.CassandraDaemon.maybeInitJmx(CassandraDaemon.java:172)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:240)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:721)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:855)
> Caused by: java.lang.RuntimeException: java.lang.IllegalAccessException:
> access to public member failed:
> com.sun.jmx.remote.security.JMXPluggableAuthenticator.[Ljava.lang.Object;@afb5821/invokeSpecial,
> from class
> org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper
> (unnamed module @51dcb805)
> at
> org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper.(JMXServerUtils.java:306)
> ... 7 more
> Caused by: java.lang.IllegalAccessException: access to public member failed:
> com.sun.jmx.remote.security.JMXPluggableAuthenticator.[Ljava.lang.Object;@afb5821/invokeSpecial,
> from class
> org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper
> (unnamed module @51dcb805)
> at
> java.base/java.lang.invoke.MemberName.makeAccessException(MemberName.java:955)
> at
> java.base/java.lang.invoke.MethodHandles$Lookup.checkAccess(MethodHandles.java:3882)
> at
> java.base/java.lang.invoke.MethodHandles$Lookup.getDirectConstructorCommon(MethodHandles.java:4117)
> at
> java.base/java.lang.invoke.MethodHandles$Lookup.getDirectConstructorNoSecurityManager(MethodHandles.java:4111)
> at
> java.base/java.lang.invoke.MethodHandles$Lookup.unreflectConstructor(MethodHandles.java:3433)
> at
> org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper.(JMXServerUtils.java:302)
> ... 7 more
> ERROR [main] 2024-03-01 06:16:00,028 CassandraDaemon.java:877 - Exception
> encountered during startup
> java.lang.ExceptionInInitializerError: null
> at
> org.apache.cassandra.utils.JMXServerUtils.configureJmxAuthentication(JMXServerUtils.java:188)
> at
> org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:106)
> at
> org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:154)
> at
> org.apache.cassandra.service.CassandraDaemon.maybeInitJmx(CassandraDaemon.java:172)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:240)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:721)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:855)
> Caused by: java.lang.RuntimeException: java.lang.IllegalAccessException:
> access to public member failed:
> com.sun.jmx.remote.security.JMXPluggableAuthenticator.[Ljava.lang.Object;@afb5821/invokeSpecial,
> from class
> org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper
> (unnamed module @51dcb805)
> at
> org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper.(JMXServerUtils.java:306)
> ... 7 common frames omitted
> Caused by: java.lang.IllegalAccessException: access to public member failed:
> com.sun.jmx.remote.security.JMXPluggableAuthenticator.[Ljava.lang.Object;@afb5821/invokeSpecial,
> from class
> org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper
> (unnamed module @51dcb805)
> at
>
[jira] [Created] (CASSANDRA-19453) Enabling remote JMX fails to start
Brandon Williams created CASSANDRA-19453:
Summary: Enabling remote JMX fails to start
Key: CASSANDRA-19453
URL: https://issues.apache.org/jira/browse/CASSANDRA-19453
Project: Cassandra
Issue Type: Bug
Reporter: Brandon Williams
If you set LOCAL_JMX to something other than 'yes' in conf/cassandra-env.sh,
you receive:
{noformat}
Exception (java.lang.ExceptionInInitializerError) encountered during startup:
null
java.lang.ExceptionInInitializerError
at
org.apache.cassandra.utils.JMXServerUtils.configureJmxAuthentication(JMXServerUtils.java:188)
at
org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:106)
at
org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:154)
at
org.apache.cassandra.service.CassandraDaemon.maybeInitJmx(CassandraDaemon.java:172)
at
org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:240)
at
org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:721)
at
org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:855)
Caused by: java.lang.RuntimeException: java.lang.IllegalAccessException: access
to public member failed:
com.sun.jmx.remote.security.JMXPluggableAuthenticator.[Ljava.lang.Object;@afb5821/invokeSpecial,
from class
org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper
(unnamed module @51dcb805)
at
org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper.(JMXServerUtils.java:306)
... 7 more
Caused by: java.lang.IllegalAccessException: access to public member failed:
com.sun.jmx.remote.security.JMXPluggableAuthenticator.[Ljava.lang.Object;@afb5821/invokeSpecial,
from class
org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper
(unnamed module @51dcb805)
at
java.base/java.lang.invoke.MemberName.makeAccessException(MemberName.java:955)
at
java.base/java.lang.invoke.MethodHandles$Lookup.checkAccess(MethodHandles.java:3882)
at
java.base/java.lang.invoke.MethodHandles$Lookup.getDirectConstructorCommon(MethodHandles.java:4117)
at
java.base/java.lang.invoke.MethodHandles$Lookup.getDirectConstructorNoSecurityManager(MethodHandles.java:4111)
at
java.base/java.lang.invoke.MethodHandles$Lookup.unreflectConstructor(MethodHandles.java:3433)
at
org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper.(JMXServerUtils.java:302)
... 7 more
ERROR [main] 2024-03-01 06:16:00,028 CassandraDaemon.java:877 - Exception
encountered during startup
java.lang.ExceptionInInitializerError: null
at
org.apache.cassandra.utils.JMXServerUtils.configureJmxAuthentication(JMXServerUtils.java:188)
at
org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:106)
at
org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:154)
at
org.apache.cassandra.service.CassandraDaemon.maybeInitJmx(CassandraDaemon.java:172)
at
org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:240)
at
org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:721)
at
org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:855)
Caused by: java.lang.RuntimeException: java.lang.IllegalAccessException: access
to public member failed:
com.sun.jmx.remote.security.JMXPluggableAuthenticator.[Ljava.lang.Object;@afb5821/invokeSpecial,
from class
org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper
(unnamed module @51dcb805)
at
org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper.(JMXServerUtils.java:306)
... 7 common frames omitted
Caused by: java.lang.IllegalAccessException: access to public member failed:
com.sun.jmx.remote.security.JMXPluggableAuthenticator.[Ljava.lang.Object;@afb5821/invokeSpecial,
from class
org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper
(unnamed module @51dcb805)
at
java.base/java.lang.invoke.MemberName.makeAccessException(MemberName.java:955)
at
java.base/java.lang.invoke.MethodHandles$Lookup.checkAccess(MethodHandles.java:3882)
at
java.base/java.lang.invoke.MethodHandles$Lookup.getDirectConstructorCommon(MethodHandles.java:4117)
at
java.base/java.lang.invoke.MethodHandles$Lookup.getDirectConstructorNoSecurityManager(MethodHandles.java:4111)
at
java.base/java.lang.invoke.MethodHandles$Lookup.unreflectConstructor(MethodHandles.java:3433)
at
org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper.(JMXServerUtils.java:302)
... 7 common frames omitted
{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CASSANDRA-19393) nodetool: group CMS-related commands into one command
[ https://issues.apache.org/jira/browse/CASSANDRA-19393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Petrov updated CASSANDRA-19393: Reviewers: Alex Petrov Status: Review In Progress (was: Needs Committer) > nodetool: group CMS-related commands into one command > - > > Key: CASSANDRA-19393 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19393 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool, Transactional Cluster Metadata >Reporter: n.v.harikrishna >Assignee: n.v.harikrishna >Priority: Normal > Fix For: 5.x > > Time Spent: 1.5h > Remaining Estimate: 0h > > The purpose of this ticket is to group all CMS-related commands under one > "nodetool cms" command where existing command would be subcommands of it. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19393) nodetool: group CMS-related commands into one command
[ https://issues.apache.org/jira/browse/CASSANDRA-19393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-19393: -- Epic Link: CASSANDRA-19055 > nodetool: group CMS-related commands into one command > - > > Key: CASSANDRA-19393 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19393 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool, Transactional Cluster Metadata >Reporter: n.v.harikrishna >Assignee: n.v.harikrishna >Priority: Normal > Fix For: 5.x > > Time Spent: 1.5h > Remaining Estimate: 0h > > The purpose of this ticket is to group all CMS-related commands under one > "nodetool cms" command where existing command would be subcommands of it. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19393) nodetool: group CMS-related commands into one command
[ https://issues.apache.org/jira/browse/CASSANDRA-19393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-19393: -- Reviewers: (was: Stefan Miklosovic) > nodetool: group CMS-related commands into one command > - > > Key: CASSANDRA-19393 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19393 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool, Transactional Cluster Metadata >Reporter: n.v.harikrishna >Assignee: n.v.harikrishna >Priority: Normal > Fix For: 5.x > > Time Spent: 1.5h > Remaining Estimate: 0h > > The purpose of this ticket is to group all CMS-related commands under one > "nodetool cms" command where existing command would be subcommands of it. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19393) nodetool: group CMS-related commands into one command
[ https://issues.apache.org/jira/browse/CASSANDRA-19393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17822519#comment-17822519 ] Stefan Miklosovic commented on CASSANDRA-19393: --- I dont think this will be reviewed anytime soon. > nodetool: group CMS-related commands into one command > - > > Key: CASSANDRA-19393 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19393 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool, Transactional Cluster Metadata >Reporter: n.v.harikrishna >Assignee: n.v.harikrishna >Priority: Normal > Fix For: 5.x > > Time Spent: 1.5h > Remaining Estimate: 0h > > The purpose of this ticket is to group all CMS-related commands under one > "nodetool cms" command where existing command would be subcommands of it. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-19374) CompactionStress tool write data cannot work because of new TCM feature
[
https://issues.apache.org/jira/browse/CASSANDRA-19374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ling Mao reassigned CASSANDRA-19374:
Assignee: Ling Mao
> CompactionStress tool write data cannot work because of new TCM feature
> ---
>
> Key: CASSANDRA-19374
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19374
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/stress, Transactional Cluster Metadata
>Reporter: Ling Mao
>Assignee: Ling Mao
>Priority: Normal
> Fix For: 5.1
>
> Attachments: compactstree_tcm_code_diff.txt
>
>
> CompactionStress tool write data cannot work anymore because of new TCM
> feature
> {code:java}
> ./compaction-stress write -d /tmp/compaction -g 5 -p
> ../cqlstress-example.yaml -t 4
> Cannot write anything to the disk{code}
> It was introduced by the Patch: CEP-21. After applying that patch, this tool
> cannot work
> anymore
> {code:java}
> Implementation of Transactional Cluster Metadata as described in CEP-21
> Hash: ae084237
> {code}
> I attach some key code related diff for further debugging
--
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-19103) Filter replicas for counter mutation leader to be JOINED replicas to decouple from RPC_READY state
[ https://issues.apache.org/jira/browse/CASSANDRA-19103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17822455#comment-17822455 ] Stefan Miklosovic commented on CASSANDRA-19103: --- test_counter_leader_with_partial_view is not broken anymore, I can not reproduce the failure in CI nor locally. I think I just had to wait until TCM impl somehow "stabilizes" and this just seems to auto-resolve. dtest: https://github.com/apache/cassandra-dtest/pull/246 branch: https://github.com/apache/cassandra/pull/2934 > Filter replicas for counter mutation leader to be JOINED replicas to decouple > from RPC_READY state > -- > > Key: CASSANDRA-19103 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19103 > Project: Cassandra > Issue Type: Improvement > Components: Transactional Cluster Metadata >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 5.x > > Time Spent: 1h 20m > Remaining Estimate: 0h > > In CASSANDRA-18935, what I did was that if transport is turned off while node > is up, it will set RPC_READY to "false". Before 18935 was in, if you turned > off transport while node was up and transport was on, RPC_READY was not > changed to false but it stayed to be "true" for ever. > Clearly, this was wrong, so I fixed that, but when I did that, the code which > decides who will be the leader of counter mutation was broken, because that > node filtered out all nodes for which RPC_READY is false, which never > happened before, because nobody has set it to "false" on turned off transport. > So, we decided to revert this regression in 5.0-rc1 and I was waiting for > CEP-21 to be in because I saw it is rewritten there with TODO to filter > JOINED nodes. > Hence, we can decouple this logic and fix RPC_READY status finally. -- 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-19103) Filter replicas for counter mutation leader to be JOINED replicas to decouple from RPC_READY state
[ https://issues.apache.org/jira/browse/CASSANDRA-19103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-19103: -- Status: Needs Committer (was: Patch Available) > Filter replicas for counter mutation leader to be JOINED replicas to decouple > from RPC_READY state > -- > > Key: CASSANDRA-19103 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19103 > Project: Cassandra > Issue Type: Improvement > Components: Transactional Cluster Metadata >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 5.x > > Time Spent: 1h 20m > Remaining Estimate: 0h > > In CASSANDRA-18935, what I did was that if transport is turned off while node > is up, it will set RPC_READY to "false". Before 18935 was in, if you turned > off transport while node was up and transport was on, RPC_READY was not > changed to false but it stayed to be "true" for ever. > Clearly, this was wrong, so I fixed that, but when I did that, the code which > decides who will be the leader of counter mutation was broken, because that > node filtered out all nodes for which RPC_READY is false, which never > happened before, because nobody has set it to "false" on turned off transport. > So, we decided to revert this regression in 5.0-rc1 and I was waiting for > CEP-21 to be in because I saw it is rewritten there with TODO to filter > JOINED nodes. > Hence, we can decouple this logic and fix RPC_READY status finally. -- 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-19103) Filter replicas for counter mutation leader to be JOINED replicas to decouple from RPC_READY state
[ https://issues.apache.org/jira/browse/CASSANDRA-19103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-19103: -- Status: Patch Available (was: In Progress) > Filter replicas for counter mutation leader to be JOINED replicas to decouple > from RPC_READY state > -- > > Key: CASSANDRA-19103 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19103 > Project: Cassandra > Issue Type: Improvement > Components: Transactional Cluster Metadata >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 5.x > > Time Spent: 1h 20m > Remaining Estimate: 0h > > In CASSANDRA-18935, what I did was that if transport is turned off while node > is up, it will set RPC_READY to "false". Before 18935 was in, if you turned > off transport while node was up and transport was on, RPC_READY was not > changed to false but it stayed to be "true" for ever. > Clearly, this was wrong, so I fixed that, but when I did that, the code which > decides who will be the leader of counter mutation was broken, because that > node filtered out all nodes for which RPC_READY is false, which never > happened before, because nobody has set it to "false" on turned off transport. > So, we decided to revert this regression in 5.0-rc1 and I was waiting for > CEP-21 to be in because I saw it is rewritten there with TODO to filter > JOINED nodes. > Hence, we can decouple this logic and fix RPC_READY status finally. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] (CASSANDRA-19103) Filter replicas for counter mutation leader to be JOINED replicas to decouple from RPC_READY state
[ https://issues.apache.org/jira/browse/CASSANDRA-19103 ]
Stefan Miklosovic deleted comment on CASSANDRA-19103:
---
was (Author: smiklosovic):
[CASSANDRA-19103|https://github.com/instaclustr/cassandra/tree/CASSANDRA-19103]
{noformat}
java17_pre-commit_tests
java17_separate_tests
java11_pre-commit_tests
java11_separate_tests
{noformat}
[java17_pre-commit_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/3944/workflows/979e3a49-6ffc-4c0a-9551-8d6f6b250851]
[java17_separate_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/3944/workflows/79303764-d8ac-46e0-b82f-ebc38dd299f2]
[java11_pre-commit_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/3944/workflows/5c9ec875-57ff-4949-a4cf-d7c5ea9a9b1d]
[java11_separate_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/3944/workflows/44af98f2-8eb8-414b-887e-27c4619e34aa]
> Filter replicas for counter mutation leader to be JOINED replicas to decouple
> from RPC_READY state
> --
>
> Key: CASSANDRA-19103
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19103
> Project: Cassandra
> Issue Type: Improvement
> Components: Transactional Cluster Metadata
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> In CASSANDRA-18935, what I did was that if transport is turned off while node
> is up, it will set RPC_READY to "false". Before 18935 was in, if you turned
> off transport while node was up and transport was on, RPC_READY was not
> changed to false but it stayed to be "true" for ever.
> Clearly, this was wrong, so I fixed that, but when I did that, the code which
> decides who will be the leader of counter mutation was broken, because that
> node filtered out all nodes for which RPC_READY is false, which never
> happened before, because nobody has set it to "false" on turned off transport.
> So, we decided to revert this regression in 5.0-rc1 and I was waiting for
> CEP-21 to be in because I saw it is rewritten there with TODO to filter
> JOINED nodes.
> Hence, we can decouple this logic and fix RPC_READY status finally.
--
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-19103) Filter replicas for counter mutation leader to be JOINED replicas to decouple from RPC_READY state
[
https://issues.apache.org/jira/browse/CASSANDRA-19103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17822449#comment-17822449
]
Stefan Miklosovic commented on CASSANDRA-19103:
---
[CASSANDRA-19103|https://github.com/instaclustr/cassandra/tree/CASSANDRA-19103]
{noformat}
java17_pre-commit_tests
java17_separate_tests
java11_pre-commit_tests
java11_separate_tests
{noformat}
[java17_pre-commit_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/3944/workflows/979e3a49-6ffc-4c0a-9551-8d6f6b250851]
[java17_separate_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/3944/workflows/79303764-d8ac-46e0-b82f-ebc38dd299f2]
[java11_pre-commit_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/3944/workflows/5c9ec875-57ff-4949-a4cf-d7c5ea9a9b1d]
[java11_separate_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/3944/workflows/44af98f2-8eb8-414b-887e-27c4619e34aa]
> Filter replicas for counter mutation leader to be JOINED replicas to decouple
> from RPC_READY state
> --
>
> Key: CASSANDRA-19103
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19103
> Project: Cassandra
> Issue Type: Improvement
> Components: Transactional Cluster Metadata
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> In CASSANDRA-18935, what I did was that if transport is turned off while node
> is up, it will set RPC_READY to "false". Before 18935 was in, if you turned
> off transport while node was up and transport was on, RPC_READY was not
> changed to false but it stayed to be "true" for ever.
> Clearly, this was wrong, so I fixed that, but when I did that, the code which
> decides who will be the leader of counter mutation was broken, because that
> node filtered out all nodes for which RPC_READY is false, which never
> happened before, because nobody has set it to "false" on turned off transport.
> So, we decided to revert this regression in 5.0-rc1 and I was waiting for
> CEP-21 to be in because I saw it is rewritten there with TODO to filter
> JOINED nodes.
> Hence, we can decouple this logic and fix RPC_READY status finally.
--
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
