Re: [PR] JAVA-3131: Add #retrieve method to EndPoint for when caller does not … [cassandra-java-driver]
SiyaoIsHiding commented on PR #1735: URL: https://github.com/apache/cassandra-java-driver/pull/1735#issuecomment-1996315515 Work taken over to https://github.com/apache/cassandra-java-driver/pull/1919 -- 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
[PR] JAVA-3131: Add #retrieve method to EndPoint for when caller does not... [cassandra-java-driver]
SiyaoIsHiding opened a new pull request, #1919: URL: https://github.com/apache/cassandra-java-driver/pull/1919 …need the endpoint to be proactively resolved Refactor existing usages of EndPoint#resolve to use retrieve when resolved ip addresses are not needed. Taken over from https://github.com/apache/cassandra-java-driver/pull/1735. -- 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] JAVA-3131: Add #retrieve method to EndPoint for when caller does not … [cassandra-java-driver]
SiyaoIsHiding commented on code in PR #1735:
URL:
https://github.com/apache/cassandra-java-driver/pull/1735#discussion_r1524149783
##
core/src/test/java/com/datastax/oss/driver/internal/core/metadata/SniEndPointTest.java:
##
@@ -0,0 +1,142 @@
+/*
+ * 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 com.datastax.oss.driver.internal.core.metadata;
+
+import static com.datastax.oss.driver.Assertions.assertThat;
+import static org.assertj.core.api.Assertions.assertThatCode;
+import static org.mockito.Mockito.doReturn;
+import static org.mockito.Mockito.doThrow;
+
+import java.net.InetAddress;
+import java.net.InetSocketAddress;
+import java.net.UnknownHostException;
+import java.util.Arrays;
+import java.util.stream.Stream;
+import org.apache.commons.lang3.ArrayUtils;
+import org.junit.Test;
+import org.junit.runner.RunWith;
+import org.mockito.Spy;
+import org.mockito.junit.MockitoJUnitRunner;
+
+@RunWith(MockitoJUnitRunner.class)
+public class SniEndPointTest {
+ private static InetSocketAddress SNI_ADDRESS =
+ InetSocketAddress.createUnresolved("unittest.host", 12345);
+ private static String SERVER_NAME = "unittest.server.name";
+
+ @Spy private SniEndPoint sniEndPoint = new SniEndPoint(SNI_ADDRESS,
SERVER_NAME);
+
+ private static InetAddress[] createAddresses(String... addrs) {
+return Stream.of(addrs)
+.map(
+addr -> {
+ try {
+int[] comp =
Arrays.stream(addr.split("\\.")).mapToInt(Integer::parseInt).toArray();
+return InetAddress.getByAddress(
+new byte[] {(byte) comp[0], (byte) comp[1], (byte)
comp[2], (byte) comp[3]});
Review Comment:
Sorry, I am confused. Could you pls explain more?
`InetAddress.getByAddress` does not do reverse lookup.
`InetAddress.getByName` will look it up. We don't want it to look up.
Therefore, I think `InetAddress.getByAddress` is the one we should use. :)
--
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] [Comment Edited] (CASSANDRA-19428) Clean up KeyRangeIterator classes
[
https://issues.apache.org/jira/browse/CASSANDRA-19428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17826905#comment-17826905
]
Ekaterina Dimitrova edited comment on CASSANDRA-19428 at 3/14/24 1:28 AM:
--
To put breakpoints and debug I need to raise range_request_timeout and enable
SAI_TEST_DISABLE_TIMEOUT.
I noticed in the artifacts logs that there is a strong self-ref loop detected.
(not too surprising, there is also CASSANDRA-19222). However, I have not seen
that leak locally so far.
I decided to apply the patch to 5.0. This is from the 5.0 run where the test
fails simply with read timeout.
[https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2667/workflows/29de6ee7-dd02-4da2-88eb-1e670ef75288]
(the dtest failures seem to be OS error, environmental, we've seen this
before, ignore them)
{code:java}
com.datastax.driver.core.exceptions.ReadTimeoutException: Cassandra timeout
during read query at consistency LOCAL_ONE (1 responses were required but only
0 replica responded). In case this was generated during read repair, the
consistency level is not representative of the actual consistency.{code}
I am planning to spend more time on 5.0 as it seems it would be easier to find
out the problem and then move to trunk where there might be more than 1 problem
and not only from my patch (?)
was (Author: e.dimitrova):
To put breakpoints and debug I need to raise range_request_timeout and enable
SAI_TEST_DISABLE_TIMEOUT.
I noticed in the artifacts logs that there is a strong self-ref loop detected.
(not too surprising, there is also CASSANDRA-19222). However, I have not seen
that leak locally so far.
I decided to apply the patch to 5.0. This is from the 5.0 run where the test
fails simply with read timeout, even without raising any timeouts, etc.
[https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2667/workflows/29de6ee7-dd02-4da2-88eb-1e670ef75288]
(the dtest failures seem to be OS error, environmental, we've seen this
before, ignore them)
{code:java}
com.datastax.driver.core.exceptions.ReadTimeoutException: Cassandra timeout
during read query at consistency LOCAL_ONE (1 responses were required but only
0 replica responded). In case this was generated during read repair, the
consistency level is not representative of the actual consistency.{code}
I am planning to spend more time on 5.0 as it seems it would be easier to find
out the problem and then move to trunk where there might be more than 1 problem
and not only from my patch (?)
> Clean up KeyRangeIterator classes
> -
>
> Key: CASSANDRA-19428
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19428
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/2i Index
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Low
> Fix For: 5.0.x, 5.x
>
>
> Remove KeyRangeIterator.current and simplify
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-19428) Clean up KeyRangeIterator classes
[
https://issues.apache.org/jira/browse/CASSANDRA-19428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17826905#comment-17826905
]
Ekaterina Dimitrova edited comment on CASSANDRA-19428 at 3/14/24 12:57 AM:
---
To put breakpoints and debug I need to raise range_request_timeout and enable
SAI_TEST_DISABLE_TIMEOUT.
I noticed in the artifacts logs that there is a strong self-ref loop detected.
(not too surprising, there is also CASSANDRA-19222). However, I have not seen
that leak locally so far.
I decided to apply the patch to 5.0. This is from the 5.0 run where the test
fails simply with read timeout, even without raising any timeouts, etc.
[https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2667/workflows/29de6ee7-dd02-4da2-88eb-1e670ef75288]
(the dtest failures seem to be OS error, environmental, we've seen this
before, ignore them)
{code:java}
com.datastax.driver.core.exceptions.ReadTimeoutException: Cassandra timeout
during read query at consistency LOCAL_ONE (1 responses were required but only
0 replica responded). In case this was generated during read repair, the
consistency level is not representative of the actual consistency.{code}
I am planning to spend more time on 5.0 as it seems it would be easier to find
out the problem and then move to trunk where there might be more than 1 problem
and not only from my patch (?)
was (Author: e.dimitrova):
To put breakpoints and debug I need to raise range_request_timeout and enable
SAI_TEST_DISABLE_TIMEOUT.
I noticed in the artifacts logs that there is a strong self-ref loop detected.
(not too surprising, there is also CASSANDRA-19222). However, I have not seen
that leak locally so far.
I decided to apply the patch to 5.0. This is from the 5.0 run where the test
fails simply with read timeout, even without raising any timeouts, etc.
[https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2667/workflows/29de6ee7-dd02-4da2-88eb-1e670ef75288]
(the dtest failures seem to be OS error, environmental, we've seen this
before, ignore them)
{code:java}
com.datastax.driver.core.exceptions.ReadTimeoutException: Cassandra timeout
during read query at consistency LOCAL_ONE (1 responses were required but only
0 replica responded). In case this was generated during read repair, the
consistency level is not representative of the actual consistency.{code}
I am planning to spend more time on 5.0 as it seems it would be easier to find
out the problem and then move to trunk where there might be more than 1 problem
and not only from my patch?
> Clean up KeyRangeIterator classes
> -
>
> Key: CASSANDRA-19428
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19428
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/2i Index
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Low
> Fix For: 5.x
>
>
> Remove KeyRangeIterator.current and simplify
--
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-19428) Clean up KeyRangeIterator classes
[ https://issues.apache.org/jira/browse/CASSANDRA-19428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-19428: Fix Version/s: 5.0.x > Clean up KeyRangeIterator classes > - > > Key: CASSANDRA-19428 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19428 > Project: Cassandra > Issue Type: Improvement > Components: Feature/2i Index >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Low > Fix For: 5.0.x, 5.x > > > Remove KeyRangeIterator.current and simplify -- 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-19428) Clean up KeyRangeIterator classes
[
https://issues.apache.org/jira/browse/CASSANDRA-19428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17826905#comment-17826905
]
Ekaterina Dimitrova commented on CASSANDRA-19428:
-
To put breakpoints and debug I need to raise range_request_timeout and enable
SAI_TEST_DISABLE_TIMEOUT.
I noticed in the artifacts logs that there is a strong self-ref loop detected.
(not too surprising, there is also CASSANDRA-19222). However, I have not seen
that leak locally so far.
I decided to apply the patch to 5.0. This is from the 5.0 run where the test
fails simply with read timeout, even without raising any timeouts, etc.
[https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2667/workflows/29de6ee7-dd02-4da2-88eb-1e670ef75288]
(the dtest failures seem to be OS error, environmental, we've seen this
before, ignore them)
{code:java}
com.datastax.driver.core.exceptions.ReadTimeoutException: Cassandra timeout
during read query at consistency LOCAL_ONE (1 responses were required but only
0 replica responded). In case this was generated during read repair, the
consistency level is not representative of the actual consistency.{code}
I am planning to spend more time on 5.0 as it seems it would be easier to find
out the problem and then move to trunk where there might be more than 1 problem
and not only from my patch?
> Clean up KeyRangeIterator classes
> -
>
> Key: CASSANDRA-19428
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19428
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/2i Index
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Low
> Fix For: 5.x
>
>
> Remove KeyRangeIterator.current and simplify
--
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-19468) In some situations MetadataManager.SingleThreaded.startSchemaRequest could fail to set CompletableFuture arg
[
https://issues.apache.org/jira/browse/CASSANDRA-19468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17826896#comment-17826896
]
Bret McGuire commented on CASSANDRA-19468:
--
If we could get to a test case that would repro this as well that would be
fantastic!
> In some situations MetadataManager.SingleThreaded.startSchemaRequest could
> fail to set CompletableFuture arg
>
>
> Key: CASSANDRA-19468
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19468
> Project: Cassandra
> Issue Type: Bug
> Components: Client/java-driver
>Reporter: Bret McGuire
>Assignee: Henry Hughes
>Priority: Normal
>
> Relevant code is:
>
>
> {code:java}
> private void startSchemaRequest(CompletableFuture
> refreshFuture) {
> assert adminExecutor.inEventLoop();
> if (closeWasCalled) {
> refreshFuture.complete(new RefreshSchemaResult(metadata));
> return;
> }
> if (currentSchemaRefresh == null) {
> currentSchemaRefresh = refreshFuture;
> LOG.debug("[{}] Starting schema refresh", logPrefix);
> initControlConnectionForSchema()
> .thenCompose(v -> context.getTopologyMonitor().checkSchemaAgreement())
> .whenComplete(
> (schemaInAgreement, agreementError) -> {
> if (agreementError != null) {
> refreshFuture.completeExceptionally(agreementError);
> } else {
> schemaQueriesFactory
> .newInstance()
> .execute()
> .thenApplyAsync(this::parseAndApplySchemaRows,
> adminExecutor)
> .whenComplete(
> (newMetadata, metadataError) -> {
> if (metadataError != null) {
>
> refreshFuture.completeExceptionally(metadataError);
> } else {
> refreshFuture.complete(
> new RefreshSchemaResult(newMetadata,
> schemaInAgreement));
> }
> ...{code}
>
>
> Problem is that the default impl of SchemaQueriesFactory
> (DefaultSchemaQueriesFactory) can chuck exceptions in a few cases, most
> notably if the control connection is in a bad way:
>
>
> {code:java}
> @Override
> public SchemaQueries newInstance() {
> DriverChannel channel = context.getControlConnection().channel();
> if (channel == null || channel.closeFuture().isDone()) {
> throw new IllegalStateException("Control channel not available, aborting
> schema refresh");
> }
> Node node =
> context
> .getMetadataManager()
> .getMetadata()
> .findNode(channel.getEndPoint())
> .orElseThrow(
> () ->
> new IllegalStateException(
> "Could not find control node metadata "
> + channel.getEndPoint()
> + ", aborting schema refresh"));
> return newInstance(node, channel);
> } {code}
>
>
>
> In this case the MetadataManager code above will exit out before it ever sets
> a state on refreshFuture... meaning anything waiting on that future will just
> continue to wait.
>
>
--
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] Correction of exception handling in asynchronous programming [cassandra-java-driver]
absurdfarce commented on PR #1918: URL: https://github.com/apache/cassandra-java-driver/pull/1918#issuecomment-1996093338 Ah, okay, I see your fundamental point @vararo27. I got confused myself by the sequence of CompletionStages at play there but you're correct; what really matters in this case is the CompletableFuture that's passed in as an arg. And in an exception case from DefaultSchemaQueriesFactory.newInstance() that will never get set. I've filed [CASSANDRA-19468](https://issues.apache.org/jira/browse/CASSANDRA-19468) to document this issue. We'll wind up doing something different from what you have in this PR, most likely some changes around the handling of that newInstance() call. But it's definitely an issue we're aware of. Thanks again for the report (and for sticking with me while we work through this)! -- 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] [Commented] (CASSANDRA-19468) In some situations MetadataManager.SingleThreaded.startSchemaRequest could fail to set CompletableFuture arg
[
https://issues.apache.org/jira/browse/CASSANDRA-19468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17826894#comment-17826894
]
Bret McGuire commented on CASSANDRA-19468:
--
Huge hat tip to Github user "vararo27" for pointing out the issue and
[persisting in
dialog|https://github.com/apache/cassandra-java-driver/pull/1918] to make sure
we identify it correctly!
> In some situations MetadataManager.SingleThreaded.startSchemaRequest could
> fail to set CompletableFuture arg
>
>
> Key: CASSANDRA-19468
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19468
> Project: Cassandra
> Issue Type: Bug
> Components: Client/java-driver
>Reporter: Bret McGuire
>Assignee: Henry Hughes
>Priority: Normal
>
> Relevant code is:
>
>
> {code:java}
> private void startSchemaRequest(CompletableFuture
> refreshFuture) {
> assert adminExecutor.inEventLoop();
> if (closeWasCalled) {
> refreshFuture.complete(new RefreshSchemaResult(metadata));
> return;
> }
> if (currentSchemaRefresh == null) {
> currentSchemaRefresh = refreshFuture;
> LOG.debug("[{}] Starting schema refresh", logPrefix);
> initControlConnectionForSchema()
> .thenCompose(v -> context.getTopologyMonitor().checkSchemaAgreement())
> .whenComplete(
> (schemaInAgreement, agreementError) -> {
> if (agreementError != null) {
> refreshFuture.completeExceptionally(agreementError);
> } else {
> schemaQueriesFactory
> .newInstance()
> .execute()
> .thenApplyAsync(this::parseAndApplySchemaRows,
> adminExecutor)
> .whenComplete(
> (newMetadata, metadataError) -> {
> if (metadataError != null) {
>
> refreshFuture.completeExceptionally(metadataError);
> } else {
> refreshFuture.complete(
> new RefreshSchemaResult(newMetadata,
> schemaInAgreement));
> }
> ...{code}
>
>
> Problem is that the default impl of SchemaQueriesFactory
> (DefaultSchemaQueriesFactory) can chuck exceptions in a few cases, most
> notably if the control connection is in a bad way:
>
>
> {code:java}
> @Override
> public SchemaQueries newInstance() {
> DriverChannel channel = context.getControlConnection().channel();
> if (channel == null || channel.closeFuture().isDone()) {
> throw new IllegalStateException("Control channel not available, aborting
> schema refresh");
> }
> Node node =
> context
> .getMetadataManager()
> .getMetadata()
> .findNode(channel.getEndPoint())
> .orElseThrow(
> () ->
> new IllegalStateException(
> "Could not find control node metadata "
> + channel.getEndPoint()
> + ", aborting schema refresh"));
> return newInstance(node, channel);
> } {code}
>
>
>
> In this case the MetadataManager code above will exit out before it ever sets
> a state on refreshFuture... meaning anything waiting on that future will just
> continue to wait.
>
>
--
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-19468) In some situations MetadataManager.SingleThreaded.startSchemaRequest could fail to set CompletableFuture arg
Bret McGuire created CASSANDRA-19468:
Summary: In some situations
MetadataManager.SingleThreaded.startSchemaRequest could fail to set
CompletableFuture arg
Key: CASSANDRA-19468
URL: https://issues.apache.org/jira/browse/CASSANDRA-19468
Project: Cassandra
Issue Type: Bug
Components: Client/java-driver
Reporter: Bret McGuire
Assignee: Henry Hughes
Relevant code is:
{code:java}
private void startSchemaRequest(CompletableFuture
refreshFuture) {
assert adminExecutor.inEventLoop();
if (closeWasCalled) {
refreshFuture.complete(new RefreshSchemaResult(metadata));
return;
}
if (currentSchemaRefresh == null) {
currentSchemaRefresh = refreshFuture;
LOG.debug("[{}] Starting schema refresh", logPrefix);
initControlConnectionForSchema()
.thenCompose(v -> context.getTopologyMonitor().checkSchemaAgreement())
.whenComplete(
(schemaInAgreement, agreementError) -> {
if (agreementError != null) {
refreshFuture.completeExceptionally(agreementError);
} else {
schemaQueriesFactory
.newInstance()
.execute()
.thenApplyAsync(this::parseAndApplySchemaRows,
adminExecutor)
.whenComplete(
(newMetadata, metadataError) -> {
if (metadataError != null) {
refreshFuture.completeExceptionally(metadataError);
} else {
refreshFuture.complete(
new RefreshSchemaResult(newMetadata,
schemaInAgreement));
}
...{code}
Problem is that the default impl of SchemaQueriesFactory
(DefaultSchemaQueriesFactory) can chuck exceptions in a few cases, most notably
if the control connection is in a bad way:
{code:java}
@Override
public SchemaQueries newInstance() {
DriverChannel channel = context.getControlConnection().channel();
if (channel == null || channel.closeFuture().isDone()) {
throw new IllegalStateException("Control channel not available, aborting
schema refresh");
}
Node node =
context
.getMetadataManager()
.getMetadata()
.findNode(channel.getEndPoint())
.orElseThrow(
() ->
new IllegalStateException(
"Could not find control node metadata "
+ channel.getEndPoint()
+ ", aborting schema refresh"));
return newInstance(node, channel);
} {code}
In this case the MetadataManager code above will exit out before it ever sets a
state on refreshFuture... meaning anything waiting on that future will just
continue to wait.
--
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] JAVA-3057 Allow decoding a UDT that has more fields than expected [cassandra-java-driver]
akhaku commented on code in PR #1635:
URL:
https://github.com/apache/cassandra-java-driver/pull/1635#discussion_r1524006033
##
core/src/main/java/com/datastax/oss/driver/internal/core/type/codec/UdtCodec.java:
##
@@ -105,10 +105,7 @@ public UdtValue decode(@Nullable ByteBuffer bytes,
@NonNull ProtocolVersion prot
int i = 0;
while (input.hasRemaining()) {
if (i == cqlType.getFieldTypes().size()) {
- throw new IllegalArgumentException(
- String.format(
- "Too many fields in encoded UDT value, expected %d",
- cqlType.getFieldTypes().size()));
+ break;
Review Comment:
Yes, that's the scenario we ran into, and I can't think of any other
scenarios.
Fair, a no-spam warn is a good idea but it doesn't look like the client
currently has a no-spam logger. I could copy the one from the server but maybe
not the best thing to do in this PR... and a vanilla log warn would be bad here
since it would get logged every time we decode a UDT field matching that
scenario. Thoughts?
--
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] [Commented] (CASSANDRA-19465) Test Failure: configuration_test.TestConfiguration.test_change_durable_writes
[
https://issues.apache.org/jira/browse/CASSANDRA-19465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17826861#comment-17826861
]
Brandon Williams commented on CASSANDRA-19465:
--
Discussed this with [~stefan.miklosovic] a bit, and it looks like he repro'd
the 64MB problem with no test modification
[here|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4001/workflows/a628b12c-f6d9-4898-9507-45e3c3d222f0/jobs/204086/parallel-runs/23?filterBy=ALL].
So now I guess we have two problems, but even more he pointed out the
original exception shouldn't happen from a large mutation, it should be caught
sooner. It looks like that is correct since the [large
mutation|https://github.com/apache/cassandra-dtest/blob/trunk/write_failures_test.py#L242]
test is passing and doesn't account for that exception. This is some kind of
progress but we're still stumped.
> Test Failure: configuration_test.TestConfiguration.test_change_durable_writes
> -
>
> Key: CASSANDRA-19465
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19465
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Berenguer Blasi
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
>
> https://app.circleci.com/pipelines/github/bereng/cassandra/1181/workflows/fe2ac859-f6ba-4f1e-b0b1-e6923b16e874/jobs/39449/tests
> {noformat}
> self =
> @pytest.mark.timeout(60*30)
> def test_change_durable_writes(self):
> """
> @jira_ticket CASSANDRA-9560
>
> Test that changes to the DURABLE_WRITES option on keyspaces is
> respected in subsequent writes.
>
> This test starts by writing a dataset to a cluster and asserting that
> the commitlogs have been written to. The subsequent test depends on
> the assumption that this dataset triggers an fsync.
>
> After checking this assumption, the test destroys the cluster and
> creates a fresh one. Then it tests that DURABLE_WRITES is respected
> by:
>
> - creating a keyspace with DURABLE_WRITES set to false,
> - using ALTER KEYSPACE to set its DURABLE_WRITES option to true,
> - writing a dataset to this keyspace that is known to trigger a
> commitlog fsync,
> - asserting that the commitlog has grown in size since the data was
> written.
> """
> def new_commitlog_cluster_node():
> # writes should block on commitlog fsync
> self.fixture_dtest_setup.cluster.populate(1)
> node = self.fixture_dtest_setup.cluster.nodelist()[0]
>
> self.fixture_dtest_setup.cluster.set_batch_commitlog(enabled=True,
> use_batch_window = self.fixture_dtest_setup.cluster.version() < '5.0')
>
> self.fixture_dtest_setup.cluster.start()
> return node
>
> durable_node = new_commitlog_cluster_node()
> durable_init_size = commitlog_size(durable_node)
> durable_session = self.patient_exclusive_cql_connection(durable_node)
>
> # test assumption that write_to_trigger_fsync actually triggers a
> commitlog fsync
> durable_session.execute("CREATE KEYSPACE ks WITH REPLICATION =
> {'class': 'SimpleStrategy', 'replication_factor': 1} "
> "AND DURABLE_WRITES = true")
> durable_session.execute('CREATE TABLE ks.tab (key int PRIMARY KEY, a
> int, b int, c int)')
> logger.debug('commitlog size diff = ' +
> str(commitlog_size(durable_node) - durable_init_size))
> write_to_trigger_fsync(durable_session, 'ks', 'tab')
>
> assert commitlog_size(durable_node) > durable_init_size, \
> "This test will not work in this environment;
> write_to_trigger_fsync does not trigger fsync."
>
> # get a fresh cluster to work on
> durable_session.shutdown()
> self.fixture_dtest_setup.cleanup_and_replace_cluster()
>
> node = new_commitlog_cluster_node()
> init_size = commitlog_size(node)
> session = self.patient_exclusive_cql_connection(node)
>
> # set up a keyspace without durable writes, then alter it to use them
> session.execute("CREATE KEYSPACE ks WITH REPLICATION = {'class':
> 'SimpleStrategy', 'replication_factor': 1} "
> "AND DURABLE_WRITES = false")
> session.execute('CREATE TABLE ks.tab (key int PRIMARY KEY, a int, b
> int, c int)')
> session.execute('ALTER KEYSPACE ks WITH DURABLE_WRITES=true')
> > write_to_trigger_fsync(session, 'ks', 'tab')
> configuration_test.py:113:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
>
Re: [PR] Annotate BatchStatement methods with CheckReturnValue [cassandra-java-driver]
akhaku commented on PR #1607: URL: https://github.com/apache/cassandra-java-driver/pull/1607#issuecomment-1995596202 Thanks for the approval! Rebased to fix the merge conflict, please merge when ready. -- 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] JAVA-3057 Allow decoding a UDT that has more fields than expected [cassandra-java-driver]
aratno commented on code in PR #1635:
URL:
https://github.com/apache/cassandra-java-driver/pull/1635#discussion_r1523809556
##
core/src/main/java/com/datastax/oss/driver/internal/core/type/codec/UdtCodec.java:
##
@@ -105,10 +105,7 @@ public UdtValue decode(@Nullable ByteBuffer bytes,
@NonNull ProtocolVersion prot
int i = 0;
while (input.hasRemaining()) {
if (i == cqlType.getFieldTypes().size()) {
- throw new IllegalArgumentException(
- String.format(
- "Too many fields in encoded UDT value, expected %d",
- cqlType.getFieldTypes().size()));
+ break;
Review Comment:
I can understand not failing in this case, but logging a (no-spam) warning
seems appropriate. Based on my understanding, this should only happen if a
schema change happens on the server to add fields to a UDT, and the client gets
an updated UDT in a response before finding out about the new schema.
Are there any other situations when this might occur?
--
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] [Comment Edited] (CASSANDRA-19465) Test Failure: configuration_test.TestConfiguration.test_change_durable_writes
[
https://issues.apache.org/jira/browse/CASSANDRA-19465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17826795#comment-17826795
]
Brandon Williams edited comment on CASSANDRA-19465 at 3/13/24 6:48 PM:
---
Running with the assumption that JMX is the culprit, I [rewrote the
check|https://github.com/driftx/cassandra-dtest/commit/6a9f18943b711c378407af7630697cf3eb8b6932]
to manually sum the commitlogs, and still no dice, so I added
[debugging|https://github.com/driftx/cassandra-dtest/commit/b264a289c9e2f2cd90070e265f492a1f56cc49c3]
to print all the commitlogs:
{noformat}
16:38:17,433 configuration_test DEBUG added , os.stat_result(st_mode=33188,
st_ino=631414135, st_dev=66308, st_nlink=1, st_uid=1000, st_gid=1000,
st_size=33554432, st_atime=1710347893, st_mtime=1710347896, st_ctime=1710347896)
16:38:17,434 configuration_test DEBUG added , os.stat_result(st_mode=33188,
st_ino=631415045, st_dev=66308, st_nlink=1, st_uid=1000, st_gid=1000,
st_size=33554432, st_atime=1710347894, st_mtime=1710347894, st_ctime=1710347894)
{noformat}
Here we find the mystery 64MB, in two 32MB commitlogs. The timestamp in the
filenames point to 16:38:13 3/13/2024, which is 4 seconds before these logs.
During that time:
{noformat}
16:38:10,579 conftest INFO Starting execution of
test_change_durable_writes[12-20] at 2024-03-13 16:38:10.579693
16:38:11,471 dtest_setup INFO cluster ccm directory: /tmp/dtest-nf9xjaeg
16:38:11,537 ccm DEBUG Log-watching thread starting.
live log call -
16:38:11,537 ccm DEBUG Log-watching thread starting.
16:38:11,539 ccm DEBUG using balanced tokens for non-vnode cluster
16:38:11,539 ccm DEBUG using balanced tokens for non-vnode cluster
---circle stuff snipped---
16:38:12,306 ccm INFO node1: using Java 17 for the current invocation
16:38:12,306 ccm INFO node1: using Java 17 for the current invocation
16:38:12,350 ccm INFO Starting node1 with
JAVA_HOME=/usr/lib/jvm/java-17-openjdk-amd64 java_version=17
cassandra_version=5.0, install_dir=/home/cassandra/cassandra
16:38:12,350 ccm INFO Starting node1 with
JAVA_HOME=/usr/lib/jvm/java-17-openjdk-amd64 java_version=17
cassandra_version=5.0, install_dir=/home/cassandra/cassandra
{noformat}
The node is simply starting up and nothing should be generating that much data.
I'll keep digging on what seems to be a total circle-ism here.
was (Author: brandon.williams):
Running with the assumption that JMX is the culprit, I [rewrote the
check|https://github.com/driftx/cassandra-dtest/commit/6a9f18943b711c378407af7630697cf3eb8b6932]
to manually sum the commitlogs, and still no dice, so I added
[debugging|https://github.com/driftx/cassandra-dtest/commit/b264a289c9e2f2cd90070e265f492a1f56cc49c3]
to print all the commitlogs:
{noformat}
16:38:17,433 configuration_test DEBUG added , os.stat_result(st_mode=33188,
st_ino=631414135, st_dev=66308, st_nlink=1, st_uid=1000, st_gid=1000,
st_size=33554432, st_atime=1710347893, st_mtime=1710347896, st_ctime=1710347896)
16:38:17,434 configuration_test DEBUG added , os.stat_result(st_mode=33188,
st_ino=631415045, st_dev=66308, st_nlink=1, st_uid=1000, st_gid=1000,
st_size=33554432, st_atime=1710347894, st_mtime=1710347894, st_ctime=1710347894)
{noformat}
Here we find the mystery 64MB, in two 32MB commitlogs. The timestamp in the
filenames point to 16:38:13 3/13/2024, which is 4 seconds before these logs.
During that time:
{noformat}
16:38:10,579 conftest INFO Starting execution of
test_change_durable_writes[12-20] at 2024-03-13 16:38:10.579693
16:38:11,471 dtest_setup INFO cluster ccm directory: /tmp/dtest-nf9xjaeg
16:38:11,537 ccm DEBUG Log-watching thread starting.
live log call -
16:38:11,537 ccm DEBUG Log-watching thread starting.
16:38:11,539 ccm DEBUG using balanced tokens for non-vnode cluster
16:38:11,539 ccm DEBUG using balanced tokens for non-vnode cluster
---circle stuff snipped---
16:38:12,306 ccm INFO node1: using Java 17 for the current invocation
16:38:12,306 ccm INFO node1: using Java 17 for the current invocation
16:38:12,350 ccm INFO Starting node1 with
JAVA_HOME=/usr/lib/jvm/java-17-openjdk-amd64 java_version=17
cassandra_version=5.0, install_dir=/home/cassandra/cassandra
16:38:12,350 ccm INFO Starting node1 with
JAVA_HOME=/usr/lib/jvm/java-17-openjdk-amd64 java_version=17
cassandra_version=5.0, install_dir=/home/cassandra/cassandra
{noformat}
The node is simply starting up and nothing shouldn't be generating that much
data. I'll keep digging on what seems to be a total circle-ism here.
> Test Failure: configuration_test.TestConfiguration.test_change_durable_writes
> -
>
> Key: CASSANDRA-19465
> URL:
[jira] [Comment Edited] (CASSANDRA-19465) Test Failure: configuration_test.TestConfiguration.test_change_durable_writes
[
https://issues.apache.org/jira/browse/CASSANDRA-19465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17826824#comment-17826824
]
Brandon Williams edited comment on CASSANDRA-19465 at 3/13/24 6:48 PM:
---
On a fresh start we will have two 32MB (by default) commitlogs _allocated_, but
then...why doesn't this fail everywhere, all the time? I don't understand why
this only fails in circle.
was (Author: brandon.williams):
On a fresh start we will have two 32MB (by default) commitlogs present, but
then...why doesn't this fail everywhere, all the time? I don't understand why
this only fails in circle.
> Test Failure: configuration_test.TestConfiguration.test_change_durable_writes
> -
>
> Key: CASSANDRA-19465
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19465
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Berenguer Blasi
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
>
> https://app.circleci.com/pipelines/github/bereng/cassandra/1181/workflows/fe2ac859-f6ba-4f1e-b0b1-e6923b16e874/jobs/39449/tests
> {noformat}
> self =
> @pytest.mark.timeout(60*30)
> def test_change_durable_writes(self):
> """
> @jira_ticket CASSANDRA-9560
>
> Test that changes to the DURABLE_WRITES option on keyspaces is
> respected in subsequent writes.
>
> This test starts by writing a dataset to a cluster and asserting that
> the commitlogs have been written to. The subsequent test depends on
> the assumption that this dataset triggers an fsync.
>
> After checking this assumption, the test destroys the cluster and
> creates a fresh one. Then it tests that DURABLE_WRITES is respected
> by:
>
> - creating a keyspace with DURABLE_WRITES set to false,
> - using ALTER KEYSPACE to set its DURABLE_WRITES option to true,
> - writing a dataset to this keyspace that is known to trigger a
> commitlog fsync,
> - asserting that the commitlog has grown in size since the data was
> written.
> """
> def new_commitlog_cluster_node():
> # writes should block on commitlog fsync
> self.fixture_dtest_setup.cluster.populate(1)
> node = self.fixture_dtest_setup.cluster.nodelist()[0]
>
> self.fixture_dtest_setup.cluster.set_batch_commitlog(enabled=True,
> use_batch_window = self.fixture_dtest_setup.cluster.version() < '5.0')
>
> self.fixture_dtest_setup.cluster.start()
> return node
>
> durable_node = new_commitlog_cluster_node()
> durable_init_size = commitlog_size(durable_node)
> durable_session = self.patient_exclusive_cql_connection(durable_node)
>
> # test assumption that write_to_trigger_fsync actually triggers a
> commitlog fsync
> durable_session.execute("CREATE KEYSPACE ks WITH REPLICATION =
> {'class': 'SimpleStrategy', 'replication_factor': 1} "
> "AND DURABLE_WRITES = true")
> durable_session.execute('CREATE TABLE ks.tab (key int PRIMARY KEY, a
> int, b int, c int)')
> logger.debug('commitlog size diff = ' +
> str(commitlog_size(durable_node) - durable_init_size))
> write_to_trigger_fsync(durable_session, 'ks', 'tab')
>
> assert commitlog_size(durable_node) > durable_init_size, \
> "This test will not work in this environment;
> write_to_trigger_fsync does not trigger fsync."
>
> # get a fresh cluster to work on
> durable_session.shutdown()
> self.fixture_dtest_setup.cleanup_and_replace_cluster()
>
> node = new_commitlog_cluster_node()
> init_size = commitlog_size(node)
> session = self.patient_exclusive_cql_connection(node)
>
> # set up a keyspace without durable writes, then alter it to use them
> session.execute("CREATE KEYSPACE ks WITH REPLICATION = {'class':
> 'SimpleStrategy', 'replication_factor': 1} "
> "AND DURABLE_WRITES = false")
> session.execute('CREATE TABLE ks.tab (key int PRIMARY KEY, a int, b
> int, c int)')
> session.execute('ALTER KEYSPACE ks WITH DURABLE_WRITES=true')
> > write_to_trigger_fsync(session, 'ks', 'tab')
> configuration_test.py:113:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> configuration_test.py:186: in write_to_trigger_fsync
> execute_concurrent_with_args(session,
> ../env3.8/src/cassandra-driver/cassandra/concurrent.py:238: in
> execute_concurrent_with_args
> return execute_concurrent(session, zip(cycle((statement,)),
[jira] [Commented] (CASSANDRA-19465) Test Failure: configuration_test.TestConfiguration.test_change_durable_writes
[
https://issues.apache.org/jira/browse/CASSANDRA-19465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17826824#comment-17826824
]
Brandon Williams commented on CASSANDRA-19465:
--
On a fresh start we will have two 32MB (by default) commitlogs present, but
then...why doesn't this fail everywhere, all the time? I don't understand why
this only fails in circle.
> Test Failure: configuration_test.TestConfiguration.test_change_durable_writes
> -
>
> Key: CASSANDRA-19465
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19465
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Berenguer Blasi
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
>
> https://app.circleci.com/pipelines/github/bereng/cassandra/1181/workflows/fe2ac859-f6ba-4f1e-b0b1-e6923b16e874/jobs/39449/tests
> {noformat}
> self =
> @pytest.mark.timeout(60*30)
> def test_change_durable_writes(self):
> """
> @jira_ticket CASSANDRA-9560
>
> Test that changes to the DURABLE_WRITES option on keyspaces is
> respected in subsequent writes.
>
> This test starts by writing a dataset to a cluster and asserting that
> the commitlogs have been written to. The subsequent test depends on
> the assumption that this dataset triggers an fsync.
>
> After checking this assumption, the test destroys the cluster and
> creates a fresh one. Then it tests that DURABLE_WRITES is respected
> by:
>
> - creating a keyspace with DURABLE_WRITES set to false,
> - using ALTER KEYSPACE to set its DURABLE_WRITES option to true,
> - writing a dataset to this keyspace that is known to trigger a
> commitlog fsync,
> - asserting that the commitlog has grown in size since the data was
> written.
> """
> def new_commitlog_cluster_node():
> # writes should block on commitlog fsync
> self.fixture_dtest_setup.cluster.populate(1)
> node = self.fixture_dtest_setup.cluster.nodelist()[0]
>
> self.fixture_dtest_setup.cluster.set_batch_commitlog(enabled=True,
> use_batch_window = self.fixture_dtest_setup.cluster.version() < '5.0')
>
> self.fixture_dtest_setup.cluster.start()
> return node
>
> durable_node = new_commitlog_cluster_node()
> durable_init_size = commitlog_size(durable_node)
> durable_session = self.patient_exclusive_cql_connection(durable_node)
>
> # test assumption that write_to_trigger_fsync actually triggers a
> commitlog fsync
> durable_session.execute("CREATE KEYSPACE ks WITH REPLICATION =
> {'class': 'SimpleStrategy', 'replication_factor': 1} "
> "AND DURABLE_WRITES = true")
> durable_session.execute('CREATE TABLE ks.tab (key int PRIMARY KEY, a
> int, b int, c int)')
> logger.debug('commitlog size diff = ' +
> str(commitlog_size(durable_node) - durable_init_size))
> write_to_trigger_fsync(durable_session, 'ks', 'tab')
>
> assert commitlog_size(durable_node) > durable_init_size, \
> "This test will not work in this environment;
> write_to_trigger_fsync does not trigger fsync."
>
> # get a fresh cluster to work on
> durable_session.shutdown()
> self.fixture_dtest_setup.cleanup_and_replace_cluster()
>
> node = new_commitlog_cluster_node()
> init_size = commitlog_size(node)
> session = self.patient_exclusive_cql_connection(node)
>
> # set up a keyspace without durable writes, then alter it to use them
> session.execute("CREATE KEYSPACE ks WITH REPLICATION = {'class':
> 'SimpleStrategy', 'replication_factor': 1} "
> "AND DURABLE_WRITES = false")
> session.execute('CREATE TABLE ks.tab (key int PRIMARY KEY, a int, b
> int, c int)')
> session.execute('ALTER KEYSPACE ks WITH DURABLE_WRITES=true')
> > write_to_trigger_fsync(session, 'ks', 'tab')
> configuration_test.py:113:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> configuration_test.py:186: in write_to_trigger_fsync
> execute_concurrent_with_args(session,
> ../env3.8/src/cassandra-driver/cassandra/concurrent.py:238: in
> execute_concurrent_with_args
> return execute_concurrent(session, zip(cycle((statement,)), parameters),
> *args, **kwargs)
> ../env3.8/src/cassandra-driver/cassandra/concurrent.py:94: in
> execute_concurrent
> return executor.execute(concurrency, raise_on_first_error)
> ../env3.8/src/cassandra-driver/cassandra/concurrent.py:201: in execute
> return
[jira] [Updated] (CASSANDRASC-111) Improve observability in Sidecar
[ https://issues.apache.org/jira/browse/CASSANDRASC-111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Saranya Krishnakumar updated CASSANDRASC-111: - Description: Currently we capture minimal metrics in Sidecar, through this patch we want to improve observability in Sidecar. For this we want to record more metrics in Sidecar with Dropwizard. Introduce setup changes needed for capturing sidecar metrics through Dropwizard. Some of the metric kinds we will capture through this patch are, HTTP metrics like number of requests created per route, response time taken endpoint wise. Capture metrics per Cassandra instance maintained by Sidecar, such as, instance specific restore metrics, instance specific stream and upload metrics. We will also turn on registering, server route metrics emitted by Vert.x. was: Currently we capture minimal metrics in Sidecar, through this patch we want to improve observability in Sidecar. For this we want to record more metrics in Sidecar with Dropwizard. Introduce setup changes needed for capturing sidecar metrics through Dropwizard. Remove existing metric interfaces with default methods, in place capture metrics with Dropwizard APIs. Some of the metric kinds we will capture through this patch are, HTTP metrics like number of requests created per route, response time taken endpoint wise. Capture metrics per Cassandra instance maintained by Sidecar, such as, instance specific restore metrics, instance specific stream and upload metrics. We will also turn on registering, server route specific metrics emitted by Vert.x. > Improve observability in Sidecar > - > > Key: CASSANDRASC-111 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-111 > Project: Sidecar for Apache Cassandra > Issue Type: Task > Components: Rest API >Reporter: Saranya Krishnakumar >Assignee: Saranya Krishnakumar >Priority: Normal > Labels: pull-request-available > > Currently we capture minimal metrics in Sidecar, through this patch we want > to improve observability in Sidecar. > For this we want to record more metrics in Sidecar with Dropwizard. Introduce > setup changes needed for capturing sidecar metrics through Dropwizard. > Some of the metric kinds we will capture through this patch are, HTTP metrics > like number of requests created per route, response time taken endpoint wise. > Capture metrics per Cassandra instance maintained by Sidecar, such as, > instance specific restore metrics, instance specific stream and upload > metrics. We will also turn on registering, server route metrics emitted by > Vert.x. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
Re: [PR] Add ExecutionInfo to RequestTracker methods [cassandra-java-driver]
vanditsramblings commented on PR #1640: URL: https://github.com/apache/cassandra-java-driver/pull/1640#issuecomment-1995012337 +1 , this would be a great addition , allowing more granular access to execution metrics. -- 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] [Comment Edited] (CASSANDRA-19465) Test Failure: configuration_test.TestConfiguration.test_change_durable_writes
[
https://issues.apache.org/jira/browse/CASSANDRA-19465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17826795#comment-17826795
]
Brandon Williams edited comment on CASSANDRA-19465 at 3/13/24 4:55 PM:
---
Running with the assumption that JMX is the culprit, I [rewrote the
check|https://github.com/driftx/cassandra-dtest/commit/6a9f18943b711c378407af7630697cf3eb8b6932]
to manually sum the commitlogs, and still no dice, so I added
[debugging|https://github.com/driftx/cassandra-dtest/commit/b264a289c9e2f2cd90070e265f492a1f56cc49c3]
to print all the commitlogs:
{noformat}
16:38:17,433 configuration_test DEBUG added , os.stat_result(st_mode=33188,
st_ino=631414135, st_dev=66308, st_nlink=1, st_uid=1000, st_gid=1000,
st_size=33554432, st_atime=1710347893, st_mtime=1710347896, st_ctime=1710347896)
16:38:17,434 configuration_test DEBUG added , os.stat_result(st_mode=33188,
st_ino=631415045, st_dev=66308, st_nlink=1, st_uid=1000, st_gid=1000,
st_size=33554432, st_atime=1710347894, st_mtime=1710347894, st_ctime=1710347894)
{noformat}
Here we find the mystery 64MB, in two 32MB commitlogs. The timestamp in the
filenames point to 16:38:13 3/13/2024, which is 4 seconds before these logs.
During that time:
{noformat}
16:38:10,579 conftest INFO Starting execution of
test_change_durable_writes[12-20] at 2024-03-13 16:38:10.579693
16:38:11,471 dtest_setup INFO cluster ccm directory: /tmp/dtest-nf9xjaeg
16:38:11,537 ccm DEBUG Log-watching thread starting.
live log call -
16:38:11,537 ccm DEBUG Log-watching thread starting.
16:38:11,539 ccm DEBUG using balanced tokens for non-vnode cluster
16:38:11,539 ccm DEBUG using balanced tokens for non-vnode cluster
---circle stuff snipped---
16:38:12,306 ccm INFO node1: using Java 17 for the current invocation
16:38:12,306 ccm INFO node1: using Java 17 for the current invocation
16:38:12,350 ccm INFO Starting node1 with
JAVA_HOME=/usr/lib/jvm/java-17-openjdk-amd64 java_version=17
cassandra_version=5.0, install_dir=/home/cassandra/cassandra
16:38:12,350 ccm INFO Starting node1 with
JAVA_HOME=/usr/lib/jvm/java-17-openjdk-amd64 java_version=17
cassandra_version=5.0, install_dir=/home/cassandra/cassandra
{noformat}
The node is simply starting up and nothing shouldn't be generating that much
data. I'll keep digging on what seems to be a total circle-ism here.
was (Author: brandon.williams):
Running with the assumption that JMX is the culprit, I [rewrote the
check|https://github.com/driftx/cassandra-dtest/commit/6a9f18943b711c378407af7630697cf3eb8b6932]
to manually sum the commitlogs, and still no dice I added
[debugging|https://github.com/driftx/cassandra-dtest/commit/b264a289c9e2f2cd90070e265f492a1f56cc49c3]
to print all the commitlogs:
{noformat}
16:38:17,433 configuration_test DEBUG added , os.stat_result(st_mode=33188,
st_ino=631414135, st_dev=66308, st_nlink=1, st_uid=1000, st_gid=1000,
st_size=33554432, st_atime=1710347893, st_mtime=1710347896, st_ctime=1710347896)
16:38:17,434 configuration_test DEBUG added , os.stat_result(st_mode=33188,
st_ino=631415045, st_dev=66308, st_nlink=1, st_uid=1000, st_gid=1000,
st_size=33554432, st_atime=1710347894, st_mtime=1710347894, st_ctime=1710347894)
{noformat}
Here we find the mystery 64MB, in two 32MB commitlogs. The timestamp in the
filenames point to 16:38:13 3/13/2024, which is 4 seconds before these logs.
During that time:
{noformat}
16:38:10,579 conftest INFO Starting execution of
test_change_durable_writes[12-20] at 2024-03-13 16:38:10.579693
16:38:11,471 dtest_setup INFO cluster ccm directory: /tmp/dtest-nf9xjaeg
16:38:11,537 ccm DEBUG Log-watching thread starting.
live log call -
16:38:11,537 ccm DEBUG Log-watching thread starting.
16:38:11,539 ccm DEBUG using balanced tokens for non-vnode cluster
16:38:11,539 ccm DEBUG using balanced tokens for non-vnode cluster
---circle stuff snipped---
16:38:12,306 ccm INFO node1: using Java 17 for the current invocation
16:38:12,306 ccm INFO node1: using Java 17 for the current invocation
16:38:12,350 ccm INFO Starting node1 with
JAVA_HOME=/usr/lib/jvm/java-17-openjdk-amd64 java_version=17
cassandra_version=5.0, install_dir=/home/cassandra/cassandra
16:38:12,350 ccm INFO Starting node1 with
JAVA_HOME=/usr/lib/jvm/java-17-openjdk-amd64 java_version=17
cassandra_version=5.0, install_dir=/home/cassandra/cassandra
{noformat}
The node is simply starting up and nothing shouldn't be generating that much
data. I'll keep digging on what seems to be a total circle-ism here.
> Test Failure: configuration_test.TestConfiguration.test_change_durable_writes
> -
>
> Key: CASSANDRA-19465
> URL:
[jira] [Commented] (CASSANDRA-19465) Test Failure: configuration_test.TestConfiguration.test_change_durable_writes
[
https://issues.apache.org/jira/browse/CASSANDRA-19465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17826795#comment-17826795
]
Brandon Williams commented on CASSANDRA-19465:
--
Running with the assumption that JMX is the culprit, I [rewrote the
check|https://github.com/driftx/cassandra-dtest/commit/6a9f18943b711c378407af7630697cf3eb8b6932]
to manually sum the commitlogs, and still no dice I added
[debugging|https://github.com/driftx/cassandra-dtest/commit/b264a289c9e2f2cd90070e265f492a1f56cc49c3]
to print all the commitlogs:
{noformat}
16:38:17,433 configuration_test DEBUG added , os.stat_result(st_mode=33188,
st_ino=631414135, st_dev=66308, st_nlink=1, st_uid=1000, st_gid=1000,
st_size=33554432, st_atime=1710347893, st_mtime=1710347896, st_ctime=1710347896)
16:38:17,434 configuration_test DEBUG added , os.stat_result(st_mode=33188,
st_ino=631415045, st_dev=66308, st_nlink=1, st_uid=1000, st_gid=1000,
st_size=33554432, st_atime=1710347894, st_mtime=1710347894, st_ctime=1710347894)
{noformat}
Here we find the mystery 64MB, in two 32MB commitlogs. The timestamp in the
filenames point to 16:38:13 3/13/2024, which is 4 seconds before these logs.
During that time:
{noformat}
16:38:10,579 conftest INFO Starting execution of
test_change_durable_writes[12-20] at 2024-03-13 16:38:10.579693
16:38:11,471 dtest_setup INFO cluster ccm directory: /tmp/dtest-nf9xjaeg
16:38:11,537 ccm DEBUG Log-watching thread starting.
live log call -
16:38:11,537 ccm DEBUG Log-watching thread starting.
16:38:11,539 ccm DEBUG using balanced tokens for non-vnode cluster
16:38:11,539 ccm DEBUG using balanced tokens for non-vnode cluster
---circle stuff snipped---
16:38:12,306 ccm INFO node1: using Java 17 for the current invocation
16:38:12,306 ccm INFO node1: using Java 17 for the current invocation
16:38:12,350 ccm INFO Starting node1 with
JAVA_HOME=/usr/lib/jvm/java-17-openjdk-amd64 java_version=17
cassandra_version=5.0, install_dir=/home/cassandra/cassandra
16:38:12,350 ccm INFO Starting node1 with
JAVA_HOME=/usr/lib/jvm/java-17-openjdk-amd64 java_version=17
cassandra_version=5.0, install_dir=/home/cassandra/cassandra
{noformat}
The node is simply starting up and nothing shouldn't be generating that much
data. I'll keep digging on what seems to be a total circle-ism here.
> Test Failure: configuration_test.TestConfiguration.test_change_durable_writes
> -
>
> Key: CASSANDRA-19465
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19465
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Berenguer Blasi
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
>
> https://app.circleci.com/pipelines/github/bereng/cassandra/1181/workflows/fe2ac859-f6ba-4f1e-b0b1-e6923b16e874/jobs/39449/tests
> {noformat}
> self =
> @pytest.mark.timeout(60*30)
> def test_change_durable_writes(self):
> """
> @jira_ticket CASSANDRA-9560
>
> Test that changes to the DURABLE_WRITES option on keyspaces is
> respected in subsequent writes.
>
> This test starts by writing a dataset to a cluster and asserting that
> the commitlogs have been written to. The subsequent test depends on
> the assumption that this dataset triggers an fsync.
>
> After checking this assumption, the test destroys the cluster and
> creates a fresh one. Then it tests that DURABLE_WRITES is respected
> by:
>
> - creating a keyspace with DURABLE_WRITES set to false,
> - using ALTER KEYSPACE to set its DURABLE_WRITES option to true,
> - writing a dataset to this keyspace that is known to trigger a
> commitlog fsync,
> - asserting that the commitlog has grown in size since the data was
> written.
> """
> def new_commitlog_cluster_node():
> # writes should block on commitlog fsync
> self.fixture_dtest_setup.cluster.populate(1)
> node = self.fixture_dtest_setup.cluster.nodelist()[0]
>
> self.fixture_dtest_setup.cluster.set_batch_commitlog(enabled=True,
> use_batch_window = self.fixture_dtest_setup.cluster.version() < '5.0')
>
> self.fixture_dtest_setup.cluster.start()
> return node
>
> durable_node = new_commitlog_cluster_node()
> durable_init_size = commitlog_size(durable_node)
> durable_session = self.patient_exclusive_cql_connection(durable_node)
>
> # test assumption that write_to_trigger_fsync actually triggers a
> commitlog fsync
> durable_session.execute("CREATE KEYSPACE ks WITH REPLICATION =
> {'class':
Re: [PR] Correction of exception handling in asynchronous programming [cassandra-java-driver]
vararo27 commented on PR #1918: URL: https://github.com/apache/cassandra-java-driver/pull/1918#issuecomment-1994959017 Yes, agreed that it will never reach thenApplyAsync() and subsequent whenComplete(). Basically, exception thrown by schemaQueriesFactory.newInstance() reference is lost and refreshFuture object is never completed. It results in blockage of further workflows. Basically, with this change I am trying to highlight that exception should be handled some way. Sample java code which I had shared could be used to replicate this behavior. It would give clear depiction of problem I am trying to highlight. Please let me know if we can connect to discuss this issue in details. -- 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-19447) Register the measurements of the bootstrap as Dropwizard metrics
[
https://issues.apache.org/jira/browse/CASSANDRA-19447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated CASSANDRA-19447:
Fix Version/s: 5.1
(was: 5.x)
Source Control Link:
https://github.com/apache/cassandra/commit/81a2cb782eed932961b0c89fbd40199c7269c662
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Verified repeated run locally against the trunk branch, everything passes. I've
also checked the {{FailedBootstapTest}} on the trunk branch without my changes
and on the PR branch, so it passes all the time in both cases.
The patch merged here:
https://github.com/apache/cassandra/commit/81a2cb782eed932961b0c89fbd40199c7269c662
[~smiklosovic] Thank you for the review.
> Register the measurements of the bootstrap as Dropwizard metrics
>
>
> Key: CASSANDRA-19447
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19447
> Project: Cassandra
> Issue Type: Improvement
> Components: Observability/JMX, Observability/Metrics
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Normal
> Fix For: 5.1
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Currently, we can view the node's bootstrap state in the following ways:
> - via the nodetool cli tool, e.g. by running the "resume" command;
> - querying the bootstrapped column of the system_veis.local virtual table;
> In addition, we can also expose the status and state of the node's bootstrap
> via JMX. This is used by third-party tools that rely entirely on the JMX API
> and don't have access to the CQL interface. The operator will be able to get
> all the information they need from the dashboards without having to use CLIs.
--
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: Register the measurements of the bootstrap process as Dropwizard metrics
This is an automated email from the ASF dual-hosted git repository.
mmuzaf 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 81a2cb782e Register the measurements of the bootstrap process as
Dropwizard metrics
81a2cb782e is described below
commit 81a2cb782eed932961b0c89fbd40199c7269c662
Author: Maxim Muzafarov
AuthorDate: Wed Mar 6 14:54:02 2024 +0100
Register the measurements of the bootstrap process as Dropwizard metrics
patch by Maxim Muzafarov; reviewed by Stefan Miklosovic for CASSANDRA-19447
---
CHANGES.txt| 1 +
.../org/apache/cassandra/dht/BootStrapper.java | 49 +-
.../apache/cassandra/metrics/StorageMetrics.java | 4 +-
.../test/hostreplacement/FailedBootstrapTest.java | 14 -
.../distributed/test/ring/BootstrapTest.java | 60 +-
5 files changed, 122 insertions(+), 6 deletions(-)
diff --git a/CHANGES.txt b/CHANGES.txt
index b6b9ab86ba..af985568cd 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
5.1
+ * Register the measurements of the bootstrap process as Dropwizard metrics
(CASSANDRA-19447)
* Add LIST SUPERUSERS CQL statement (CASSANDRA-19417)
* Modernize CQLSH datetime conversions (CASSANDRA-18879)
* Harry model and in-JVM tests for partition-restricted 2i queries
(CASSANDRA-18275)
diff --git a/src/java/org/apache/cassandra/dht/BootStrapper.java
b/src/java/org/apache/cassandra/dht/BootStrapper.java
index 82f587ed30..6c306a3ff0 100644
--- a/src/java/org/apache/cassandra/dht/BootStrapper.java
+++ b/src/java/org/apache/cassandra/dht/BootStrapper.java
@@ -24,18 +24,20 @@ import java.util.HashSet;
import java.util.List;
import java.util.Set;
import java.util.concurrent.atomic.AtomicInteger;
+import java.util.concurrent.atomic.AtomicLong;
+import java.util.concurrent.atomic.AtomicReference;
-import org.apache.cassandra.tcm.ownership.MovementMap;
-import org.apache.cassandra.utils.concurrent.Future;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
+import com.codahale.metrics.Gauge;
import org.apache.cassandra.config.DatabaseDescriptor;
import org.apache.cassandra.db.Keyspace;
import org.apache.cassandra.dht.tokenallocator.TokenAllocation;
import org.apache.cassandra.exceptions.ConfigurationException;
import org.apache.cassandra.locator.AbstractReplicationStrategy;
import org.apache.cassandra.locator.InetAddressAndPort;
+import org.apache.cassandra.metrics.StorageMetrics;
import org.apache.cassandra.schema.KeyspaceMetadata;
import org.apache.cassandra.schema.Schema;
import org.apache.cassandra.streaming.StreamEvent;
@@ -44,13 +46,21 @@ import org.apache.cassandra.streaming.StreamOperation;
import org.apache.cassandra.streaming.StreamResultFuture;
import org.apache.cassandra.streaming.StreamState;
import org.apache.cassandra.tcm.ClusterMetadata;
+import org.apache.cassandra.tcm.ownership.MovementMap;
+import org.apache.cassandra.utils.concurrent.Future;
import org.apache.cassandra.utils.progress.ProgressEvent;
import org.apache.cassandra.utils.progress.ProgressEventNotifierSupport;
import org.apache.cassandra.utils.progress.ProgressEventType;
+import static org.apache.cassandra.metrics.CassandraMetricsRegistry.Metrics;
+
public class BootStrapper extends ProgressEventNotifierSupport
{
private static final Logger logger =
LoggerFactory.getLogger(BootStrapper.class);
+private static final AtomicLong bootstrapFilesTotal = new AtomicLong();
+private static final AtomicLong bootstrapFilesReceived = new AtomicLong();
+private static final AtomicReference bootstrapLastSeenStatus = new
AtomicReference<>();
+private static final AtomicReference bootstrapLastSeenError = new
AtomicReference<>();
/* endpoint that needs to be bootstrapped */
protected final InetAddressAndPort address;
@@ -59,6 +69,14 @@ public class BootStrapper extends
ProgressEventNotifierSupport
private final MovementMap movements;
private final MovementMap strictMovements;
+static
+{
+
Metrics.>register(StorageMetrics.factory.createMetricName("BootstrapFilesTotal"),
bootstrapFilesTotal::get);
+
Metrics.>register(StorageMetrics.factory.createMetricName("BootstrapFilesReceived"),
bootstrapFilesReceived::get);
+
Metrics.>register(StorageMetrics.factory.createMetricName("BootstrapLastSeenStatus"),
bootstrapLastSeenStatus::get);
+
Metrics.>register(StorageMetrics.factory.createMetricName("BootstrapLastSeenError"),
bootstrapLastSeenError::get);
+}
+
public BootStrapper(InetAddressAndPort address,
ClusterMetadata metadata,
MovementMap movements,
@@ -70,6 +88,30 @@ public class BootStrapper extends
ProgressEventNotifierSupport
this.metadata = metadata;
this.movements = movements;
Re: [PR] Correction of exception handling in asynchronous programming [cassandra-java-driver]
absurdfarce commented on PR #1918:
URL:
https://github.com/apache/cassandra-java-driver/pull/1918#issuecomment-1994643967
I think we're talking about different whenComplete() blocks. The
newInstance() call throws an exception inside the whenComplete block that
starts with this code:
```java
initControlConnectionForSchema()
.thenCompose(v ->
context.getTopologyMonitor().checkSchemaAgreement())
.whenComplete(
(schemaInAgreement, agreementError) -> {
...
```
The thenApplyAsync() and subsequent whenComplete() calls never actually
happen because the exception thrown by schemaQueriesFactory.newInstance() exits
the BiConsumer passed to the enclosing whenComplete() (shown in the code
above). This code then exits with a stage that returned exceptionally (using
the exception thrown by schemaQueriesFactory.newInstance()) per the Javadoc
above.
--
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] [Commented] (CASSANDRA-18736) Streaming exception race creates corrupt transaction log files that prevent restart
[
https://issues.apache.org/jira/browse/CASSANDRA-18736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17826769#comment-17826769
]
Ekaterina Dimitrova commented on CASSANDRA-18736:
-
This ticket hasn't been updated for a while, is anything blocking it?
> Streaming exception race creates corrupt transaction log files that prevent
> restart
> ---
>
> Key: CASSANDRA-18736
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18736
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Streaming, Local/Startup and Shutdown
>Reporter: Jon Meredith
>Assignee: Jon Meredith
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0.x
>
>
> On restart, Cassandra logs this message and terminates.
> {code:java}
> ERROR 2023-07-17T17:17:22,931 [main]
> org.apache.cassandra.db.lifecycle.LogTransaction:561 - Unexpected disk state:
> failed to read transaction log
> [nb_txn_stream_39d5f6b0-fb81-11ed-8f46-e97b3f61511e.log in
> /datadir1/keyspace/table-c9527530a0d611e8813f034699fc9043]
> Files and contents follow:
> /datadir1/keyspace/table-c9527530a0d611e8813f034699fc9043/nb_txn_stream_39d5f6b0-fb81-11ed-8f46-e97b3f61511e.log
> ABORT:[,0,0][737437348]
> ***This record should have been the last one in all replicas
>
> ADD:[/datadir1/keyspace/table-c9527530a0d611e8813f034699fc9043/nb-284490-big-,0,8][2493503833]
> {code}
> The root cause is a race during streaming exception handling.
> Although concurrent modification of to the {{LogTransaction}} was added for
> CASSANDRA-16225, there is nothing to prevent usage after the transaction is
> completed (committed/aborted) once it has been processed by
> {{TransactionTidier}} (after the last reference is released). Before the
> transaction is tidied, the {{LogFile}} keeps a list of records that are
> checked for completion before adding new entries. In {{TransactionTidier}}
> {{LogFile.records}} are cleared as no longer needed, however the
> LogTransaction/LogFile is still accessible to the stream.
> The changes in CASSANDRA-17273 added a parallel set of {{onDiskRecords}} that
> could be used to reliably recreate the transaction log at any new datadirs
> the same as the existing
> datadirs - regardless of the effect of
> {{LogTransaction.untrackNew/LogFile.remove}}
> If a streaming exception causes the LogTransaction to be aborted and tidied
> just before {{SimpleSSTableMultiWriter}} calls trackNew to add a new sstable.
> At the time of the call, the {{LogFile}} will not contain any {{LogReplicas}},
> {{LogFile.records}} will be empty, and {{LogFile.onDiskRecords}} will contain
> an {{ABORT}}.
> When {{LogTransaction.trackNew/LogFile.add}} is called, the check for
> completed transaction fails as records is empty, there are no replicas on the
> datadir, so {{maybeCreateReplicas}} creates a new txnlog file replica
> containing ABORT, then
> appends an ADD record.
> The LogFile has already been tidied after the abort so the txnlog file is not
> removed and sits on disk until a restart, causing the faiulre.
> There is a related exception caused with a different interleaving of aborts,
> after an sstable is added, however this is just a nuisance in the logs as the
> LogRelica is already created with an {{ADD}} record first.
> {code:java}
> java.lang.AssertionError:
> [ADD:[/datadir1/keyspace/table/nb-23314378-big-,0,8][1869379820]] is not
> tracked by 55be35b0-35d1-11ee-865d-8b1e3c48ca06
> at org.apache.cassandra.db.lifecycle.LogFile.remove(LogFile.java:388)
> at
> org.apache.cassandra.db.lifecycle.LogTransaction.untrackNew(LogTransaction.java:158)
> at
> org.apache.cassandra.db.lifecycle.LifecycleTransaction.untrackNew(LifecycleTransaction.java:577)
> at
> org.apache.cassandra.db.streaming.CassandraStreamReceiver$1.untrackNew(CassandraStreamReceiver.java:149)
> at
> org.apache.cassandra.io.sstable.SimpleSSTableMultiWriter.abort(SimpleSSTableMultiWriter.java:95)
> at
> org.apache.cassandra.io.sstable.format.RangeAwareSSTableWriter.abort(RangeAwareSSTableWriter.java:191)
> at
> org.apache.cassandra.db.streaming.CassandraCompressedStreamReader.read(CassandraCompressedStreamReader.java:115)
> at
> org.apache.cassandra.db.streaming.CassandraIncomingFile.read(CassandraIncomingFile.java:85)
> at
> org.apache.cassandra.streaming.messages.IncomingStreamMessage$1.deserialize(IncomingStreamMessage.java:53)
> at
> org.apache.cassandra.streaming.messages.IncomingStreamMessage$1.deserialize(IncomingStreamMessage.java:38)
> at
> org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:53)
> at
>
[jira] [Commented] (CASSANDRA-19417) LIST SUPERUSERS cql command
[ https://issues.apache.org/jira/browse/CASSANDRA-19417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17826027#comment-17826027 ] Stefan Miklosovic commented on CASSANDRA-19417: --- the failed tests seem to be already reported in CASSANDRA-19443 > LIST SUPERUSERS cql command > --- > > Key: CASSANDRA-19417 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19417 > Project: Cassandra > Issue Type: Improvement > Components: Tool/cqlsh >Reporter: Shailaja Koppu >Assignee: Shailaja Koppu >Priority: Normal > Labels: CQL > Fix For: 5.1 > > Attachments: checkstyle_output.txt, ci_summary.html, > result_details.tar.gz > > Time Spent: 4h 20m > Remaining Estimate: 0h > > Developing a new CQL command LIST SUPERUSERS to return list of roles with > superuser privilege. This includes roles who acquired superuser privilege in > the hierarchy. > Context: LIST ROLES cql command lists roles, their membership details and > displays super=true for immediate superusers. But there can be roles who > acquired superuser privilege due to a grant. LIST ROLES command won't display > super=true for such roles and the only way to recognize such roles is to look > for atleast one row with super=true in the output of LIST ROLES OF name> command. While this works to check is a given role has superuser > privilege, there may be services (for example, Sidecar) working with C* and > may need to maintain list of roles with superuser privilege. There is no > existing command/tool to retrieve such roles details. Hence developing this > command which returns all roles having superuser privilege. -- 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-19443) Test Failure: org.apache.cassandra.audit.AuditLoggerAuthTest
[
https://issues.apache.org/jira/browse/CASSANDRA-19443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17826028#comment-17826028
]
Stefan Miklosovic commented on CASSANDRA-19443:
---
I saw this again here
https://app.circleci.com/pipelines/github/instaclustr/cassandra/3996/workflows/5c7f22e0-bb0c-4860-80d8-f616e766e391/jobs/203592/tests
> Test Failure: org.apache.cassandra.audit.AuditLoggerAuthTest
>
>
> Key: CASSANDRA-19443
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19443
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.x
>
>
> The tests in this class are flaky for current trunk, as seen in this run:
> [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra?branch=AuditLoggerAuthTest-trunk]
> org.apache.cassandra.audit.AuditLoggerAuthTest.testUNAUTHORIZED_ATTEMPTAuditing-_jdk17
> {code:java}
> junit.framework.AssertionFailedError: expected: but
> was: at
> org.apache.cassandra.audit.AuditLoggerAuthTest.executeWithCredentials(AuditLoggerAuthTest.java:374)
> at
> org.apache.cassandra.audit.AuditLoggerAuthTest.testUNAUTHORIZED_ATTEMPTAuditing(AuditLoggerAuthTest.java:252)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method) at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43){code}
> testCqlLoginAuditing-_jdk17
> {code:java}
> junit.framework.AssertionFailedError: expected: but
> was: at
> org.apache.cassandra.audit.AuditLoggerAuthTest.executeWithCredentials(AuditLoggerAuthTest.java:374)
> at
> org.apache.cassandra.audit.AuditLoggerAuthTest.testCqlLoginAuditing(AuditLoggerAuthTest.java:119)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method) at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43){code}
> testCqlLISTROLESAuditing-_jdk17
> {code:java}
> junit.framework.AssertionFailedError: expected: but
> was: at
> org.apache.cassandra.audit.AuditLoggerAuthTest.executeWithCredentials(AuditLoggerAuthTest.java:374)
> at
> org.apache.cassandra.audit.AuditLoggerAuthTest.testCqlLISTROLESAuditing(AuditLoggerAuthTest.java:209)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method) at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43){code}
> testCqlCreateRoleAuditing-_jdk17
> {code:java}
> junit.framework.AssertionFailedError: expected: but
> was: at
> org.apache.cassandra.audit.AuditLoggerAuthTest.executeWithCredentials(AuditLoggerAuthTest.java:374)
> at
> org.apache.cassandra.audit.AuditLoggerAuthTest.createTestRole(AuditLoggerAuthTest.java:424)
> at
> org.apache.cassandra.audit.AuditLoggerAuthTest.testCqlCreateRoleAuditing(AuditLoggerAuthTest.java:127)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method) at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43){code}
--
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-19417) LIST SUPERUSERS cql command
[ https://issues.apache.org/jira/browse/CASSANDRA-19417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-19417: -- Fix Version/s: 5.1 (was: 5.x) Source Control Link: https://github.com/apache/cassandra/commit/b35ad427c5e9282730682553b6dcf5d70b603e22 Resolution: Fixed Status: Resolved (was: Ready to Commit) > LIST SUPERUSERS cql command > --- > > Key: CASSANDRA-19417 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19417 > Project: Cassandra > Issue Type: Improvement > Components: Tool/cqlsh >Reporter: Shailaja Koppu >Assignee: Shailaja Koppu >Priority: Normal > Labels: CQL > Fix For: 5.1 > > Attachments: checkstyle_output.txt, ci_summary.html, > result_details.tar.gz > > Time Spent: 4h 20m > Remaining Estimate: 0h > > Developing a new CQL command LIST SUPERUSERS to return list of roles with > superuser privilege. This includes roles who acquired superuser privilege in > the hierarchy. > Context: LIST ROLES cql command lists roles, their membership details and > displays super=true for immediate superusers. But there can be roles who > acquired superuser privilege due to a grant. LIST ROLES command won't display > super=true for such roles and the only way to recognize such roles is to look > for atleast one row with super=true in the output of LIST ROLES OF name> command. While this works to check is a given role has superuser > privilege, there may be services (for example, Sidecar) working with C* and > may need to maintain list of roles with superuser privilege. There is no > existing command/tool to retrieve such roles details. Hence developing this > command which returns all roles having superuser privilege. -- 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: Add LIST SUPERUSERS CQL statement
This is an automated email from the ASF dual-hosted git repository. smiklosovic pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git The following commit(s) were added to refs/heads/trunk by this push: new b35ad427c5 Add LIST SUPERUSERS CQL statement b35ad427c5 is described below commit b35ad427c5e9282730682553b6dcf5d70b603e22 Author: Shailaja Koppu AuthorDate: Tue Mar 12 12:27:58 2024 + Add LIST SUPERUSERS CQL statement patch by Shailaja Koppu; reviewed by Stefan Miklosovic and Benjamin Lerer for CASSANDRA-19417 --- CHANGES.txt| 1 + doc/cql3/CQL.textile | 16 ++- .../examples/BNF/list_superusers_statement.bnf | 1 + .../cassandra/pages/developing/cql/security.adoc | 12 ++ .../pages/reference/cql-commands/commands-toc.adoc | 3 + pylib/cqlshlib/cql3handling.py | 4 + pylib/cqlshlib/test/test_cqlsh_completion.py | 2 +- src/antlr/Lexer.g | 1 + src/antlr/Parser.g | 11 ++ .../apache/cassandra/audit/AuditLogEntryType.java | 3 +- src/java/org/apache/cassandra/auth/Roles.java | 14 +++ .../cql3/statements/ListSuperUsersStatement.java | 102 .../cassandra/audit/AuditLoggerAuthTest.java | 10 ++ test/unit/org/apache/cassandra/auth/RolesTest.java | 22 .../statements/ListSuperUsersStatementTest.java| 131 + 15 files changed, 330 insertions(+), 3 deletions(-) diff --git a/CHANGES.txt b/CHANGES.txt index 296d4cb2d9..b6b9ab86ba 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -1,4 +1,5 @@ 5.1 + * Add LIST SUPERUSERS CQL statement (CASSANDRA-19417) * Modernize CQLSH datetime conversions (CASSANDRA-18879) * Harry model and in-JVM tests for partition-restricted 2i queries (CASSANDRA-18275) * Refactor cqlshmain global constants (CASSANDRA-19201) diff --git a/doc/cql3/CQL.textile b/doc/cql3/CQL.textile index 959533f771..c85fef5ab5 100644 --- a/doc/cql3/CQL.textile +++ b/doc/cql3/CQL.textile @@ -1414,7 +1414,7 @@ REVOKE report_writer FROM alice; This statement revokes the @report_writer@ role from @alice@. Any permissions that @alice@ has acquired via the @report_writer@ role are also revoked. -h4(#listRolesStmt). LIST ROLES +h3(#listRolesStmt). LIST ROLES __Syntax:__ @@ -1438,6 +1438,20 @@ LIST ROLES OF @bob@ NORECURSIVE List all roles directly granted to @bob@. +h3(#listSuperusersStmt). LIST SUPERUSERS + +__Syntax:__ + +bc(syntax). + ::= LIST SUPERUSERS; + +__Sample:__ + +bc(sample). +LIST SUPERUSERS; + +Returns roles with the superuser privilege (this includes roles with transitively acquired superuser privilege), this command requires `DESCRIBE` permission on all roles of the database. + h3(#createUserStmt). CREATE USER Prior to the introduction of roles in Cassandra 2.2, authentication and authorization were based around the concept of a @USER@. For backward compatibility, the legacy syntax has been preserved with @USER@ centric statments becoming synonyms for the @ROLE@ based equivalents. diff --git a/doc/modules/cassandra/examples/BNF/list_superusers_statement.bnf b/doc/modules/cassandra/examples/BNF/list_superusers_statement.bnf new file mode 100644 index 00..ae21466e19 --- /dev/null +++ b/doc/modules/cassandra/examples/BNF/list_superusers_statement.bnf @@ -0,0 +1 @@ +list_superusers_statement ::= LIST SUPERUSERS diff --git a/doc/modules/cassandra/pages/developing/cql/security.adoc b/doc/modules/cassandra/pages/developing/cql/security.adoc index f751a1658d..2d438b9815 100644 --- a/doc/modules/cassandra/pages/developing/cql/security.adoc +++ b/doc/modules/cassandra/pages/developing/cql/security.adoc @@ -261,6 +261,18 @@ transitively acquired ones: include::cassandra:example$CQL/list_roles_nonrecursive.cql[] +[[list-superusers-statement]] +== LIST SUPERUSERS + +All the known roles (including transitively acquired) with superuser privilege can be listed using the `LIST SUPERUSERS` statement: + +[source, bnf] + +include::cassandra:example$BNF/list_superusers_statement.bnf[] + + +This command requires `DESCRIBE` permission on all roles of the database. + == Users Prior to the introduction of roles in Cassandra 2.2, authentication and diff --git a/doc/modules/cassandra/pages/reference/cql-commands/commands-toc.adoc b/doc/modules/cassandra/pages/reference/cql-commands/commands-toc.adoc index e1fe0fe0fd..0924e63ac7 100644 --- a/doc/modules/cassandra/pages/reference/cql-commands/commands-toc.adoc +++ b/doc/modules/cassandra/pages/reference/cql-commands/commands-toc.adoc @@ -95,6 +95,9 @@ Lists permissions on resources. xref:reference:cql-commands/list-roles.adoc[LIST ROLES] :: Lists roles and shows superuser and login status. +xref:reference:cql-commands/list-superusers.adoc[LIST SUPERUSERS] :: +Lists roles with the superuser
[jira] [Updated] (CASSANDRA-19417) LIST SUPERUSERS cql command
[ https://issues.apache.org/jira/browse/CASSANDRA-19417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-19417: --- Status: Review In Progress (was: Needs Committer) > LIST SUPERUSERS cql command > --- > > Key: CASSANDRA-19417 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19417 > Project: Cassandra > Issue Type: Improvement > Components: Tool/cqlsh >Reporter: Shailaja Koppu >Assignee: Shailaja Koppu >Priority: Normal > Labels: CQL > Fix For: 5.x > > Attachments: checkstyle_output.txt, ci_summary.html, > result_details.tar.gz > > Time Spent: 4h 20m > Remaining Estimate: 0h > > Developing a new CQL command LIST SUPERUSERS to return list of roles with > superuser privilege. This includes roles who acquired superuser privilege in > the hierarchy. > Context: LIST ROLES cql command lists roles, their membership details and > displays super=true for immediate superusers. But there can be roles who > acquired superuser privilege due to a grant. LIST ROLES command won't display > super=true for such roles and the only way to recognize such roles is to look > for atleast one row with super=true in the output of LIST ROLES OF name> command. While this works to check is a given role has superuser > privilege, there may be services (for example, Sidecar) working with C* and > may need to maintain list of roles with superuser privilege. There is no > existing command/tool to retrieve such roles details. Hence developing this > command which returns all roles having superuser privilege. -- 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-19417) LIST SUPERUSERS cql command
[ https://issues.apache.org/jira/browse/CASSANDRA-19417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-19417: --- Status: Ready to Commit (was: Review In Progress) > LIST SUPERUSERS cql command > --- > > Key: CASSANDRA-19417 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19417 > Project: Cassandra > Issue Type: Improvement > Components: Tool/cqlsh >Reporter: Shailaja Koppu >Assignee: Shailaja Koppu >Priority: Normal > Labels: CQL > Fix For: 5.x > > Attachments: checkstyle_output.txt, ci_summary.html, > result_details.tar.gz > > Time Spent: 4h 20m > Remaining Estimate: 0h > > Developing a new CQL command LIST SUPERUSERS to return list of roles with > superuser privilege. This includes roles who acquired superuser privilege in > the hierarchy. > Context: LIST ROLES cql command lists roles, their membership details and > displays super=true for immediate superusers. But there can be roles who > acquired superuser privilege due to a grant. LIST ROLES command won't display > super=true for such roles and the only way to recognize such roles is to look > for atleast one row with super=true in the output of LIST ROLES OF name> command. While this works to check is a given role has superuser > privilege, there may be services (for example, Sidecar) working with C* and > may need to maintain list of roles with superuser privilege. There is no > existing command/tool to retrieve such roles details. Hence developing this > command which returns all roles having superuser privilege. -- 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-19417) LIST SUPERUSERS cql command
[ https://issues.apache.org/jira/browse/CASSANDRA-19417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17826013#comment-17826013 ] Benjamin Lerer commented on CASSANDRA-19417: Yes, I was +1 on the patch as long as the nits were addressed and CI looked good. We can commit. > LIST SUPERUSERS cql command > --- > > Key: CASSANDRA-19417 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19417 > Project: Cassandra > Issue Type: Improvement > Components: Tool/cqlsh >Reporter: Shailaja Koppu >Assignee: Shailaja Koppu >Priority: Normal > Labels: CQL > Fix For: 5.x > > Attachments: checkstyle_output.txt, ci_summary.html, > result_details.tar.gz > > Time Spent: 4h 20m > Remaining Estimate: 0h > > Developing a new CQL command LIST SUPERUSERS to return list of roles with > superuser privilege. This includes roles who acquired superuser privilege in > the hierarchy. > Context: LIST ROLES cql command lists roles, their membership details and > displays super=true for immediate superusers. But there can be roles who > acquired superuser privilege due to a grant. LIST ROLES command won't display > super=true for such roles and the only way to recognize such roles is to look > for atleast one row with super=true in the output of LIST ROLES OF name> command. While this works to check is a given role has superuser > privilege, there may be services (for example, Sidecar) working with C* and > may need to maintain list of roles with superuser privilege. There is no > existing command/tool to retrieve such roles details. Hence developing this > command which returns all roles having superuser privilege. -- 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-19417) LIST SUPERUSERS cql command
[ https://issues.apache.org/jira/browse/CASSANDRA-19417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17826012#comment-17826012 ] Stefan Miklosovic commented on CASSANDRA-19417: --- unit tests on repeat (500x each added / modified test) j17 https://app.circleci.com/pipelines/github/instaclustr/cassandra/3996/workflows/5c7f22e0-bb0c-4860-80d8-f616e766e391/jobs/203593 j11 https://app.circleci.com/pipelines/github/instaclustr/cassandra/3996/workflows/5c7f22e0-bb0c-4860-80d8-f616e766e391/jobs/203592/tests I see that for j11 we have unfortunately two tests failing but I do not think they have anything to do with this change, they are both in AuditLoggerAuthTest testCqlLoginAuditing testUNAUTHORIZED_ATTEMPTAuditing When one looks into AuditLoggerAuthTest.executeWithCredentials, it fails on assertEquals(expectedType, logEntry.getType()); should be success but is failure, not sure why this is happening at all. The fact that this was run 1000 times (both runs for j17 and j11) and failed just once tells me this is some kind of a flakiness as such, we might further investigate it why it is so but I would not block this ticket from merging as these errors seems to be totally unrelated. > LIST SUPERUSERS cql command > --- > > Key: CASSANDRA-19417 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19417 > Project: Cassandra > Issue Type: Improvement > Components: Tool/cqlsh >Reporter: Shailaja Koppu >Assignee: Shailaja Koppu >Priority: Normal > Labels: CQL > Fix For: 5.x > > Attachments: checkstyle_output.txt, ci_summary.html, > result_details.tar.gz > > Time Spent: 4h 20m > Remaining Estimate: 0h > > Developing a new CQL command LIST SUPERUSERS to return list of roles with > superuser privilege. This includes roles who acquired superuser privilege in > the hierarchy. > Context: LIST ROLES cql command lists roles, their membership details and > displays super=true for immediate superusers. But there can be roles who > acquired superuser privilege due to a grant. LIST ROLES command won't display > super=true for such roles and the only way to recognize such roles is to look > for atleast one row with super=true in the output of LIST ROLES OF name> command. While this works to check is a given role has superuser > privilege, there may be services (for example, Sidecar) working with C* and > may need to maintain list of roles with superuser privilege. There is no > existing command/tool to retrieve such roles details. Hence developing this > command which returns all roles having superuser privilege. -- 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-19417) LIST SUPERUSERS cql command
[ https://issues.apache.org/jira/browse/CASSANDRA-19417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17826010#comment-17826010 ] Shailaja Koppu commented on CASSANDRA-19417: I have attached CI run results to this Jira. Checkstyle succeeded, but may not be evident in ci_summary.html, so ran checkstyle manually and attached the output. > LIST SUPERUSERS cql command > --- > > Key: CASSANDRA-19417 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19417 > Project: Cassandra > Issue Type: Improvement > Components: Tool/cqlsh >Reporter: Shailaja Koppu >Assignee: Shailaja Koppu >Priority: Normal > Labels: CQL > Fix For: 5.x > > Attachments: checkstyle_output.txt, ci_summary.html, > result_details.tar.gz > > Time Spent: 4h 20m > Remaining Estimate: 0h > > Developing a new CQL command LIST SUPERUSERS to return list of roles with > superuser privilege. This includes roles who acquired superuser privilege in > the hierarchy. > Context: LIST ROLES cql command lists roles, their membership details and > displays super=true for immediate superusers. But there can be roles who > acquired superuser privilege due to a grant. LIST ROLES command won't display > super=true for such roles and the only way to recognize such roles is to look > for atleast one row with super=true in the output of LIST ROLES OF name> command. While this works to check is a given role has superuser > privilege, there may be services (for example, Sidecar) working with C* and > may need to maintain list of roles with superuser privilege. There is no > existing command/tool to retrieve such roles details. Hence developing this > command which returns all roles having superuser privilege. -- 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-19417) LIST SUPERUSERS cql command
[ https://issues.apache.org/jira/browse/CASSANDRA-19417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shailaja Koppu updated CASSANDRA-19417: --- Attachment: result_details.tar.gz > LIST SUPERUSERS cql command > --- > > Key: CASSANDRA-19417 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19417 > Project: Cassandra > Issue Type: Improvement > Components: Tool/cqlsh >Reporter: Shailaja Koppu >Assignee: Shailaja Koppu >Priority: Normal > Labels: CQL > Fix For: 5.x > > Attachments: checkstyle_output.txt, ci_summary.html, > result_details.tar.gz > > Time Spent: 4h 20m > Remaining Estimate: 0h > > Developing a new CQL command LIST SUPERUSERS to return list of roles with > superuser privilege. This includes roles who acquired superuser privilege in > the hierarchy. > Context: LIST ROLES cql command lists roles, their membership details and > displays super=true for immediate superusers. But there can be roles who > acquired superuser privilege due to a grant. LIST ROLES command won't display > super=true for such roles and the only way to recognize such roles is to look > for atleast one row with super=true in the output of LIST ROLES OF name> command. While this works to check is a given role has superuser > privilege, there may be services (for example, Sidecar) working with C* and > may need to maintain list of roles with superuser privilege. There is no > existing command/tool to retrieve such roles details. Hence developing this > command which returns all roles having superuser privilege. -- 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-19417) LIST SUPERUSERS cql command
[ https://issues.apache.org/jira/browse/CASSANDRA-19417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shailaja Koppu updated CASSANDRA-19417: --- Attachment: ci_summary.html > LIST SUPERUSERS cql command > --- > > Key: CASSANDRA-19417 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19417 > Project: Cassandra > Issue Type: Improvement > Components: Tool/cqlsh >Reporter: Shailaja Koppu >Assignee: Shailaja Koppu >Priority: Normal > Labels: CQL > Fix For: 5.x > > Attachments: checkstyle_output.txt, ci_summary.html, > result_details.tar.gz > > Time Spent: 4h 20m > Remaining Estimate: 0h > > Developing a new CQL command LIST SUPERUSERS to return list of roles with > superuser privilege. This includes roles who acquired superuser privilege in > the hierarchy. > Context: LIST ROLES cql command lists roles, their membership details and > displays super=true for immediate superusers. But there can be roles who > acquired superuser privilege due to a grant. LIST ROLES command won't display > super=true for such roles and the only way to recognize such roles is to look > for atleast one row with super=true in the output of LIST ROLES OF name> command. While this works to check is a given role has superuser > privilege, there may be services (for example, Sidecar) working with C* and > may need to maintain list of roles with superuser privilege. There is no > existing command/tool to retrieve such roles details. Hence developing this > command which returns all roles having superuser privilege. -- 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-19417) LIST SUPERUSERS cql command
[ https://issues.apache.org/jira/browse/CASSANDRA-19417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shailaja Koppu updated CASSANDRA-19417: --- Attachment: checkstyle_output.txt > LIST SUPERUSERS cql command > --- > > Key: CASSANDRA-19417 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19417 > Project: Cassandra > Issue Type: Improvement > Components: Tool/cqlsh >Reporter: Shailaja Koppu >Assignee: Shailaja Koppu >Priority: Normal > Labels: CQL > Fix For: 5.x > > Attachments: checkstyle_output.txt, ci_summary.html, > result_details.tar.gz > > Time Spent: 4h 20m > Remaining Estimate: 0h > > Developing a new CQL command LIST SUPERUSERS to return list of roles with > superuser privilege. This includes roles who acquired superuser privilege in > the hierarchy. > Context: LIST ROLES cql command lists roles, their membership details and > displays super=true for immediate superusers. But there can be roles who > acquired superuser privilege due to a grant. LIST ROLES command won't display > super=true for such roles and the only way to recognize such roles is to look > for atleast one row with super=true in the output of LIST ROLES OF name> command. While this works to check is a given role has superuser > privilege, there may be services (for example, Sidecar) working with C* and > may need to maintain list of roles with superuser privilege. There is no > existing command/tool to retrieve such roles details. Hence developing this > command which returns all roles having superuser privilege. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18504) Added support for type VECTOR
[
https://issues.apache.org/jira/browse/CASSANDRA-18504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17825998#comment-17825998
]
Jacek Lewandowski commented on CASSANDRA-18504:
---
Why {{SSTableHeaderFix}} got removed? Aren't we affected anymore by the issue?
Can we have a upgrade dtest to prove that?
> Added support for type VECTOR
> --
>
> Key: CASSANDRA-18504
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18504
> Project: Cassandra
> Issue Type: Improvement
> Components: Cluster/Schema, CQL/Syntax
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: 5.0-alpha1, 5.0
>
> Time Spent: 20h 40m
> Remaining Estimate: 0h
>
> Based off several mailing list threads (see "[POLL] Vector type for ML”,
> "[DISCUSS] New data type for vector search”, and "Adding vector search to SAI
> with heirarchical navigable small world graph index”), its desirable to add a
> new type “VECTOR” that has the following properties
> 1) fixed length array
> 2) elements may not be null
> 3) flatten array (aka multi-cell = false)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (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=17825985#comment-17825985 ] Stefan Miklosovic edited comment on CASSANDRA-19393 at 3/13/24 9:32 AM: good catch! yeah, I haven't run upgrades ... I dont have CI plan for that. I need to check if we can run this thing in Jenkins ... [~n.v.harikrishna] please put together dtest PR and let us know was (Author: smiklosovic): good catch! yeah, I haven't run upgrades ... I dont have CI plan for that. I need to check if we can run this thing in Jenkins ... > 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=17825985#comment-17825985 ] Stefan Miklosovic commented on CASSANDRA-19393: --- good catch! yeah, I haven't run upgrades ... I dont have CI plan for that. I need to check if we can run this thing in Jenkins ... > 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=17825983#comment-17825983 ] n.v.harikrishna commented on CASSANDRA-19393: - There are couple of places where "initializecms" is used in python dtests. [https://github.com/search?q=repo%3Aapache%2Fcassandra-dtest%20initializecms=code] . Making changes there as well and checking other commands. > 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=17825982#comment-17825982 ] Stefan Miklosovic commented on CASSANDRA-19393: --- trunks's CI is a little bit wild but nothing out of ordinary, harry and fuzz failing as usually, couple flakes in between > 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=17825979#comment-17825979
]
Stefan Miklosovic commented on CASSANDRA-19393:
---
[CASSANDRA-19393-trunk|https://github.com/instaclustr/cassandra/tree/CASSANDRA-19393-trunk]
{noformat}
java17_pre-commit_tests
✓ j17_build4m 23s
✓ j17_cqlsh_dtests_py311 6m 42s
✓ j17_cqlsh_dtests_py311_vnode 7m 4s
✓ j17_cqlsh_dtests_py386m 44s
✓ j17_cqlsh_dtests_py38_vnode 7m 25s
✓ j17_cqlshlib_cython_tests9m 17s
✓ j17_cqlshlib_tests 6m 34s
✓ j17_dtests 34m 7s
✓ j17_dtests_vnode34m 16s
✓ j17_jvm_dtests_latest_vnode_repeat 0m 12s
✓ j17_unit_tests 13m 11s
✓ j17_utests_latest 14m 29s
✓ j17_utests_latest_repeat 0m 30s
✓ j17_utests_oa14m 3s
✕ j17_dtests_latest35m 8s
offline_tools_test.TestOfflineTools test_sstablelevelreset
offline_tools_test.TestOfflineTools test_sstableofflinerelevel
✕ j17_dtests_latest_repeat 0m 25s
✕ j17_jvm_dtests 26m 10s
org.apache.cassandra.fuzz.ring.ConsistentBootstrapTest
coordinatorIsBehindTest
org.apache.cassandra.distributed.test.NativeTransportEncryptionOptionsTest
testEndpointVerificationEnabledIpNotInSAN TIMEOUTED
✕ j17_jvm_dtests_latest_vnode 22m 46s
junit.framework.TestSuite
org.apache.cassandra.fuzz.harry.integration.model.InJVMTokenAwareExecutorTest
TIMEOUTED
java17_separate_tests
java11_pre-commit_tests
✓ j11_build9m 21s
✓ j11_cqlsh_dtests_py311 8m 31s
✓ j11_cqlsh_dtests_py311_vnode 8m 52s
✓ j11_cqlsh_dtests_py38 10m 45s
✓ j11_cqlsh_dtests_py38_vnode 7m 58s
✓ j11_cqlshlib_cython_tests 10m 41s
✓ j11_cqlshlib_tests 10m 16s
✓ j11_dtests 43m 20s
✓ j11_dtests_latest_repeat 4m 6s
✓ j11_dtests_vnode41m 39s
✓ j11_jvm_dtests_latest_vnode 22m 25s
✓ j11_jvm_dtests_latest_vnode_repeat 0m 41s
✓ j11_unit_tests 18m 24s
✓ j11_utests_latest14m 1s
✓ j11_utests_latest_repeat 4m 17s
✓ j11_utests_oa17m 3s
✓ j11_utests_system_keyspace_directory17m 46s
✓ j17_cqlsh_dtests_py311 6m 59s
✓ j17_cqlsh_dtests_py311_vnode 7m 13s
✓ j17_cqlsh_dtests_py38 7m 7s
✓ j17_cqlsh_dtests_py38_vnode 7m 39s
✓ j17_cqlshlib_cython_tests7m 42s
✓ j17_cqlshlib_tests 6m 44s
✓ j17_dtests 35m 49s
✓ j17_dtests_latest_repeat 0m 30s
✓ j17_dtests_vnode35m 17s
✓ j17_jvm_dtests_latest_vnode_repeat 2m 27s
✓ j17_unit_tests 14m 21s
✓ j17_utests_latest 14m 24s
✓ j17_utests_latest_repeat 0m 20s
✓ j17_utests_oa 13m 25s
✕ j11_dtests_latest 42m 26s
bootstrap_test.TestBootstrap test_bootstrap_with_reset_bootstrap_state
client_request_metrics_local_remote_test.TestClientRequestMetricsLocalRemote
test_batch_and_slice
offline_tools_test.TestOfflineTools test_sstablelevelreset
offline_tools_test.TestOfflineTools test_sstableofflinerelevel
✕ j11_jvm_dtests 26m 6s
org.apache.cassandra.fuzz.ring.ConsistentBootstrapTest
coordinatorIsBehindTest
✕ j11_simulator_dtests 3m 49s
org.apache.cassandra.simulator.test.HarrySimulatorTest test
✕ j17_dtests_latest34m 8s
bootstrap_test.TestBootstrap test_bootstrap_with_reset_bootstrap_state
offline_tools_test.TestOfflineTools test_sstablelevelreset
offline_tools_test.TestOfflineTools test_sstableofflinerelevel
streaming_test.TestStreaming test_zerocopy_streaming_no_replication
✕ j17_jvm_dtests 27m 0s
Re: [PR] Correction of exception handling in asynchronous programming [cassandra-java-driver]
vararo27 commented on PR #1918:
URL:
https://github.com/apache/cassandra-java-driver/pull/1918#issuecomment-1993839304
Actually, exception thrown by below line will not move to the whenComplete
block following that. Basically, problem is that we have logic and exception
thrown outside of thenApplyAsync.
`
schemaQueriesFactory
.newInstance()
.execute()
`
Attaching one sample java program which could be tried out to highlight the
same problem. It will block the thread and not print the final result because
of exception thrown in
> FetchData.newInstance().fetchData()
`package org.example.java8;
import
com.datastax.oss.driver.internal.core.util.concurrent.CompletableFutures;
import java.util.concurrent.CompletableFuture;
public class CompletableFutureMain {
public static void main(String[] args) {
CompletableFuture resultFuture = new CompletableFuture<>();
CompletableFuture fetchFuture =
CompletableFuture.supplyAsync(CompletableFutureMain::fetchData);
CompletableFuture processFuture =
fetchFuture.thenCompose(CompletableFutureMain::processAsync);
processFuture.whenComplete((result, exception) -> {
if (exception != null) {
resultFuture.completeExceptionally(exception);
System.out.println("Exception occurred : " +
exception.getMessage());
} else {
System.out.println("Processed result : " + result);
/*try {*/
FetchData.newInstance().fetchData()/*.exceptionally(ex -> {
resultFuture.completeExceptionally(ex);
return "9";
})*/
.thenApplyAsync(CompletableFutureMain::processData)
.whenComplete((result1, exception1) -> {
if (exception1 != null) {
resultFuture.completeExceptionally(exception1);
System.out.println("Exception occurred 1 : "
+ exception1.getMessage());
} else {
resultFuture.complete(result1);
System.out.println("Processed result 1 : " +
result1);
}
});
/*} catch (Exception exception2) {
resultFuture.completeExceptionally(exception2);
System.out.println("No result");
}*/
}
});
Integer result = CompletableFutures.getUninterruptibly(resultFuture);
System.out.println("Final Result " + result);
}
// Simulated data processing operation
private static Integer processData(String data) {
int value = Integer.parseInt(data);
/*throw new IllegalStateException("Error while processing data
!!");*/
return value * 3;
}
// Simulated data fetching operation
private static String fetchData() {
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
e.printStackTrace();
}
return "10";
}
// Simulated data processing operation
private static CompletableFuture processAsync(String data) {
return CompletableFuture.supplyAsync(() -> {
int value = Integer.parseInt(data);
return value * 2;
});
}
}
class FetchData {
private final CompletableFuture resultFuture = new
CompletableFuture<>();
private FetchData() {
}
public static FetchData newInstance() {
return new FetchData();
}
// Simulated data fetching operation
public CompletableFuture fetchData() {
try {
Thread.sleep(1000);
throw new IllegalStateException("Error in fetching data !!");
} catch (InterruptedException e) {
e.printStackTrace();
}
resultFuture.complete("10");
return resultFuture;
}
}`
--
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] [Commented] (CASSANDRA-19042) Repair fuzz tests fail with paxos_variant: v2
[
https://issues.apache.org/jira/browse/CASSANDRA-19042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17825949#comment-17825949
]
Berenguer Blasi commented on CASSANDRA-19042:
-
5.0 looks like is nearing completion :fireworks: so any help here from someone
knowledgeable would be great! #collaborating
> Repair fuzz tests fail with paxos_variant: v2
> -
>
> Key: CASSANDRA-19042
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19042
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Repair, Feature/Lightweight Transactions,
> Test/fuzz
>Reporter: Branimir Lambov
>Assignee: David Capwell
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
> Time Spent: 2h 10m
> Remaining Estimate: 0h
>
> Adding {{paxos_variant: v2}} to the test yaml causes all fuzz repair tests to
> fail with
> {code}
> java.lang.NullPointerException: null
> at
> org.apache.cassandra.gms.EndpointStateSerializer.serializedSize(EndpointState.java:337)
> at
> org.apache.cassandra.gms.EndpointStateSerializer.serializedSize(EndpointState.java:300)
> at
> org.apache.cassandra.service.paxos.cleanup.PaxosStartPrepareCleanup$RequestSerializer.serializedSize(PaxosStartPrepareCleanup.java:176)
> at
> org.apache.cassandra.service.paxos.cleanup.PaxosStartPrepareCleanup$RequestSerializer.serializedSize(PaxosStartPrepareCleanup.java:147)
> at
> org.apache.cassandra.net.Message$Serializer.payloadSize(Message.java:1067)
> at org.apache.cassandra.net.Message.payloadSize(Message.java:1114)
> at
> org.apache.cassandra.net.Message$Serializer.serializedSize(Message.java:750)
> at org.apache.cassandra.net.Message.serializedSize(Message.java:1094)
> ...
> {code}
> This happens for all three options of {{paxos_state_purging}} and both with
> and without {{storage_compatibility_mode: NONE}}.
> Tests still fail if {{PaxosStartPrepareCleanup}} is changed to use
> {{EndpointState.nullableSerializer}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-19466) Test Failure: testGettingSchemaVersion
[
https://issues.apache.org/jira/browse/CASSANDRA-19466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17825920#comment-17825920
]
Berenguer Blasi edited comment on CASSANDRA-19466 at 3/13/24 6:24 AM:
--
Weird bc I isn't in butler or Jira but you made look in
[jenkins|https://ci-cassandra.apache.org/job/Cassandra-4.1/444/testReport/junit/org.apache.cassandra.schema/SchemaTest/testGettingSchemaVersion_cdc/]
where I found a failure. So not a 5.0 blocker...
was (Author: bereng):
Weird bc I isn't in butler but you made look in
[jenkins|https://ci-cassandra.apache.org/job/Cassandra-4.1/444/testReport/junit/org.apache.cassandra.schema/SchemaTest/testGettingSchemaVersion_cdc/]
where I found a failure. So not a 5.0 blocker...
> Test Failure: testGettingSchemaVersion
> --
>
> Key: CASSANDRA-19466
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19466
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x
>
>
> [Failure|https://app.circleci.com/pipelines/github/bereng/cassandra/1185/workflows/280a09fd-75f7-447e-b94d-9224df3e5045/jobs/39584/tests]
> of org.apache.cassandra.schema.SchemaTest.testGettingSchemaVersion
> {noformat}
> junit.framework.AssertionFailedError:
> Expecting value to be true but was false expected:<[tru]e> but was:<[fals]e>
> at
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.cassandra.schema.SchemaTest.testGettingSchemaVersion(SchemaTest.java:193)
> 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)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19466) Test Failure: testGettingSchemaVersion
[
https://issues.apache.org/jira/browse/CASSANDRA-19466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Berenguer Blasi updated CASSANDRA-19466:
Fix Version/s: 4.0.x
4.1.x
5.0.x
(was: 5.0-rc)
> Test Failure: testGettingSchemaVersion
> --
>
> Key: CASSANDRA-19466
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19466
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x
>
>
> [Failure|https://app.circleci.com/pipelines/github/bereng/cassandra/1185/workflows/280a09fd-75f7-447e-b94d-9224df3e5045/jobs/39584/tests]
> of org.apache.cassandra.schema.SchemaTest.testGettingSchemaVersion
> {noformat}
> junit.framework.AssertionFailedError:
> Expecting value to be true but was false expected:<[tru]e> but was:<[fals]e>
> at
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.cassandra.schema.SchemaTest.testGettingSchemaVersion(SchemaTest.java:193)
> 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)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19466) Test Failure: testGettingSchemaVersion
[
https://issues.apache.org/jira/browse/CASSANDRA-19466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17825920#comment-17825920
]
Berenguer Blasi commented on CASSANDRA-19466:
-
Weird bc I isn't in butler but you made look in
[jenkins|https://ci-cassandra.apache.org/job/Cassandra-4.1/444/testReport/junit/org.apache.cassandra.schema/SchemaTest/testGettingSchemaVersion_cdc/]
where I found a failure. So not a 5.0 blocker...
> Test Failure: testGettingSchemaVersion
> --
>
> Key: CASSANDRA-19466
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19466
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Berenguer Blasi
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
>
> [Failure|https://app.circleci.com/pipelines/github/bereng/cassandra/1185/workflows/280a09fd-75f7-447e-b94d-9224df3e5045/jobs/39584/tests]
> of org.apache.cassandra.schema.SchemaTest.testGettingSchemaVersion
> {noformat}
> junit.framework.AssertionFailedError:
> Expecting value to be true but was false expected:<[tru]e> but was:<[fals]e>
> at
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.cassandra.schema.SchemaTest.testGettingSchemaVersion(SchemaTest.java:193)
> 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)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
