[jira] [Commented] (CASSANDRA-18999) Gossiper::hasMajorVersion3Nodes returns true when a cluster is upgrading patch version without Cassandra 3 nodes.
[
https://issues.apache.org/jira/browse/CASSANDRA-18999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17804166#comment-17804166
]
Stefan Miklosovic commented on CASSANDRA-18999:
---
I am not sure what's the problem either. The same set of tests seem to fail on
4.0 and 4.1 so I do not think this is environmental. Maybe a rerun would
confirm or reject this?
> Gossiper::hasMajorVersion3Nodes returns true when a cluster is upgrading
> patch version without Cassandra 3 nodes.
> -
>
> Key: CASSANDRA-18999
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18999
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Distributed Metadata
>Reporter: Isaac Reath
>Assignee: Isaac Reath
>Priority: Low
> Labels: lhf
> Fix For: 4.0.x, 4.1.x, 5.0.x
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> When working on https://issues.apache.org/jira/browse/CASSANDRA-18968 we
> found that {{Gossiper::hasMajorVersion3Nodes}} will return true when the
> cluster is undergoing an upgrade from a patch version even if the cluster has
> no Cassandra 3 nodes in it.
> This can be reproduced by running this Gossiper test:
> {code:java}
> @Test
> public void
> testHasVersion3NodesShouldReturnFalseWhenNoVersion3NodesDetectedAndCassandra4UpgradeInProgress()
> throws Exception
> {
> Gossiper.instance.start(0);
> Gossiper.instance.expireUpgradeFromVersion();
> VersionedValue.VersionedValueFactory factory = new
> VersionedValue.VersionedValueFactory(null);
> EndpointState es = new EndpointState((HeartBeatState) null);
> es.addApplicationState(ApplicationState.RELEASE_VERSION,
> factory.releaseVersion(CURRENT_VERSION.toString()));
>
> Gossiper.instance.endpointStateMap.put(InetAddressAndPort.getByName("127.0.0.1"),
> es);
>
> Gossiper.instance.liveEndpoints.add(InetAddressAndPort.getByName("127.0.0.1"));
> es = new EndpointState((HeartBeatState) null);
> String previousPatchVersion = String.valueOf(CURRENT_VERSION.major) +
> '.' + (CURRENT_VERSION.minor) + '.' + (CURRENT_VERSION.patch - 1);
> es.addApplicationState(ApplicationState.RELEASE_VERSION,
> factory.releaseVersion(previousPatchVersion));
>
> Gossiper.instance.endpointStateMap.put(InetAddressAndPort.getByName("127.0.0.2"),
> es);
>
> Gossiper.instance.liveEndpoints.add(InetAddressAndPort.getByName("127.0.0.2"));
> assertFalse(Gossiper.instance.hasMajorVersion3Nodes());
> }
> {code}
> This seems to be because of
> [https://github.com/apache/cassandra/blob/cassandra-4.1/src/java/org/apache/cassandra/gms/Gossiper.java#L2360],
> where an upgrade in progress is possible but we are not upgrading from a
> lower family version (i.e from 4.1.1 to 4.1.2).
> From the comment in this function, it seems instead of the existing check, we
> would want to iterate over all known endpoints in gossip and return true if
> any of them do not have a version (similar to
> [https://github.com/apache/cassandra/blob/cassandra-4.1/src/java/org/apache/cassandra/gms/Gossiper.java#L227-L236)
>
> |https://github.com/apache/cassandra/blob/cassandra-4.1/src/java/org/apache/cassandra/gms/Gossiper.java#L227-L236).]
--
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-19187) nodetool assassinate may cause thread serialization for that node
[
https://issues.apache.org/jira/browse/CASSANDRA-19187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17804167#comment-17804167
]
Stefan Miklosovic commented on CASSANDRA-19187:
---
I will merge this after we resolved CASSANDRA-18999
> nodetool assassinate may cause thread serialization for that node
> -
>
> Key: CASSANDRA-19187
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19187
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Membership
>Reporter: Runtian Liu
>Assignee: Runtian Liu
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0.x
>
>
> When assassinate an ip address that is not in the gossip map, a "corrupted"
> entry will be inserted into the gossip map.
> [(1)|https://github.com/apache/cassandra/blob/cassandra-4.0/src/java/org/apache/cassandra/gms/Gossiper.java#L810]
> For example, if we do "nodetool assassinate 10.1.1.1"
> we will get an entry like below by running "nodetool gossipinfo":
>
> {code:java}
> /10.1.1.1
> generation:1702006511
> heartbeat:
> STATUS:209516:LEFT,-8393921141401589197,1702265651923
> STATUS_WITH_PORT:209515:LEFT,-8393921141401589197,1702265651923
> TOKENS: not present {code}
>
> This entry in endpointStateMap will cause issue for
> [isUpgradingFromVersionLowerThan|https://github.com/apache/cassandra/blob/cassandra-4.0/src/java/org/apache/cassandra/gms/Gossiper.java#L2284]
> function. Because the
> [upgradeFromVersionSupplier|https://github.com/apache/cassandra/blob/cassandra-4.0/src/java/org/apache/cassandra/gms/Gossiper.java#L191]
> supplier will always set the
> [allHostsHaveKnownVersion|https://github.com/apache/cassandra/blob/cassandra-4.0/src/java/org/apache/cassandra/gms/Gossiper.java#L216]
> flag to false so no memoized value will be returned. The "get" function will
> always require a lock from this
> [line|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/utils/ExpiringMemoizingSupplier.java#L66].
> If application is using "fetchAll", the native-transport-requests thread will
> hit this
> [line|https://github.com/apache/cassandra/blob/cassandra-4.0/src/java/org/apache/cassandra/db/filter/ColumnFilter.java#L574].
> This means all the native-transport-requests thread is serialized, also, the
> lock is shared by GossipStage threads. It means if a node in a cluster with
> the corrupted gossip map is restart, the node will run into this problem.
> To fix the issue,
> # Why we want to add a dummy entry for nodetool assassinate if the endpoint
> is not in the map anymore. Should we do nothing or throw exception if the
> node is not in the gossip map anymore?
> # Before checking if a version is null, we should make sure the node is not
> a dead node. A decommissioned node, a left node should not be considered part
> of the cluster anymore when calculating "upgradeInProgressPossible"
>
--
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-19187) nodetool assassinate may cause thread serialization for that node
[
https://issues.apache.org/jira/browse/CASSANDRA-19187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-19187:
--
Status: Ready to Commit (was: Review In Progress)
> nodetool assassinate may cause thread serialization for that node
> -
>
> Key: CASSANDRA-19187
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19187
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Membership
>Reporter: Runtian Liu
>Assignee: Runtian Liu
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0.x
>
>
> When assassinate an ip address that is not in the gossip map, a "corrupted"
> entry will be inserted into the gossip map.
> [(1)|https://github.com/apache/cassandra/blob/cassandra-4.0/src/java/org/apache/cassandra/gms/Gossiper.java#L810]
> For example, if we do "nodetool assassinate 10.1.1.1"
> we will get an entry like below by running "nodetool gossipinfo":
>
> {code:java}
> /10.1.1.1
> generation:1702006511
> heartbeat:
> STATUS:209516:LEFT,-8393921141401589197,1702265651923
> STATUS_WITH_PORT:209515:LEFT,-8393921141401589197,1702265651923
> TOKENS: not present {code}
>
> This entry in endpointStateMap will cause issue for
> [isUpgradingFromVersionLowerThan|https://github.com/apache/cassandra/blob/cassandra-4.0/src/java/org/apache/cassandra/gms/Gossiper.java#L2284]
> function. Because the
> [upgradeFromVersionSupplier|https://github.com/apache/cassandra/blob/cassandra-4.0/src/java/org/apache/cassandra/gms/Gossiper.java#L191]
> supplier will always set the
> [allHostsHaveKnownVersion|https://github.com/apache/cassandra/blob/cassandra-4.0/src/java/org/apache/cassandra/gms/Gossiper.java#L216]
> flag to false so no memoized value will be returned. The "get" function will
> always require a lock from this
> [line|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/utils/ExpiringMemoizingSupplier.java#L66].
> If application is using "fetchAll", the native-transport-requests thread will
> hit this
> [line|https://github.com/apache/cassandra/blob/cassandra-4.0/src/java/org/apache/cassandra/db/filter/ColumnFilter.java#L574].
> This means all the native-transport-requests thread is serialized, also, the
> lock is shared by GossipStage threads. It means if a node in a cluster with
> the corrupted gossip map is restart, the node will run into this problem.
> To fix the issue,
> # Why we want to add a dummy entry for nodetool assassinate if the endpoint
> is not in the map anymore. Should we do nothing or throw exception if the
> node is not in the gossip map anymore?
> # Before checking if a version is null, we should make sure the node is not
> a dead node. A decommissioned node, a left node should not be considered part
> of the cluster anymore when calculating "upgradeInProgressPossible"
>
--
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-19187) nodetool assassinate may cause thread serialization for that node
[
https://issues.apache.org/jira/browse/CASSANDRA-19187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-19187:
--
Reviewers: Brandon Williams, Stefan Miklosovic, Stefan Miklosovic (was:
Brandon Williams, Stefan Miklosovic)
Brandon Williams, Stefan Miklosovic, Stefan Miklosovic (was:
Brandon Williams, Stefan Miklosovic)
Status: Review In Progress (was: Patch Available)
> nodetool assassinate may cause thread serialization for that node
> -
>
> Key: CASSANDRA-19187
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19187
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Membership
>Reporter: Runtian Liu
>Assignee: Runtian Liu
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0.x
>
>
> When assassinate an ip address that is not in the gossip map, a "corrupted"
> entry will be inserted into the gossip map.
> [(1)|https://github.com/apache/cassandra/blob/cassandra-4.0/src/java/org/apache/cassandra/gms/Gossiper.java#L810]
> For example, if we do "nodetool assassinate 10.1.1.1"
> we will get an entry like below by running "nodetool gossipinfo":
>
> {code:java}
> /10.1.1.1
> generation:1702006511
> heartbeat:
> STATUS:209516:LEFT,-8393921141401589197,1702265651923
> STATUS_WITH_PORT:209515:LEFT,-8393921141401589197,1702265651923
> TOKENS: not present {code}
>
> This entry in endpointStateMap will cause issue for
> [isUpgradingFromVersionLowerThan|https://github.com/apache/cassandra/blob/cassandra-4.0/src/java/org/apache/cassandra/gms/Gossiper.java#L2284]
> function. Because the
> [upgradeFromVersionSupplier|https://github.com/apache/cassandra/blob/cassandra-4.0/src/java/org/apache/cassandra/gms/Gossiper.java#L191]
> supplier will always set the
> [allHostsHaveKnownVersion|https://github.com/apache/cassandra/blob/cassandra-4.0/src/java/org/apache/cassandra/gms/Gossiper.java#L216]
> flag to false so no memoized value will be returned. The "get" function will
> always require a lock from this
> [line|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/utils/ExpiringMemoizingSupplier.java#L66].
> If application is using "fetchAll", the native-transport-requests thread will
> hit this
> [line|https://github.com/apache/cassandra/blob/cassandra-4.0/src/java/org/apache/cassandra/db/filter/ColumnFilter.java#L574].
> This means all the native-transport-requests thread is serialized, also, the
> lock is shared by GossipStage threads. It means if a node in a cluster with
> the corrupted gossip map is restart, the node will run into this problem.
> To fix the issue,
> # Why we want to add a dummy entry for nodetool assassinate if the endpoint
> is not in the map anymore. Should we do nothing or throw exception if the
> node is not in the gossip map anymore?
> # Before checking if a version is null, we should make sure the node is not
> a dead node. A decommissioned node, a left node should not be considered part
> of the cluster anymore when calculating "upgradeInProgressPossible"
>
--
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-19187) nodetool assassinate may cause thread serialization for that node
[
https://issues.apache.org/jira/browse/CASSANDRA-19187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17804167#comment-17804167
]
Stefan Miklosovic edited comment on CASSANDRA-19187 at 1/8/24 8:35 AM:
---
I will merge this after we resolve CASSANDRA-18999
was (Author: smiklosovic):
I will merge this after we resolved CASSANDRA-18999
> nodetool assassinate may cause thread serialization for that node
> -
>
> Key: CASSANDRA-19187
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19187
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Membership
>Reporter: Runtian Liu
>Assignee: Runtian Liu
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0.x
>
>
> When assassinate an ip address that is not in the gossip map, a "corrupted"
> entry will be inserted into the gossip map.
> [(1)|https://github.com/apache/cassandra/blob/cassandra-4.0/src/java/org/apache/cassandra/gms/Gossiper.java#L810]
> For example, if we do "nodetool assassinate 10.1.1.1"
> we will get an entry like below by running "nodetool gossipinfo":
>
> {code:java}
> /10.1.1.1
> generation:1702006511
> heartbeat:
> STATUS:209516:LEFT,-8393921141401589197,1702265651923
> STATUS_WITH_PORT:209515:LEFT,-8393921141401589197,1702265651923
> TOKENS: not present {code}
>
> This entry in endpointStateMap will cause issue for
> [isUpgradingFromVersionLowerThan|https://github.com/apache/cassandra/blob/cassandra-4.0/src/java/org/apache/cassandra/gms/Gossiper.java#L2284]
> function. Because the
> [upgradeFromVersionSupplier|https://github.com/apache/cassandra/blob/cassandra-4.0/src/java/org/apache/cassandra/gms/Gossiper.java#L191]
> supplier will always set the
> [allHostsHaveKnownVersion|https://github.com/apache/cassandra/blob/cassandra-4.0/src/java/org/apache/cassandra/gms/Gossiper.java#L216]
> flag to false so no memoized value will be returned. The "get" function will
> always require a lock from this
> [line|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/utils/ExpiringMemoizingSupplier.java#L66].
> If application is using "fetchAll", the native-transport-requests thread will
> hit this
> [line|https://github.com/apache/cassandra/blob/cassandra-4.0/src/java/org/apache/cassandra/db/filter/ColumnFilter.java#L574].
> This means all the native-transport-requests thread is serialized, also, the
> lock is shared by GossipStage threads. It means if a node in a cluster with
> the corrupted gossip map is restart, the node will run into this problem.
> To fix the issue,
> # Why we want to add a dummy entry for nodetool assassinate if the endpoint
> is not in the map anymore. Should we do nothing or throw exception if the
> node is not in the gossip map anymore?
> # Before checking if a version is null, we should make sure the node is not
> a dead node. A decommissioned node, a left node should not be considered part
> of the cluster anymore when calculating "upgradeInProgressPossible"
>
--
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-19126) Streaming appears to be incompatible with different storage_compatibility_mode settings
[
https://issues.apache.org/jira/browse/CASSANDRA-19126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17804175#comment-17804175
]
Berenguer Blasi commented on CASSANDRA-19126:
-
bq. Perhaps, value of "4" should be immediately deprecated?
I'm in support of that or just clarifying it in the docs . Otherwise your
cornering yourself to effectively supporting a chained N-1 on all versions
going forward
> Streaming appears to be incompatible with different
> storage_compatibility_mode settings
> ---
>
> Key: CASSANDRA-19126
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19126
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Streaming, Legacy/Streaming and Messaging,
> Messaging/Internode, Tool/bulk load
>Reporter: Branimir Lambov
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
>
> In particular, SSTableLoader appears to be incompatible with
> storage_compatibility_mode: NONE, which manifests as a failure of
> {{org.apache.cassandra.distributed.test.SSTableLoaderEncryptionOptionsTest}}
> when the flag is turned on (found during CASSANDRA-18753 testing). Setting
> {{storage_compatibility_mode: NONE}} in the tool configuration yaml does not
> help (according to the docs, this setting is not picked up).
> This is likely a bigger problem as the acceptable streaming version for C* 5
> is 12 only in legacy mode and 13 only in none, i.e. two C* 5 nodes do not
> appear to be able to stream with each other if their setting for the
> compatibility mode is different.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-18288) Test Failure: TopPartitionsTest.basicRegularTombstonesTest
[
https://issues.apache.org/jira/browse/CASSANDRA-18288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Berenguer Blasi reassigned CASSANDRA-18288:
---
Assignee: (was: Berenguer Blasi)
> Test Failure: TopPartitionsTest.basicRegularTombstonesTest
> --
>
> Key: CASSANDRA-18288
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18288
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: Michael Semb Wever
>Priority: Normal
> Fix For: 5.0.x, 5.x
>
>
> from
> -
> https://ci-cassandra.apache.org/job/Cassandra-trunk/1469/testReport/org.apache.cassandra.distributed.test/TopPartitionsTest/basicRegularTombstonesTest_Incremental___jdk11/
> -
> https://ci-cassandra.apache.org/job/Cassandra-trunk-jvm-dtest/1534/jdk=jdk_11_latest,label=cassandra,split=8/testReport/junit/org.apache.cassandra.distributed.test/TopPartitionsTest/basicRegularTombstonesTest_Incremental___jdk11/
> Stacktrace
> {noformat}
> java.lang.RuntimeException:
> at org.psjava.util.AssertStatus.assertTrue(AssertStatus.java:18)
> at org.psjava.util.AssertStatus.assertTrue(AssertStatus.java:5)
> at
> org.apache.cassandra.distributed.test.TopPartitionsTest.lambda$basicRegularTombstonesTest$e2f532b5$1(TopPartitionsTest.java:226)
> at org.apache.cassandra.concurrent.FutureTask$1.call(FutureTask.java:96)
> at org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:61)
> at org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:71)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:829)
> {noformat}
> Standard Output
> {noformat}
> INFO [main] 2023-02-25 00:15:20,407 Reflections.java:219 -
> Reflections took 1661 ms to scan 9 urls, producing 1832 keys and 7268 values
> INFO [main] 2023-02-25 00:15:21,602 Reflections.java:219 -
> Reflections took 1131 ms to scan 9 urls, producing 1832 keys and 7268 values
> Node id topology:
> node 1: dc = datacenter0, rack = rack0
> node 2: dc = datacenter0, rack = rack0
> Configured node count: 2, nodeIdTopology size: 2
> DEBUG [main] node1 2023-02-25 00:15:22,419 InternalLoggerFactory.java:63 -
> Using SLF4J as the default logging framework
> DEBUG [main] node1 2023-02-25 00:15:22,426 PlatformDependent0.java:417 -
> -Dio.netty.noUnsafe: false
> DEBUG [main] node1 2023-02-25 00:15:22,427 PlatformDependent0.java:897 - Java
> version: 11
> DEBUG [main] node1 2023-02-25 00:15:22,428 PlatformDependent0.java:130 -
> sun.misc.Unsafe.theUnsafe: available
> DEBUG [main] node1 2023-02-25 00:15:22,429 PlatformDependent0.java:154 -
> sun.misc.Unsafe.copyMemory: available
> DEBUG [main] node1 2023-02-25 00:15:22,430 PlatformDependent0.java:192 -
> java.nio.Buffer.address: available
> DEBUG [main] node1 2023-02-25 00:15:22,431 PlatformDependent0.java:257 -
> direct buffer constructor: available
> DEBUG [main] node1 2023-02-25 00:15:22,432 PlatformDependent0.java:331 -
> java.nio.Bits.unaligned: available, true
> DEBUG [main] node1 2023-02-25 00:15:22,434 PlatformDependent0.java:393 -
> jdk.internal.misc.Unsafe.allocateUninitializedArray(int): available
> DEBUG [main] node1 2023-02-25 00:15:22,435 PlatformDependent0.java:403 -
> java.nio.DirectByteBuffer.(long, int): available
> DEBUG [main] node1 2023-02-25 00:15:22,435 PlatformDependent.java:1079 -
> sun.misc.Unsafe: available
> DEBUG [main] node1 2023-02-25 00:15:22,448 PlatformDependent.java:1181 -
> maxDirectMemory: 1056309248 bytes (maybe)
> DEBUG [main] node1 2023-02-25 00:15:22,449 PlatformDependent.java:1200 -
> -Dio.netty.tmpdir: /home/cassandra/cassandra/tmp (java.io.tmpdir)
> DEBUG [main] node1 2023-02-25 00:15:22,449 PlatformDependent.java:1279 -
> -Dio.netty.bitMode: 64 (sun.arch.data.model)
> DEBUG [main] node1 2023-02-25 00:15:22,450 PlatformDependent.java:177 -
> -Dio.netty.maxDirectMemory: 1056309248 bytes
> DEBUG [main] node1 2023-02-25 00:15:22,451 PlatformDependent.java:184 -
> -Dio.netty.uninitializedArrayAllocationThreshold: 1024
> DEBUG [main] node1 2023-02-25 00:15:22,452 CleanerJava9.java:71 -
> java.nio.ByteBuffer.cleaner(): available
> DEBUG [main] node1 2023-02-25 00:15:22,453 PlatformDependent.java:204 -
> -Dio.netty.noPreferDirect: false
> DEBUG [main] node2 2023-02-25 00:15:23,126 InternalLoggerFactory.java:63 -
> Using SLF4J as the default logging framework
> DEBUG [main] node2 2023-02-25 00:15:23,133 PlatformDependent0.java:417 -
> -Dio.netty.noUnsafe: false
> DEBUG [main] node2 2023-02-25 00:15:23,134 PlatformDe
[jira] [Commented] (CASSANDRA-17667) Text value containing "/*" interpreted as multiline comment in cqlsh
[
https://issues.apache.org/jira/browse/CASSANDRA-17667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17804194#comment-17804194
]
Berenguer Blasi commented on CASSANDRA-17667:
-
If tests pass then that settles it. I am still uneasy as to why the removal of
that code has no effect on comments. I noticed a new test with '/*' was added
for a _field value_. Should we add one with '*/', one with '/*blabla*/',
pg-style quoted equivalents and a multiline for _field values_?
> Text value containing "/*" interpreted as multiline comment in cqlsh
>
>
> Key: CASSANDRA-17667
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17667
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: ANOOP THOMAS
>Assignee: Brad Schoening
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.x
>
>
> I use CQLSH command line utility to load some DDLs. The version of utility I
> use is this:
> {noformat}
> [cqlsh 6.0.0 | Cassandra 4.0.0.47 | CQL spec 3.4.5 | Native protocol
> v5]{noformat}
> Command that loads DDL.cql:
> {noformat}
> cqlsh -u username -p password cassandra.example.com 65503 --ssl -f DDL.cql
> {noformat}
> I have a line in CQL script that breaks the syntax.
> {noformat}
> INSERT into tablename (key,columnname1,columnname2) VALUES
> ('keyName','value1','/value2/*/value3');{noformat}
> {{/*}} here is interpreted as start of multi-line comment. It used to work on
> older versions of cqlsh. The error I see looks like this:
> {noformat}
> SyntaxException: line 4:2 mismatched input 'Update' expecting ')'
> (...,'value1','/value2INSERT into tablename(INSERT into tablename
> (key,columnname1,columnname2)) VALUES ('[Update]-...) SyntaxException: line
> 1:0 no viable alternative at input '(' ([(]...)
> {noformat}
> Same behavior while running in interactive mode too. {{/*}} inside a CQL
> statement should not be interpreted as start of multi-line comment.
> With schema:
> {code:java}
> CREATE TABLE tablename ( key text primary key, columnname1 text, columnname2
> text);{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] [Comment Edited] (CASSANDRA-17667) Text value containing "/*" interpreted as multiline comment in cqlsh
[
https://issues.apache.org/jira/browse/CASSANDRA-17667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17804194#comment-17804194
]
Berenguer Blasi edited comment on CASSANDRA-17667 at 1/8/24 9:18 AM:
-
If tests pass then that settles it. I am still uneasy as to why the removal of
that code has no effect on comments. I noticed a new test with {{'/*'}} was
added for a _field value_. Should we add one with {{'*/'}}, one with
{{'/*blabla*/'}}, pg-style quoted equivalents and a multiline for _field
values_?
was (Author: bereng):
If tests pass then that settles it. I am still uneasy as to why the removal of
that code has no effect on comments. I noticed a new test with '/*' was added
for a _field value_. Should we add one with '*/', one with '/*blabla*/',
pg-style quoted equivalents and a multiline for _field values_?
> Text value containing "/*" interpreted as multiline comment in cqlsh
>
>
> Key: CASSANDRA-17667
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17667
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: ANOOP THOMAS
>Assignee: Brad Schoening
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.x
>
>
> I use CQLSH command line utility to load some DDLs. The version of utility I
> use is this:
> {noformat}
> [cqlsh 6.0.0 | Cassandra 4.0.0.47 | CQL spec 3.4.5 | Native protocol
> v5]{noformat}
> Command that loads DDL.cql:
> {noformat}
> cqlsh -u username -p password cassandra.example.com 65503 --ssl -f DDL.cql
> {noformat}
> I have a line in CQL script that breaks the syntax.
> {noformat}
> INSERT into tablename (key,columnname1,columnname2) VALUES
> ('keyName','value1','/value2/*/value3');{noformat}
> {{/*}} here is interpreted as start of multi-line comment. It used to work on
> older versions of cqlsh. The error I see looks like this:
> {noformat}
> SyntaxException: line 4:2 mismatched input 'Update' expecting ')'
> (...,'value1','/value2INSERT into tablename(INSERT into tablename
> (key,columnname1,columnname2)) VALUES ('[Update]-...) SyntaxException: line
> 1:0 no viable alternative at input '(' ([(]...)
> {noformat}
> Same behavior while running in interactive mode too. {{/*}} inside a CQL
> statement should not be interpreted as start of multi-line comment.
> With schema:
> {code:java}
> CREATE TABLE tablename ( key text primary key, columnname1 text, columnname2
> text);{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] [Comment Edited] (CASSANDRA-17667) Text value containing "/*" interpreted as multiline comment in cqlsh
[
https://issues.apache.org/jira/browse/CASSANDRA-17667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17804194#comment-17804194
]
Berenguer Blasi edited comment on CASSANDRA-17667 at 1/8/24 9:19 AM:
-
If tests pass then that settles it. I am still uneasy as to why the removal of
that code has no effect on comments. I noticed a new test with '/\*' was added
for a _field value_. Should we add one with '\*/', one with '/\*blabla\*/',
pg-style quoted equivalents and a multiline for _field values_?
was (Author: bereng):
If tests pass then that settles it. I am still uneasy as to why the removal of
that code has no effect on comments. I noticed a new test with {{'/*'}} was
added for a _field value_. Should we add one with {{'*/'}}, one with
{{'/*blabla*/'}}, pg-style quoted equivalents and a multiline for _field
values_?
> Text value containing "/*" interpreted as multiline comment in cqlsh
>
>
> Key: CASSANDRA-17667
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17667
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: ANOOP THOMAS
>Assignee: Brad Schoening
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.x
>
>
> I use CQLSH command line utility to load some DDLs. The version of utility I
> use is this:
> {noformat}
> [cqlsh 6.0.0 | Cassandra 4.0.0.47 | CQL spec 3.4.5 | Native protocol
> v5]{noformat}
> Command that loads DDL.cql:
> {noformat}
> cqlsh -u username -p password cassandra.example.com 65503 --ssl -f DDL.cql
> {noformat}
> I have a line in CQL script that breaks the syntax.
> {noformat}
> INSERT into tablename (key,columnname1,columnname2) VALUES
> ('keyName','value1','/value2/*/value3');{noformat}
> {{/*}} here is interpreted as start of multi-line comment. It used to work on
> older versions of cqlsh. The error I see looks like this:
> {noformat}
> SyntaxException: line 4:2 mismatched input 'Update' expecting ')'
> (...,'value1','/value2INSERT into tablename(INSERT into tablename
> (key,columnname1,columnname2)) VALUES ('[Update]-...) SyntaxException: line
> 1:0 no viable alternative at input '(' ([(]...)
> {noformat}
> Same behavior while running in interactive mode too. {{/*}} inside a CQL
> statement should not be interpreted as start of multi-line comment.
> With schema:
> {code:java}
> CREATE TABLE tablename ( key text primary key, columnname1 text, columnname2
> text);{code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19120) local consistencies may get timeout if blocking read repair is sending the read repair mutation to other DC
[ https://issues.apache.org/jira/browse/CASSANDRA-19120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17804204#comment-17804204 ] Stefan Miklosovic commented on CASSANDRA-19120: --- I am OK with that, we just need to find another committer (these are the rules we play with here). Looking into git blame, I see [~samt] [~bdeggleston] as the last people who touched that code. Any chance they will review this, at least conceptually? > local consistencies may get timeout if blocking read repair is sending the > read repair mutation to other DC > > > Key: CASSANDRA-19120 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19120 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Repair >Reporter: Runtian Liu >Assignee: Runtian Liu >Priority: Normal > Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x > > Attachments: image-2023-11-29-15-26-08-056.png, signature.asc > > Time Spent: 10m > Remaining Estimate: 0h > > For a two DCs cluster setup. When a new node is being added to DC1, for > blocking read repair triggered by local_quorum in DC1, it will require to > send read repair mutation to an extra node(1)(2). The selector for read > repair may select *ANY* node that has not been contacted before(3) instead of > selecting the DC1 nodes. If a node from DC2 is selected, this will cause 100% > timeout because of the bug described below: > When we initialized the latch(4) for blocking read repair, the shouldBlockOn > function will only return true for local nodes(5), the blockFor value will be > reduced if a local node doesn't require repair(6). The blockFor is same as > the number of read repair mutation sent out. But when the coordinator node > receives the response from the target nodes, the latch only count down for > nodes in same DC(7). The latch will wait till timeout and the read request > will timeout. > This can be reproduced if you have a constant load on a 3 + 3 cluster when > adding a node. If you have someway to trigger blocking read repair(maybe by > adding load using stress tool). If you use local_quorum consistency with a > constant read after write load in the same DC that you are adding node. You > will see read timeout issue from time to time because of the bug described > above > > I think for read repair when selecting the extra node to do repair, we should > prefer local nodes than the nodes from other region. Also, we need to fix the > latch part so even if we send mutation to the nodes in other DC, we don't get > a timeout. > (1)[https://github.com/apache/cassandra/blob/cassandra-4.0.11/src/java/org/apache/cassandra/locator/ReplicaPlans.java#L455] > (2)[https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/ConsistencyLevel.java#L183] > (3)[https://github.com/apache/cassandra/blob/cassandra-4.0.11/src/java/org/apache/cassandra/locator/ReplicaPlans.java#L458] > (4)[https://github.com/apache/cassandra/blob/cassandra-4.0.11/src/java/org/apache/cassandra/service/reads/repair/BlockingPartitionRepair.java#L96] > (5)[https://github.com/apache/cassandra/blob/cassandra-4.0.11/src/java/org/apache/cassandra/service/reads/repair/BlockingPartitionRepair.java#L71] > (6)[https://github.com/apache/cassandra/blob/cassandra-4.0.11/src/java/org/apache/cassandra/service/reads/repair/BlockingPartitionRepair.java#L88] > (7)[https://github.com/apache/cassandra/blob/cassandra-4.0.11/src/java/org/apache/cassandra/service/reads/repair/BlockingPartitionRepair.java#L113] > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19162) Test Failure: SSTableCorruptionDetectionTest.testSinglePartitionIterator
[
https://issues.apache.org/jira/browse/CASSANDRA-19162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17804207#comment-17804207
]
Berenguer Blasi commented on CASSANDRA-19162:
-
^Actually you're right. I'm +1 on closing until sthg that we can work with
comes up...
> Test Failure:
> SSTableCorruptionDetectionTest.testSinglePartitionIterator
> -
>
> Key: CASSANDRA-19162
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19162
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
>
> [https://ci-cassandra.apache.org/job/Cassandra-trunk/1785/testReport/org.apache.cassandra.io.sstable/SSTableCorruptionDetectionTest/testSinglePartitionIterator_cassandra_testtag_IS_UNDEFINED/]
> h3.
> {code:java}
> Error Message
> Timeout occurred. Please note the time in the report does not reflect the
> time until the timeout.
> Stacktrace
> junit.framework.AssertionFailedError: Timeout occurred. Please note the time
> in the report does not reflect the time until the timeout. at
> jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source) at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.util.Vector.forEach(Vector.java:1365) at
> jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source) at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source) at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.util.Vector.forEach(Vector.java:1365) at
> jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source) at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at jdk.internal.reflect.GeneratedMethodAccessor49.invoke(Unknown Source) at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.util.Vector.forEach(Vector.java:1365) at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method) at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at org.apache.cassandra.anttasks.TestHelper.execute(TestHelper.java:53) at
> jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source) at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.util.Vector.forEach(Vector.java:1365) at
> jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source) at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source) at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {code}
> This test has timedout many times on trunk these days (5 out of 7), I found
> the same failure only once on 5.0 in Jenkins
> [https://ci-cassandra.apache.org/job/Cassandra-5.0/116/testReport/org.apache.cassandra.io.sstable/SSTableCorruptionDetectionTest/testSinglePartitionIterator_cassandra_testtag_IS_UNDEFINED/]
>
--
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-19120) local consistencies may get timeout if blocking read repair is sending the read repair mutation to other DC
[ https://issues.apache.org/jira/browse/CASSANDRA-19120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-19120: -- Status: Needs Committer (was: Review In Progress) > local consistencies may get timeout if blocking read repair is sending the > read repair mutation to other DC > > > Key: CASSANDRA-19120 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19120 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Repair >Reporter: Runtian Liu >Assignee: Runtian Liu >Priority: Normal > Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x > > Attachments: image-2023-11-29-15-26-08-056.png, signature.asc > > Time Spent: 10m > Remaining Estimate: 0h > > For a two DCs cluster setup. When a new node is being added to DC1, for > blocking read repair triggered by local_quorum in DC1, it will require to > send read repair mutation to an extra node(1)(2). The selector for read > repair may select *ANY* node that has not been contacted before(3) instead of > selecting the DC1 nodes. If a node from DC2 is selected, this will cause 100% > timeout because of the bug described below: > When we initialized the latch(4) for blocking read repair, the shouldBlockOn > function will only return true for local nodes(5), the blockFor value will be > reduced if a local node doesn't require repair(6). The blockFor is same as > the number of read repair mutation sent out. But when the coordinator node > receives the response from the target nodes, the latch only count down for > nodes in same DC(7). The latch will wait till timeout and the read request > will timeout. > This can be reproduced if you have a constant load on a 3 + 3 cluster when > adding a node. If you have someway to trigger blocking read repair(maybe by > adding load using stress tool). If you use local_quorum consistency with a > constant read after write load in the same DC that you are adding node. You > will see read timeout issue from time to time because of the bug described > above > > I think for read repair when selecting the extra node to do repair, we should > prefer local nodes than the nodes from other region. Also, we need to fix the > latch part so even if we send mutation to the nodes in other DC, we don't get > a timeout. > (1)[https://github.com/apache/cassandra/blob/cassandra-4.0.11/src/java/org/apache/cassandra/locator/ReplicaPlans.java#L455] > (2)[https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/ConsistencyLevel.java#L183] > (3)[https://github.com/apache/cassandra/blob/cassandra-4.0.11/src/java/org/apache/cassandra/locator/ReplicaPlans.java#L458] > (4)[https://github.com/apache/cassandra/blob/cassandra-4.0.11/src/java/org/apache/cassandra/service/reads/repair/BlockingPartitionRepair.java#L96] > (5)[https://github.com/apache/cassandra/blob/cassandra-4.0.11/src/java/org/apache/cassandra/service/reads/repair/BlockingPartitionRepair.java#L71] > (6)[https://github.com/apache/cassandra/blob/cassandra-4.0.11/src/java/org/apache/cassandra/service/reads/repair/BlockingPartitionRepair.java#L88] > (7)[https://github.com/apache/cassandra/blob/cassandra-4.0.11/src/java/org/apache/cassandra/service/reads/repair/BlockingPartitionRepair.java#L113] > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19050) Enhanced usage of test method names in CQLTester for better test debugging
[
https://issues.apache.org/jira/browse/CASSANDRA-19050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17804209#comment-17804209
]
Berenguer Blasi commented on CASSANDRA-19050:
-
ping [~blerer]
> Enhanced usage of test method names in CQLTester for better test debugging
> --
>
> Key: CASSANDRA-19050
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19050
> Project: Cassandra
> Issue Type: Improvement
> Components: Test/unit
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
>
> All views, tables, ks,... created in CQLTester are of the form {{table_00}}:
> - While debugging tests and flakies this makes it really hard to match logs
> to test methods.
> - Some async operations can spill log lines from a previous test method into
> the next's log lines which is incredibly confusing
> - It's hard on the eyes and easy to mix up
> - When comparing logs from 2 different branches, envs,... it's really hard to
> match logs
> The proposed solution is for {{CQLTester}} to decorate these with the test
> name.
--
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-19205) Fix flaky test: org.apache.cassandra.tools.BulkLoaderTest.testBulkLoader_WithArgs1-_jdk17
[
https://issues.apache.org/jira/browse/CASSANDRA-19205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17804212#comment-17804212
]
Berenguer Blasi commented on CASSANDRA-19205:
-
It seems indeed that exclusion is needed. I have been lucky in repro'ing
similar ones with the {{RepeatableRunner}} locally #collaborating. LGTM +1 to
the patch and to extending to the rest of the branches.
> Fix flaky test:
> org.apache.cassandra.tools.BulkLoaderTest.testBulkLoader_WithArgs1-_jdk17
> -
>
> Key: CASSANDRA-19205
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19205
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/bulk load
>Reporter: Brandon Williams
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
>
> Seen here:
> https://app.circleci.com/pipelines/github/driftx/cassandra/1418/workflows/5d108993-69f8-4bb8-a616-93a1d904ff1a/jobs/67177/tests
> {quote}
> junit.framework.AssertionFailedError: Wrong thread status, active threads
> unaccounted for: [cluster2-nio-worker-2]
> at
> org.apache.cassandra.tools.OfflineToolUtils.assertNoUnexpectedThreadsStarted(OfflineToolUtils.java:120)
> at
> org.apache.cassandra.tools.BulkLoaderTest.testBulkLoader_WithArgs1(BulkLoaderTest.java:97)
> 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)
> {quote}
> Looks like either a thread is hanging around too long or we need to except it.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-19215) "Query start time" in native transport request threads should be the task enqueue time
[ https://issues.apache.org/jira/browse/CASSANDRA-19215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Petrov reassigned CASSANDRA-19215: --- Assignee: Alex Petrov > "Query start time" in native transport request threads should be the task > enqueue time > -- > > Key: CASSANDRA-19215 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19215 > Project: Cassandra > Issue Type: Bug > Components: Messaging/Client >Reporter: Runtian Liu >Assignee: Alex Petrov >Priority: Normal > Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x > > > Recently, our Cassandra 4.0.6 cluster experienced an outage due to a surge in > expensive traffic from the application side. This surge involved a large > volume of costly read queries, which took a considerable amount of time to > process on the server side. The client had timeout settings; if a request > timed out, it might trigger the sending of new requests. Since the server > nodes were overloaded, numerous nodes had hundreds of thousands of tasks > queued in the Native-Transport-Request pending queue. I expected that once > the application ceased sending requests, the server node would quickly return > to normal, as most requests in the queue were over half an hour old and > should have timed out rapidly, clearing the queue. However, it actually took > an hour to clear the native transport's pending queue, even with native > transport disabled. Upon examining the code, I noticed that for read/write > requests, the > [queryStartNanoTime|https://github.com/apache/cassandra/blob/cassandra-4.0/src/java/org/apache/cassandra/transport/Dispatcher.java#L78], > which determines if a request has timed out, only begins when the task > starts processing. This means that no matter how long a request has been > pending, it doesn't contribute to the timeout. I believe this is incorrect. > The timer should start when the Cassandra server receives the request or when > it enqueues the task, not when the request/task begins processing. This way, > an overloaded node with many pending tasks can quickly discard timed-out > requests and recover from an outage once new requests stop. -- 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-19215) "Query start time" in native transport request threads should be the task enqueue time
[ https://issues.apache.org/jira/browse/CASSANDRA-19215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17804225#comment-17804225 ] Alex Petrov commented on CASSANDRA-19215: - I have a patch for this pending, will work to CI and submit this ASAP. > "Query start time" in native transport request threads should be the task > enqueue time > -- > > Key: CASSANDRA-19215 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19215 > Project: Cassandra > Issue Type: Bug > Components: Messaging/Client >Reporter: Runtian Liu >Assignee: Alex Petrov >Priority: Normal > Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x > > > Recently, our Cassandra 4.0.6 cluster experienced an outage due to a surge in > expensive traffic from the application side. This surge involved a large > volume of costly read queries, which took a considerable amount of time to > process on the server side. The client had timeout settings; if a request > timed out, it might trigger the sending of new requests. Since the server > nodes were overloaded, numerous nodes had hundreds of thousands of tasks > queued in the Native-Transport-Request pending queue. I expected that once > the application ceased sending requests, the server node would quickly return > to normal, as most requests in the queue were over half an hour old and > should have timed out rapidly, clearing the queue. However, it actually took > an hour to clear the native transport's pending queue, even with native > transport disabled. Upon examining the code, I noticed that for read/write > requests, the > [queryStartNanoTime|https://github.com/apache/cassandra/blob/cassandra-4.0/src/java/org/apache/cassandra/transport/Dispatcher.java#L78], > which determines if a request has timed out, only begins when the task > starts processing. This means that no matter how long a request has been > pending, it doesn't contribute to the timeout. I believe this is incorrect. > The timer should start when the Cassandra server receives the request or when > it enqueues the task, not when the request/task begins processing. This way, > an overloaded node with many pending tasks can quickly discard timed-out > requests and recover from an outage once new requests stop. -- 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-18714) Expand CQLSSTableWriter to write SSTable-attached secondary indexes
[
https://issues.apache.org/jira/browse/CASSANDRA-18714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17804231#comment-17804231
]
Stefan Miklosovic commented on CASSANDRA-18714:
---
I also implemented 4a.
I dont know how to do 4b yet.
> Expand CQLSSTableWriter to write SSTable-attached secondary indexes
> ---
>
> Key: CASSANDRA-18714
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18714
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/SAI, Tool/bulk load
>Reporter: Caleb Rackliffe
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{CQLSSTableWriter}} currently has no way of writing any secondary indexes
> inline as it writes the core SSTable components. With SAI, this has become
> tractable problem, and we should be able to enhance both it and
> {{SSTableImporter}} to handle cases where we might want to write SSTables
> somewhere in bulk (and in parallel) and then import them without waiting for
> index building on import. It would require the following changes:
> 1.) {{CQLSSTableWriter}} must accept 2i definitions on top of its current
> table schema definition. Once added to the schema, any {{ColumnFamilyStore}}
> instances opened will have those 2i defined in their index managers.
> 2.) All {{AbstractSSTableSimpleWriter}} instances must register index groups,
> allowing the proper {{SSTableFlushObservers}} to be attached to
> {{SSTableWriter}}. Once this is done, SAI (and any other SSTable-attached
> indexes) components will be built incrementally along w/ the SSTable data
> file, and will be finalized when the newly written SSTable is finalized.
> 3.) Provide an example (in a unit test?) of how a third-party tool might,
> assuming access to the right C* JAR, validate/checksum SAI components outside
> C* proper.
> 4.) {{SSTableImporter}} should have two new options:
> a.) an option that fails import if any SSTable-attached 2i must be built
> (i.e. has not already been built and brought along w/ the other new SSTable
> components)
> b.) an option that allows us to bypass full checksum validation on
> imported/already-built SSTable-attached indexes (assuming they have just been
> written by {{CQLSSTableWriter}})
--
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-18714) Expand CQLSSTableWriter to write SSTable-attached secondary indexes
[
https://issues.apache.org/jira/browse/CASSANDRA-18714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17803568#comment-17803568
]
Stefan Miklosovic edited comment on CASSANDRA-18714 at 1/8/24 11:00 AM:
[https://github.com/apache/cassandra/pull/3029/files] it writes SASI too ... I
would say it is a good start at least.
was (Author: smiklosovic):
[https://github.com/apache/cassandra/pull/3029/files] it writes SAI too ... I
would say it is a good start at least.
> Expand CQLSSTableWriter to write SSTable-attached secondary indexes
> ---
>
> Key: CASSANDRA-18714
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18714
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/SAI, Tool/bulk load
>Reporter: Caleb Rackliffe
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{CQLSSTableWriter}} currently has no way of writing any secondary indexes
> inline as it writes the core SSTable components. With SAI, this has become
> tractable problem, and we should be able to enhance both it and
> {{SSTableImporter}} to handle cases where we might want to write SSTables
> somewhere in bulk (and in parallel) and then import them without waiting for
> index building on import. It would require the following changes:
> 1.) {{CQLSSTableWriter}} must accept 2i definitions on top of its current
> table schema definition. Once added to the schema, any {{ColumnFamilyStore}}
> instances opened will have those 2i defined in their index managers.
> 2.) All {{AbstractSSTableSimpleWriter}} instances must register index groups,
> allowing the proper {{SSTableFlushObservers}} to be attached to
> {{SSTableWriter}}. Once this is done, SAI (and any other SSTable-attached
> indexes) components will be built incrementally along w/ the SSTable data
> file, and will be finalized when the newly written SSTable is finalized.
> 3.) Provide an example (in a unit test?) of how a third-party tool might,
> assuming access to the right C* JAR, validate/checksum SAI components outside
> C* proper.
> 4.) {{SSTableImporter}} should have two new options:
> a.) an option that fails import if any SSTable-attached 2i must be built
> (i.e. has not already been built and brought along w/ the other new SSTable
> components)
> b.) an option that allows us to bypass full checksum validation on
> imported/already-built SSTable-attached indexes (assuming they have just been
> written by {{CQLSSTableWriter}})
--
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-18999) Gossiper::hasMajorVersion3Nodes returns true when a cluster is upgrading patch version without Cassandra 3 nodes.
[
https://issues.apache.org/jira/browse/CASSANDRA-18999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17804251#comment-17804251
]
Brandon Williams commented on CASSANDRA-18999:
--
I started
[4.0|https://app.circleci.com/pipelines/github/driftx/cassandra/1445/workflows/80335a29-b138-49d3-897a-363c5d558ab5]
and
[4.1|https://app.circleci.com/pipelines/github/driftx/cassandra/1444/workflows/3a517f8a-872b-4119-9dea-fef2fffd78db]
upgrade tests again.
> Gossiper::hasMajorVersion3Nodes returns true when a cluster is upgrading
> patch version without Cassandra 3 nodes.
> -
>
> Key: CASSANDRA-18999
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18999
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Distributed Metadata
>Reporter: Isaac Reath
>Assignee: Isaac Reath
>Priority: Low
> Labels: lhf
> Fix For: 4.0.x, 4.1.x, 5.0.x
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> When working on https://issues.apache.org/jira/browse/CASSANDRA-18968 we
> found that {{Gossiper::hasMajorVersion3Nodes}} will return true when the
> cluster is undergoing an upgrade from a patch version even if the cluster has
> no Cassandra 3 nodes in it.
> This can be reproduced by running this Gossiper test:
> {code:java}
> @Test
> public void
> testHasVersion3NodesShouldReturnFalseWhenNoVersion3NodesDetectedAndCassandra4UpgradeInProgress()
> throws Exception
> {
> Gossiper.instance.start(0);
> Gossiper.instance.expireUpgradeFromVersion();
> VersionedValue.VersionedValueFactory factory = new
> VersionedValue.VersionedValueFactory(null);
> EndpointState es = new EndpointState((HeartBeatState) null);
> es.addApplicationState(ApplicationState.RELEASE_VERSION,
> factory.releaseVersion(CURRENT_VERSION.toString()));
>
> Gossiper.instance.endpointStateMap.put(InetAddressAndPort.getByName("127.0.0.1"),
> es);
>
> Gossiper.instance.liveEndpoints.add(InetAddressAndPort.getByName("127.0.0.1"));
> es = new EndpointState((HeartBeatState) null);
> String previousPatchVersion = String.valueOf(CURRENT_VERSION.major) +
> '.' + (CURRENT_VERSION.minor) + '.' + (CURRENT_VERSION.patch - 1);
> es.addApplicationState(ApplicationState.RELEASE_VERSION,
> factory.releaseVersion(previousPatchVersion));
>
> Gossiper.instance.endpointStateMap.put(InetAddressAndPort.getByName("127.0.0.2"),
> es);
>
> Gossiper.instance.liveEndpoints.add(InetAddressAndPort.getByName("127.0.0.2"));
> assertFalse(Gossiper.instance.hasMajorVersion3Nodes());
> }
> {code}
> This seems to be because of
> [https://github.com/apache/cassandra/blob/cassandra-4.1/src/java/org/apache/cassandra/gms/Gossiper.java#L2360],
> where an upgrade in progress is possible but we are not upgrading from a
> lower family version (i.e from 4.1.1 to 4.1.2).
> From the comment in this function, it seems instead of the existing check, we
> would want to iterate over all known endpoints in gossip and return true if
> any of them do not have a version (similar to
> [https://github.com/apache/cassandra/blob/cassandra-4.1/src/java/org/apache/cassandra/gms/Gossiper.java#L227-L236)
>
> |https://github.com/apache/cassandra/blob/cassandra-4.1/src/java/org/apache/cassandra/gms/Gossiper.java#L227-L236).]
--
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-18999) Gossiper::hasMajorVersion3Nodes returns true when a cluster is upgrading patch version without Cassandra 3 nodes.
[
https://issues.apache.org/jira/browse/CASSANDRA-18999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17804252#comment-17804252
]
Stefan Miklosovic commented on CASSANDRA-18999:
---
I would be also worth to run these tests _without_ this patch. If it fails
there too, we know we are not the ones to blame.
> Gossiper::hasMajorVersion3Nodes returns true when a cluster is upgrading
> patch version without Cassandra 3 nodes.
> -
>
> Key: CASSANDRA-18999
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18999
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Distributed Metadata
>Reporter: Isaac Reath
>Assignee: Isaac Reath
>Priority: Low
> Labels: lhf
> Fix For: 4.0.x, 4.1.x, 5.0.x
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> When working on https://issues.apache.org/jira/browse/CASSANDRA-18968 we
> found that {{Gossiper::hasMajorVersion3Nodes}} will return true when the
> cluster is undergoing an upgrade from a patch version even if the cluster has
> no Cassandra 3 nodes in it.
> This can be reproduced by running this Gossiper test:
> {code:java}
> @Test
> public void
> testHasVersion3NodesShouldReturnFalseWhenNoVersion3NodesDetectedAndCassandra4UpgradeInProgress()
> throws Exception
> {
> Gossiper.instance.start(0);
> Gossiper.instance.expireUpgradeFromVersion();
> VersionedValue.VersionedValueFactory factory = new
> VersionedValue.VersionedValueFactory(null);
> EndpointState es = new EndpointState((HeartBeatState) null);
> es.addApplicationState(ApplicationState.RELEASE_VERSION,
> factory.releaseVersion(CURRENT_VERSION.toString()));
>
> Gossiper.instance.endpointStateMap.put(InetAddressAndPort.getByName("127.0.0.1"),
> es);
>
> Gossiper.instance.liveEndpoints.add(InetAddressAndPort.getByName("127.0.0.1"));
> es = new EndpointState((HeartBeatState) null);
> String previousPatchVersion = String.valueOf(CURRENT_VERSION.major) +
> '.' + (CURRENT_VERSION.minor) + '.' + (CURRENT_VERSION.patch - 1);
> es.addApplicationState(ApplicationState.RELEASE_VERSION,
> factory.releaseVersion(previousPatchVersion));
>
> Gossiper.instance.endpointStateMap.put(InetAddressAndPort.getByName("127.0.0.2"),
> es);
>
> Gossiper.instance.liveEndpoints.add(InetAddressAndPort.getByName("127.0.0.2"));
> assertFalse(Gossiper.instance.hasMajorVersion3Nodes());
> }
> {code}
> This seems to be because of
> [https://github.com/apache/cassandra/blob/cassandra-4.1/src/java/org/apache/cassandra/gms/Gossiper.java#L2360],
> where an upgrade in progress is possible but we are not upgrading from a
> lower family version (i.e from 4.1.1 to 4.1.2).
> From the comment in this function, it seems instead of the existing check, we
> would want to iterate over all known endpoints in gossip and return true if
> any of them do not have a version (similar to
> [https://github.com/apache/cassandra/blob/cassandra-4.1/src/java/org/apache/cassandra/gms/Gossiper.java#L227-L236)
>
> |https://github.com/apache/cassandra/blob/cassandra-4.1/src/java/org/apache/cassandra/gms/Gossiper.java#L227-L236).]
--
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-18999) Gossiper::hasMajorVersion3Nodes returns true when a cluster is upgrading patch version without Cassandra 3 nodes.
[
https://issues.apache.org/jira/browse/CASSANDRA-18999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17804252#comment-17804252
]
Stefan Miklosovic edited comment on CASSANDRA-18999 at 1/8/24 12:29 PM:
It would be also worth to run these tests _without_ this patch. If it fails
there too, we know we are not the ones to blame.
was (Author: smiklosovic):
I would be also worth to run these tests _without_ this patch. If it fails
there too, we know we are not the ones to blame.
> Gossiper::hasMajorVersion3Nodes returns true when a cluster is upgrading
> patch version without Cassandra 3 nodes.
> -
>
> Key: CASSANDRA-18999
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18999
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Distributed Metadata
>Reporter: Isaac Reath
>Assignee: Isaac Reath
>Priority: Low
> Labels: lhf
> Fix For: 4.0.x, 4.1.x, 5.0.x
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> When working on https://issues.apache.org/jira/browse/CASSANDRA-18968 we
> found that {{Gossiper::hasMajorVersion3Nodes}} will return true when the
> cluster is undergoing an upgrade from a patch version even if the cluster has
> no Cassandra 3 nodes in it.
> This can be reproduced by running this Gossiper test:
> {code:java}
> @Test
> public void
> testHasVersion3NodesShouldReturnFalseWhenNoVersion3NodesDetectedAndCassandra4UpgradeInProgress()
> throws Exception
> {
> Gossiper.instance.start(0);
> Gossiper.instance.expireUpgradeFromVersion();
> VersionedValue.VersionedValueFactory factory = new
> VersionedValue.VersionedValueFactory(null);
> EndpointState es = new EndpointState((HeartBeatState) null);
> es.addApplicationState(ApplicationState.RELEASE_VERSION,
> factory.releaseVersion(CURRENT_VERSION.toString()));
>
> Gossiper.instance.endpointStateMap.put(InetAddressAndPort.getByName("127.0.0.1"),
> es);
>
> Gossiper.instance.liveEndpoints.add(InetAddressAndPort.getByName("127.0.0.1"));
> es = new EndpointState((HeartBeatState) null);
> String previousPatchVersion = String.valueOf(CURRENT_VERSION.major) +
> '.' + (CURRENT_VERSION.minor) + '.' + (CURRENT_VERSION.patch - 1);
> es.addApplicationState(ApplicationState.RELEASE_VERSION,
> factory.releaseVersion(previousPatchVersion));
>
> Gossiper.instance.endpointStateMap.put(InetAddressAndPort.getByName("127.0.0.2"),
> es);
>
> Gossiper.instance.liveEndpoints.add(InetAddressAndPort.getByName("127.0.0.2"));
> assertFalse(Gossiper.instance.hasMajorVersion3Nodes());
> }
> {code}
> This seems to be because of
> [https://github.com/apache/cassandra/blob/cassandra-4.1/src/java/org/apache/cassandra/gms/Gossiper.java#L2360],
> where an upgrade in progress is possible but we are not upgrading from a
> lower family version (i.e from 4.1.1 to 4.1.2).
> From the comment in this function, it seems instead of the existing check, we
> would want to iterate over all known endpoints in gossip and return true if
> any of them do not have a version (similar to
> [https://github.com/apache/cassandra/blob/cassandra-4.1/src/java/org/apache/cassandra/gms/Gossiper.java#L227-L236)
>
> |https://github.com/apache/cassandra/blob/cassandra-4.1/src/java/org/apache/cassandra/gms/Gossiper.java#L227-L236).]
--
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-17667) Text value containing "/*" interpreted as multiline comment in cqlsh
[
https://issues.apache.org/jira/browse/CASSANDRA-17667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17804261#comment-17804261
]
Attila Homoki commented on CASSANDRA-17667:
---
_" why the removal of that code has no effect on comments :_ the code was just
a workaround to fix the original issue which was thet the order of the terminal
productions (aka field values) was incorrect.
_"Should we add ..." :_ also tested (manually) with the following field values
and these will work multiline comments.
[...]
::= /[/][*].*[*][/]/ ;
::= /[/][*].*$/ ;
::= /[/][@].*[@][/]/ ;
::= /[/][@].*$/ ;
::= /\$\$(?:(?!\$\$).)*/ ;
::= /'([^']|'')*/ ;
::= /"([^"]|"")*/ ;
[...]
my commit:
[https://github.com/apache/cassandra/commit/84a7fc2629062412303243b09004d03e2a2ade90]
> Text value containing "/*" interpreted as multiline comment in cqlsh
>
>
> Key: CASSANDRA-17667
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17667
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: ANOOP THOMAS
>Assignee: Brad Schoening
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.x
>
>
> I use CQLSH command line utility to load some DDLs. The version of utility I
> use is this:
> {noformat}
> [cqlsh 6.0.0 | Cassandra 4.0.0.47 | CQL spec 3.4.5 | Native protocol
> v5]{noformat}
> Command that loads DDL.cql:
> {noformat}
> cqlsh -u username -p password cassandra.example.com 65503 --ssl -f DDL.cql
> {noformat}
> I have a line in CQL script that breaks the syntax.
> {noformat}
> INSERT into tablename (key,columnname1,columnname2) VALUES
> ('keyName','value1','/value2/*/value3');{noformat}
> {{/*}} here is interpreted as start of multi-line comment. It used to work on
> older versions of cqlsh. The error I see looks like this:
> {noformat}
> SyntaxException: line 4:2 mismatched input 'Update' expecting ')'
> (...,'value1','/value2INSERT into tablename(INSERT into tablename
> (key,columnname1,columnname2)) VALUES ('[Update]-...) SyntaxException: line
> 1:0 no viable alternative at input '(' ([(]...)
> {noformat}
> Same behavior while running in interactive mode too. {{/*}} inside a CQL
> statement should not be interpreted as start of multi-line comment.
> With schema:
> {code:java}
> CREATE TABLE tablename ( key text primary key, columnname1 text, columnname2
> text);{code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18999) Gossiper::hasMajorVersion3Nodes returns true when a cluster is upgrading patch version without Cassandra 3 nodes.
[
https://issues.apache.org/jira/browse/CASSANDRA-18999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17804262#comment-17804262
]
Brandon Williams commented on CASSANDRA-18999:
--
Here's a baseline for
[4.0|https://app.circleci.com/pipelines/github/driftx/cassandra/1454/workflows/0357136e-cee3-42e4-900b-3347fc8d42d3]
and
[4.1|https://app.circleci.com/pipelines/github/driftx/cassandra/1453/workflows/dd1732df-271c-43bc-bc5f-8577c605c746].
> Gossiper::hasMajorVersion3Nodes returns true when a cluster is upgrading
> patch version without Cassandra 3 nodes.
> -
>
> Key: CASSANDRA-18999
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18999
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Distributed Metadata
>Reporter: Isaac Reath
>Assignee: Isaac Reath
>Priority: Low
> Labels: lhf
> Fix For: 4.0.x, 4.1.x, 5.0.x
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> When working on https://issues.apache.org/jira/browse/CASSANDRA-18968 we
> found that {{Gossiper::hasMajorVersion3Nodes}} will return true when the
> cluster is undergoing an upgrade from a patch version even if the cluster has
> no Cassandra 3 nodes in it.
> This can be reproduced by running this Gossiper test:
> {code:java}
> @Test
> public void
> testHasVersion3NodesShouldReturnFalseWhenNoVersion3NodesDetectedAndCassandra4UpgradeInProgress()
> throws Exception
> {
> Gossiper.instance.start(0);
> Gossiper.instance.expireUpgradeFromVersion();
> VersionedValue.VersionedValueFactory factory = new
> VersionedValue.VersionedValueFactory(null);
> EndpointState es = new EndpointState((HeartBeatState) null);
> es.addApplicationState(ApplicationState.RELEASE_VERSION,
> factory.releaseVersion(CURRENT_VERSION.toString()));
>
> Gossiper.instance.endpointStateMap.put(InetAddressAndPort.getByName("127.0.0.1"),
> es);
>
> Gossiper.instance.liveEndpoints.add(InetAddressAndPort.getByName("127.0.0.1"));
> es = new EndpointState((HeartBeatState) null);
> String previousPatchVersion = String.valueOf(CURRENT_VERSION.major) +
> '.' + (CURRENT_VERSION.minor) + '.' + (CURRENT_VERSION.patch - 1);
> es.addApplicationState(ApplicationState.RELEASE_VERSION,
> factory.releaseVersion(previousPatchVersion));
>
> Gossiper.instance.endpointStateMap.put(InetAddressAndPort.getByName("127.0.0.2"),
> es);
>
> Gossiper.instance.liveEndpoints.add(InetAddressAndPort.getByName("127.0.0.2"));
> assertFalse(Gossiper.instance.hasMajorVersion3Nodes());
> }
> {code}
> This seems to be because of
> [https://github.com/apache/cassandra/blob/cassandra-4.1/src/java/org/apache/cassandra/gms/Gossiper.java#L2360],
> where an upgrade in progress is possible but we are not upgrading from a
> lower family version (i.e from 4.1.1 to 4.1.2).
> From the comment in this function, it seems instead of the existing check, we
> would want to iterate over all known endpoints in gossip and return true if
> any of them do not have a version (similar to
> [https://github.com/apache/cassandra/blob/cassandra-4.1/src/java/org/apache/cassandra/gms/Gossiper.java#L227-L236)
>
> |https://github.com/apache/cassandra/blob/cassandra-4.1/src/java/org/apache/cassandra/gms/Gossiper.java#L227-L236).]
--
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-17667) Text value containing "/*" interpreted as multiline comment in cqlsh
[
https://issues.apache.org/jira/browse/CASSANDRA-17667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17804266#comment-17804266
]
Berenguer Blasi commented on CASSANDRA-17667:
-
That commit 84a7fc2629062412303243b09004d03e2a2ade90 is not in the [PR linked
in this ticket|https://github.com/apache/cassandra/pull/2561]. So can you
please confirm which is the code I should be reviewing?
Also even if you tested manually why not add those cases to the test? Am I
missing shtg?
> Text value containing "/*" interpreted as multiline comment in cqlsh
>
>
> Key: CASSANDRA-17667
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17667
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: ANOOP THOMAS
>Assignee: Brad Schoening
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.x
>
>
> I use CQLSH command line utility to load some DDLs. The version of utility I
> use is this:
> {noformat}
> [cqlsh 6.0.0 | Cassandra 4.0.0.47 | CQL spec 3.4.5 | Native protocol
> v5]{noformat}
> Command that loads DDL.cql:
> {noformat}
> cqlsh -u username -p password cassandra.example.com 65503 --ssl -f DDL.cql
> {noformat}
> I have a line in CQL script that breaks the syntax.
> {noformat}
> INSERT into tablename (key,columnname1,columnname2) VALUES
> ('keyName','value1','/value2/*/value3');{noformat}
> {{/*}} here is interpreted as start of multi-line comment. It used to work on
> older versions of cqlsh. The error I see looks like this:
> {noformat}
> SyntaxException: line 4:2 mismatched input 'Update' expecting ')'
> (...,'value1','/value2INSERT into tablename(INSERT into tablename
> (key,columnname1,columnname2)) VALUES ('[Update]-...) SyntaxException: line
> 1:0 no viable alternative at input '(' ([(]...)
> {noformat}
> Same behavior while running in interactive mode too. {{/*}} inside a CQL
> statement should not be interpreted as start of multi-line comment.
> With schema:
> {code:java}
> CREATE TABLE tablename ( key text primary key, columnname1 text, columnname2
> text);{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
Re: [PR] CASSANDRA-19212: Fix forced Spark job timeout in ResiliencyTestBase [cassandra-analytics]
JeetKunDoug commented on code in PR #27:
URL:
https://github.com/apache/cassandra-analytics/pull/27#discussion_r1444638578
##
cassandra-analytics-integration-tests/src/test/java/org/apache/cassandra/analytics/ResiliencyTestBase.java:
##
@@ -375,10 +375,22 @@ protected void bulkWriteData(ConsistencyLevel writeCL,
QualifiedName schema)
if (!completed)
{
process.destroyForcibly();
-finishLatch.await(10, TimeUnit.MINUTES);
+// The process doesn't necessarily finish right after
destroyForcibly, but will exit.
+process.waitFor(1, TimeUnit.MINUTES);
Review Comment:
The comment on 380 is still valid - after 10 minutes, we attempt to kill the
process. I did add "and was killed" along with a bit more commenting on the
additional 1 minute of wait.
--
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-19205) Fix flaky test: org.apache.cassandra.tools.BulkLoaderTest.testBulkLoader_WithArgs1-_jdk17
[
https://issues.apache.org/jira/browse/CASSANDRA-19205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-19205:
Reviewers: Berenguer Blasi (was: Berenguer Blasi, Ekaterina Dimitrova)
> Fix flaky test:
> org.apache.cassandra.tools.BulkLoaderTest.testBulkLoader_WithArgs1-_jdk17
> -
>
> Key: CASSANDRA-19205
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19205
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/bulk load
>Reporter: Brandon Williams
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
>
> Seen here:
> https://app.circleci.com/pipelines/github/driftx/cassandra/1418/workflows/5d108993-69f8-4bb8-a616-93a1d904ff1a/jobs/67177/tests
> {quote}
> junit.framework.AssertionFailedError: Wrong thread status, active threads
> unaccounted for: [cluster2-nio-worker-2]
> at
> org.apache.cassandra.tools.OfflineToolUtils.assertNoUnexpectedThreadsStarted(OfflineToolUtils.java:120)
> at
> org.apache.cassandra.tools.BulkLoaderTest.testBulkLoader_WithArgs1(BulkLoaderTest.java:97)
> 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)
> {quote}
> Looks like either a thread is hanging around too long or we need to except it.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19205) Fix flaky test: org.apache.cassandra.tools.BulkLoaderTest.testBulkLoader_WithArgs1-_jdk17
[
https://issues.apache.org/jira/browse/CASSANDRA-19205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-19205:
Reviewers: Berenguer Blasi, Ekaterina Dimitrova
Status: Review In Progress (was: Patch Available)
> Fix flaky test:
> org.apache.cassandra.tools.BulkLoaderTest.testBulkLoader_WithArgs1-_jdk17
> -
>
> Key: CASSANDRA-19205
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19205
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/bulk load
>Reporter: Brandon Williams
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
>
> Seen here:
> https://app.circleci.com/pipelines/github/driftx/cassandra/1418/workflows/5d108993-69f8-4bb8-a616-93a1d904ff1a/jobs/67177/tests
> {quote}
> junit.framework.AssertionFailedError: Wrong thread status, active threads
> unaccounted for: [cluster2-nio-worker-2]
> at
> org.apache.cassandra.tools.OfflineToolUtils.assertNoUnexpectedThreadsStarted(OfflineToolUtils.java:120)
> at
> org.apache.cassandra.tools.BulkLoaderTest.testBulkLoader_WithArgs1(BulkLoaderTest.java:97)
> 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)
> {quote}
> Looks like either a thread is hanging around too long or we need to except 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-19162) Test Failure: SSTableCorruptionDetectionTest.testSinglePartitionIterator
[
https://issues.apache.org/jira/browse/CASSANDRA-19162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17804325#comment-17804325
]
Ekaterina Dimitrova commented on CASSANDRA-19162:
-
Butler doesn't show it failing anymore, closing for now.
> Test Failure:
> SSTableCorruptionDetectionTest.testSinglePartitionIterator
> -
>
> Key: CASSANDRA-19162
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19162
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
>
> [https://ci-cassandra.apache.org/job/Cassandra-trunk/1785/testReport/org.apache.cassandra.io.sstable/SSTableCorruptionDetectionTest/testSinglePartitionIterator_cassandra_testtag_IS_UNDEFINED/]
> h3.
> {code:java}
> Error Message
> Timeout occurred. Please note the time in the report does not reflect the
> time until the timeout.
> Stacktrace
> junit.framework.AssertionFailedError: Timeout occurred. Please note the time
> in the report does not reflect the time until the timeout. at
> jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source) at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.util.Vector.forEach(Vector.java:1365) at
> jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source) at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source) at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.util.Vector.forEach(Vector.java:1365) at
> jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source) at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at jdk.internal.reflect.GeneratedMethodAccessor49.invoke(Unknown Source) at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.util.Vector.forEach(Vector.java:1365) at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method) at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at org.apache.cassandra.anttasks.TestHelper.execute(TestHelper.java:53) at
> jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source) at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.util.Vector.forEach(Vector.java:1365) at
> jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source) at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source) at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {code}
> This test has timedout many times on trunk these days (5 out of 7), I found
> the same failure only once on 5.0 in Jenkins
> [https://ci-cassandra.apache.org/job/Cassandra-5.0/116/testReport/org.apache.cassandra.io.sstable/SSTableCorruptionDetectionTest/testSinglePartitionIterator_cassandra_testtag_IS_UNDEFINED/]
>
--
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-19162) Test Failure: SSTableCorruptionDetectionTest.testSinglePartitionIterator
[
https://issues.apache.org/jira/browse/CASSANDRA-19162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-19162:
Resolution: Cannot Reproduce
Status: Resolved (was: Open)
> Test Failure:
> SSTableCorruptionDetectionTest.testSinglePartitionIterator
> -
>
> Key: CASSANDRA-19162
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19162
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
>
> [https://ci-cassandra.apache.org/job/Cassandra-trunk/1785/testReport/org.apache.cassandra.io.sstable/SSTableCorruptionDetectionTest/testSinglePartitionIterator_cassandra_testtag_IS_UNDEFINED/]
> h3.
> {code:java}
> Error Message
> Timeout occurred. Please note the time in the report does not reflect the
> time until the timeout.
> Stacktrace
> junit.framework.AssertionFailedError: Timeout occurred. Please note the time
> in the report does not reflect the time until the timeout. at
> jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source) at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.util.Vector.forEach(Vector.java:1365) at
> jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source) at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source) at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.util.Vector.forEach(Vector.java:1365) at
> jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source) at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at jdk.internal.reflect.GeneratedMethodAccessor49.invoke(Unknown Source) at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.util.Vector.forEach(Vector.java:1365) at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method) at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at org.apache.cassandra.anttasks.TestHelper.execute(TestHelper.java:53) at
> jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source) at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.util.Vector.forEach(Vector.java:1365) at
> jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source) at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source) at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {code}
> This test has timedout many times on trunk these days (5 out of 7), I found
> the same failure only once on 5.0 in Jenkins
> [https://ci-cassandra.apache.org/job/Cassandra-5.0/116/testReport/org.apache.cassandra.io.sstable/SSTableCorruptionDetectionTest/testSinglePartitionIterator_cassandra_testtag_IS_UNDEFINED/]
>
--
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-18688) Limit Java runtime in 5.0 to JDK 11 and 17 in scripts; add a flag to opt out of that
[ https://issues.apache.org/jira/browse/CASSANDRA-18688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17804330#comment-17804330 ] Ekaterina Dimitrova commented on CASSANDRA-18688: - Happy New Year! Sorry for the delayed response, I was off for a while. bq. Please let me know if everyone agrees & I will change it & remove the check for 'false' value Looks good to me, thanks! > Limit Java runtime in 5.0 to JDK 11 and 17 in scripts; add a flag to opt out > of that > > > Key: CASSANDRA-18688 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18688 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Ekaterina Dimitrova >Assignee: shylaja kokoori >Priority: Normal > Fix For: 5.0.x, 5.x > > Time Spent: 3.5h > Remaining Estimate: 0h > > Currently, we limit our users from building with non-default Java versions in > build.xml. > They can easily hack build.xml for test purposes with different versions. > Cassandra–5.0 will be run on JDK11 and JDK17, but on startup, we do not limit > people to those two, but only to everything >= 11. We should also put an > upper limit of 17 in our Cassandra startup scripts. We can also add a flag to > opt-out if someone wants to test with newer versions. -- 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-18263) Update gc settings in build.xml
[ https://issues.apache.org/jira/browse/CASSANDRA-18263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17804332#comment-17804332 ] Ekaterina Dimitrova commented on CASSANDRA-18263: - +1 on the change from me too, thanks. > Update gc settings in build.xml > --- > > Key: CASSANDRA-18263 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18263 > Project: Cassandra > Issue Type: Task > Components: Local/Config >Reporter: Ekaterina Dimitrova >Assignee: Jacek Lewandowski >Priority: Normal > Fix For: 5.x > > > As part of CASSANDRA-18027 we switched trunk to default to G1GC. We need to > update also our test settings in build.xml to test with what we default to in > trunk > CC [~mck] -- 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-19252) After upgrading from 3.11.16 to 4.1.3 the CREATE MATERIALIZED VIEW generated by DESCRIBE KEYSPACE is invalid.
[
https://issues.apache.org/jira/browse/CASSANDRA-19252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-19252:
-
Bug Category: Parent values: Correctness(12982)Level 1 values: API /
Semantic Definition(13162)
Complexity: Normal
Discovered By: User Report
Fix Version/s: 4.1.x
5.0.x
5.x
Severity: Normal
Status: Open (was: Triage Needed)
> After upgrading from 3.11.16 to 4.1.3 the CREATE MATERIALIZED VIEW generated
> by DESCRIBE KEYSPACE is invalid.
> -
>
> Key: CASSANDRA-19252
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19252
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Materialized Views
>Reporter: Frank vissing
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
>
> After upgrading from 3.11.16 to 4.1.3 the CREATE MATERIALIZED VIEW generated
> by DESCRIBE KEYSPACE is invalid.
> Way back when In a 3.11.x cluster we did
> {code:java}
> CREATE TABLE myks.devices (
> id text,
> serial text,
> PRIMARY KEY (id)
> );
> CREATE MATERIALIZED VIEW myks.devices_by_serial AS
> SELECT *
> FROM myks.devices
> WHERE serial IS NOT NULL
> PRIMARY KEY (serial, id)
> WITH CLUSTERING ORDER BY (id ASC);{code}
>
> This was perfectley ok back then as KEY's was assumed NOT NULL
> so going trough various upgrades our last upgrade from 3.11.16 to 4.1.3 it is
> no longer possible to use the schema generated by DESCRIBE KEYSPACE myks as
> this outpts
>
> {code:java}
> CREATE MATERIALIZED VIEW myks.devices_by_serial AS
> SELECT *
> FROM myks.devices
> WHERE serial IS NOT NULL
> PRIMARY KEY (serial, id)
> WITH CLUSTERING ORDER BY (id ASC);{code}
> but this is no longer valid as it is missing 'AND id IS NOT NULL' to be valid
> cql. The expected output would be
> {code:java}
> CREATE MATERIALIZED VIEW myks.devices_by_serial AS
> SELECT *
> FROM myks.devices
> WHERE serial IS NOT NULL AND id IS NOT NULL
> PRIMARY KEY (serial, id)
> WITH CLUSTERING ORDER BY (id ASC);{code}
> There is obviousley no ALTER command that will fix this, but i would have
> expected the upgraded DESCRIBE to have made valid cql.
>
--
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-18824) Backport CASSANDRA-16418: Cleanup behaviour during node decommission caused missing replica
[ https://issues.apache.org/jira/browse/CASSANDRA-18824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17804342#comment-17804342 ] Szymon Miezal commented on CASSANDRA-18824: --- It seem the failure happened only on 3.11 branch which is suspicious. Can we run a batch of 1k executions again to verify whether that will persist? > Backport CASSANDRA-16418: Cleanup behaviour during node decommission caused > missing replica > --- > > Key: CASSANDRA-18824 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18824 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Bootstrap and Decommission >Reporter: Szymon Miezal >Assignee: Szymon Miezal >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.0.x, 5.x > > Time Spent: 1.5h > Remaining Estimate: 0h > > Node decommission triggers data transfer to other nodes. While this transfer > is in progress, > receiving nodes temporarily hold token ranges in a pending state. However, > the cleanup process currently doesn't consider these pending ranges when > calculating token ownership. > As a consequence, data that is already stored in sstables gets inadvertently > cleaned up. > STR: > * Create two node cluster > * Create keyspace with RF=1 > * Insert sample data (assert data is available when querying both nodes) > * Start decommission process of node 1 > * Start running cleanup in a loop on node 2 until decommission on node 1 > finishes > * Verify of all rows are in the cluster - it will fail as the previous step > removed some of the rows > It seems that the cleanup process does not take into account the pending > ranges, it uses only the local ranges - > [https://github.com/apache/cassandra/blob/caad2f24f95b494d05c6b5d86a8d25fbee58d7c2/src/java/org/apache/cassandra/db/compaction/CompactionManager.java#L466]. > There are two solutions to the problem. > One would be to change the cleanup process in a way that it start taking > pending ranges into account. Even thought it might sound tempting at first it > will require involving changes and a lot of testing effort. > Alternatively we could interrupt/prevent the cleanup process from running > when any pending range on a node is detected. That sounds like a reasonable > alternative to the problem and something that is relatively easy to implement. > The bug has been already fixed in 4.x with CASSANDRA-16418, the goal of this > ticket is to backport it to 3.x. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17135) Update docs for CASSANDRA-17132
[
https://issues.apache.org/jira/browse/CASSANDRA-17135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17804343#comment-17804343
]
Ekaterina Dimitrova commented on CASSANDRA-17135:
-
Happy New Year and thank you for looking into this ticket, [~polandll] !
These changes were done in 4.0.3 so the doc change should be in place for 4.0,
merged to 4.1, 5.0, and trunk branches.
{quote} _Inform the users about deprecation of
otc_backlog_expiration_interval_ms, otc_coalescing_strategy,
otc_coalescing_window_us_default, otc_coalescing_window_us,
otc_coalescing_enough_coalesced_messages._
{quote}
Some information that can help you:
[https://github.com/apache/cassandra/commit/537ad9e17b820e48df78a7edfe6b3a17d56e08bc]
The deprecation info is documented in NEWS.txt, but it would be nice to update
this in the rest of the docs where those properties are mentioned, too.
{quote}_internode_application_timeout_in_ms_
{quote}
This property was never added, so we need to remove any mention in the docs of
it.
{quote} * The names of _internode_send_buff_size_in_bytes_ and
_internode_recv_buff_size_in_bytes_ to be changed to
_internode_socket_send_buffer_size_in_bytes_ and
_internode_socket_recv_buffer_size_in_bytes_ everywhere in the docs
{quote}
Those two have new names; the old ones still can be used as there is backward
compatibility, but we need to update the docs to point only to the new names
and encourage people to use the new names.
> Update docs for CASSANDRA-17132
> ---
>
> Key: CASSANDRA-17135
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17135
> Project: Cassandra
> Issue Type: Bug
> Components: Documentation
>Reporter: Ekaterina Dimitrova
>Assignee: Erick Ramirez
>Priority: Normal
> Fix For: 4.0.x, 5.x
>
>
> Some cleaning of old parameters was done in CASSANDRA-17132.
> We need to update the docs respectively after the migration to ASCIIdoc is
> done:
> * -Remove any references to {_}otc_backlog_expiration_interval_ms,
> otc_coalescing_strategy, otc_coalescing_window_us_default{_},
> _otc_coalescing_window_us,_ _otc_coalescing_enough_coalesced_messages,
> internode_application_timeout_in_ms._- _Inform the users about deprecation
> of otc_backlog_expiration_interval_ms, otc_coalescing_strategy,
> otc_coalescing_window_us_default, otc_coalescing_window_us,
> otc_coalescing_enough_coalesced_messages._
> _internode_application_timeout_in_ms - this one never existed internally so I
> am not sure whether we need to add it now to Config.java... It was only a
> commented property in cassandra.yaml that never got into the release_
> * The names of _internode_send_buff_size_in_bytes_ and
> _internode_recv_buff_size_in_bytes_ to be changed to
> _internode_socket_send_buffer_size_in_bytes_ and
> _internode_socket_recv_buffer_size_in_bytes_ everywhere in the docs
--
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-19247) Minor corrections to TCM Implementation documentation
[
https://issues.apache.org/jira/browse/CASSANDRA-19247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sam Tunnicliffe updated CASSANDRA-19247:
Bug Category: Parent values: Documentation(13562)
Complexity: Low Hanging Fruit
Discovered By: User Report
Reviewers: Sam Tunnicliffe
Severity: Normal
Status: Open (was: Triage Needed)
> Minor corrections to TCM Implementation documentation
> -
>
> Key: CASSANDRA-19247
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19247
> Project: Cassandra
> Issue Type: Bug
> Components: Documentation, Transactional Cluster Metadata
>Reporter: n.v.harikrishna
>Assignee: n.v.harikrishna
>Priority: Normal
>
> In the "[Bootstrap: InProgressSequence, PrepareJoin,
> BootstrapAndJoin|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/tcm/TCM_implementation.md#bootstrap-inprogresssequence-preparejoin-bootstrapandjoin]”
> section of TCM Implementation doc, InProgressSequence transformations are
> mentioned as "{_}InProgressSequence`, holding the three transformations
> (`PrepareJoin`, `MinJoin` `FinishJoin`){_}”. As per
> [PrepareJoin|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/tcm/transformations/PrepareJoin.java#L154],
> these are {*}StartJoin{*}, Mi{*}d{*}Join & FinishJoin. Doc needs to be
> updated.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-18857) Allow CQL client certificate authentication to work without sending an AUTHENTICATE request
[
https://issues.apache.org/jira/browse/CASSANDRA-18857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy Tolbert reassigned CASSANDRA-18857:
Assignee: Andy Tolbert
> Allow CQL client certificate authentication to work without sending an
> AUTHENTICATE request
> ---
>
> Key: CASSANDRA-18857
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18857
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Encryption
>Reporter: Andy Tolbert
>Assignee: Andy Tolbert
>Priority: Normal
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Currently when using {{MutualTlsAuthenticator}} or
> {{MutualTlsWithPasswordFallbackAuthenticator}} a client is prompted with an
> {{AUTHENTICATE}} message to which they must respond with an {{AUTH_RESPONSE}}
> (e.g. a user name and password). This shouldn't be needed as the role can be
> identified using only the certificate.
> To address this, we could add the capability to authenticate early in
> processing of a {{STARTUP}} message if we can determine that both the
> configured authenticator supports certificate authentication and a client
> certificate was provided. If the certificate can be authenticated, a
> {{READY}} response is returned, otherwise an {{ERROR}} is returned.
> This change can be done done in a fully backwards compatible way and requires
> no protocol or driver changes; I will supply a patch shortly!
--
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-18857) Allow CQL client certificate authentication to work without sending an AUTHENTICATE request
[
https://issues.apache.org/jira/browse/CASSANDRA-18857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy Tolbert updated CASSANDRA-18857:
-
Change Category: Operability
Complexity: Normal
Status: Open (was: Triage Needed)
> Allow CQL client certificate authentication to work without sending an
> AUTHENTICATE request
> ---
>
> Key: CASSANDRA-18857
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18857
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Encryption
>Reporter: Andy Tolbert
>Assignee: Andy Tolbert
>Priority: Normal
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Currently when using {{MutualTlsAuthenticator}} or
> {{MutualTlsWithPasswordFallbackAuthenticator}} a client is prompted with an
> {{AUTHENTICATE}} message to which they must respond with an {{AUTH_RESPONSE}}
> (e.g. a user name and password). This shouldn't be needed as the role can be
> identified using only the certificate.
> To address this, we could add the capability to authenticate early in
> processing of a {{STARTUP}} message if we can determine that both the
> configured authenticator supports certificate authentication and a client
> certificate was provided. If the certificate can be authenticated, a
> {{READY}} response is returned, otherwise an {{ERROR}} is returned.
> This change can be done done in a fully backwards compatible way and requires
> no protocol or driver changes; I will supply a patch shortly!
--
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-18857) Allow CQL client certificate authentication to work without sending an AUTHENTICATE request
[
https://issues.apache.org/jira/browse/CASSANDRA-18857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy Tolbert updated CASSANDRA-18857:
-
Impacts: Security (was: None)
Test and Documentation Plan:
Test included in PR:
* {{AuthenticationTest}} tests existing code path that ensures {{AUTHENTICATE}}
request is sent in response to {{STARTUP}} with {{PasswordAuthenticator}}
* {{EarlyCertificateAuthenticationTest}} which validates authentication path
where certificate is provided (or not) with MutualTlsAuthenticator.
*
{{MutualTlsWithPasswordFallbackAuthenticatorEarlyCertificateAuthenticationTest}}
additionally validates authentication path where certificate is optionally
provided with credentials.
Status: Patch Available (was: Open)
Patch available at: https://github.com/apache/cassandra/pull/2969
> Allow CQL client certificate authentication to work without sending an
> AUTHENTICATE request
> ---
>
> Key: CASSANDRA-18857
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18857
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Encryption
>Reporter: Andy Tolbert
>Assignee: Andy Tolbert
>Priority: Normal
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Currently when using {{MutualTlsAuthenticator}} or
> {{MutualTlsWithPasswordFallbackAuthenticator}} a client is prompted with an
> {{AUTHENTICATE}} message to which they must respond with an {{AUTH_RESPONSE}}
> (e.g. a user name and password). This shouldn't be needed as the role can be
> identified using only the certificate.
> To address this, we could add the capability to authenticate early in
> processing of a {{STARTUP}} message if we can determine that both the
> configured authenticator supports certificate authentication and a client
> certificate was provided. If the certificate can be authenticated, a
> {{READY}} response is returned, otherwise an {{ERROR}} is returned.
> This change can be done done in a fully backwards compatible way and requires
> no protocol or driver changes; I will supply a patch shortly!
--
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-18491) Investigate the sizing of BlockPackedReader and MonotonicBlockPackedReader
[ https://issues.apache.org/jira/browse/CASSANDRA-18491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Rackliffe updated CASSANDRA-18491: Epic Link: CASSANDRA-19224 (was: CASSANDRA-18473) > Investigate the sizing of BlockPackedReader and MonotonicBlockPackedReader > -- > > Key: CASSANDRA-18491 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18491 > Project: Cassandra > Issue Type: Task > Components: Feature/2i Index >Reporter: Mike Adamson >Priority: Normal > > BlockPackedWriter uses a block size of 128 bytes and > MonotonicBlockPackedWriter uses a block size of 16384. > There is no documentation about the reasons for choosing these particular > sizes. > We should add a micro benchmark to test these classes with different block > sizes to show impact of changing them on read and write performance. -- 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-18857) Allow CQL client certificate authentication to work without sending an AUTHENTICATE request
[
https://issues.apache.org/jira/browse/CASSANDRA-18857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17804372#comment-17804372
]
Abe Ratnofsky commented on CASSANDRA-18857:
---
+1
> Allow CQL client certificate authentication to work without sending an
> AUTHENTICATE request
> ---
>
> Key: CASSANDRA-18857
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18857
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Encryption
>Reporter: Andy Tolbert
>Assignee: Andy Tolbert
>Priority: Normal
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Currently when using {{MutualTlsAuthenticator}} or
> {{MutualTlsWithPasswordFallbackAuthenticator}} a client is prompted with an
> {{AUTHENTICATE}} message to which they must respond with an {{AUTH_RESPONSE}}
> (e.g. a user name and password). This shouldn't be needed as the role can be
> identified using only the certificate.
> To address this, we could add the capability to authenticate early in
> processing of a {{STARTUP}} message if we can determine that both the
> configured authenticator supports certificate authentication and a client
> certificate was provided. If the certificate can be authenticated, a
> {{READY}} response is returned, otherwise an {{ERROR}} is returned.
> This change can be done done in a fully backwards compatible way and requires
> no protocol or driver changes; I will supply a patch shortly!
--
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-18714) Expand CQLSSTableWriter to write SSTable-attached secondary indexes
[
https://issues.apache.org/jira/browse/CASSANDRA-18714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-18714:
--
Test and Documentation Plan: CI
Status: Patch Available (was: In Progress)
> Expand CQLSSTableWriter to write SSTable-attached secondary indexes
> ---
>
> Key: CASSANDRA-18714
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18714
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/SAI, Tool/bulk load
>Reporter: Caleb Rackliffe
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{CQLSSTableWriter}} currently has no way of writing any secondary indexes
> inline as it writes the core SSTable components. With SAI, this has become
> tractable problem, and we should be able to enhance both it and
> {{SSTableImporter}} to handle cases where we might want to write SSTables
> somewhere in bulk (and in parallel) and then import them without waiting for
> index building on import. It would require the following changes:
> 1.) {{CQLSSTableWriter}} must accept 2i definitions on top of its current
> table schema definition. Once added to the schema, any {{ColumnFamilyStore}}
> instances opened will have those 2i defined in their index managers.
> 2.) All {{AbstractSSTableSimpleWriter}} instances must register index groups,
> allowing the proper {{SSTableFlushObservers}} to be attached to
> {{SSTableWriter}}. Once this is done, SAI (and any other SSTable-attached
> indexes) components will be built incrementally along w/ the SSTable data
> file, and will be finalized when the newly written SSTable is finalized.
> 3.) Provide an example (in a unit test?) of how a third-party tool might,
> assuming access to the right C* JAR, validate/checksum SAI components outside
> C* proper.
> 4.) {{SSTableImporter}} should have two new options:
> a.) an option that fails import if any SSTable-attached 2i must be built
> (i.e. has not already been built and brought along w/ the other new SSTable
> components)
> b.) an option that allows us to bypass full checksum validation on
> imported/already-built SSTable-attached indexes (assuming they have just been
> written by {{CQLSSTableWriter}})
--
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-19247) Minor corrections to TCM Implementation documentation
[
https://issues.apache.org/jira/browse/CASSANDRA-19247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
n.v.harikrishna updated CASSANDRA-19247:
Test and Documentation Plan: Minor documentation (with in GitHub) change.
Status: Patch Available (was: Open)
Patch available in [pr 3028|https://github.com/apache/cassandra/pull/3028].
> Minor corrections to TCM Implementation documentation
> -
>
> Key: CASSANDRA-19247
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19247
> Project: Cassandra
> Issue Type: Bug
> Components: Documentation, Transactional Cluster Metadata
>Reporter: n.v.harikrishna
>Assignee: n.v.harikrishna
>Priority: Normal
>
> In the "[Bootstrap: InProgressSequence, PrepareJoin,
> BootstrapAndJoin|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/tcm/TCM_implementation.md#bootstrap-inprogresssequence-preparejoin-bootstrapandjoin]”
> section of TCM Implementation doc, InProgressSequence transformations are
> mentioned as "{_}InProgressSequence`, holding the three transformations
> (`PrepareJoin`, `MinJoin` `FinishJoin`){_}”. As per
> [PrepareJoin|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/tcm/transformations/PrepareJoin.java#L154],
> these are {*}StartJoin{*}, Mi{*}d{*}Join & FinishJoin. Doc needs to be
> updated.
>
--
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-17812) Rate-limit new client connection setup to avoid overwhelming bcrypt
[ https://issues.apache.org/jira/browse/CASSANDRA-17812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17804390#comment-17804390 ] Josh McKenzie commented on CASSANDRA-17812: --- Since this is an improvement we only target unreleased versions with it; while this patch helps with stabilization in general it's also not a bugfix in and of itself. The code-changes for it aren't that extensive so creating a one-off patch to apply to 4.1 and doing a local release shouldn't be _too_ painful for you to do if that's something you desperately need. > Rate-limit new client connection setup to avoid overwhelming bcrypt > --- > > Key: CASSANDRA-17812 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17812 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Encryption >Reporter: Josh McKenzie >Assignee: Josh McKenzie >Priority: Normal > Fix For: 5.0-alpha1, 5.0 > > > A flood of reconnects can cause a ton of pain at the bcrypt phase of > validating incoming connections. While this shouldn't happen during normal > operations, we need a rate limit server side - if there's a bad client out > there (version and/or configuration) that misbehaves, a way to cap the pain > on a server is quite useful. Right now the only option is to cap the total > connections which has other issues that aren't an ideal tradeoff (inability > to connect, etc). > Moving authentication requests to a small, separate pool will prevent > starvation handling all other requests. If the authExecutor pool backs up it > may cause authentication timeouts, but the clients should back off and retry > while the rest of the system continues to make progress. -- 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-18824) Backport CASSANDRA-16418: Cleanup behaviour during node decommission caused missing replica
[ https://issues.apache.org/jira/browse/CASSANDRA-18824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17804392#comment-17804392 ] Brandon Williams commented on CASSANDRA-18824: -- Given that it failed an assertion and wasn't a timeout, I think it shows flakiness regardless of whether or not 1k iterations is enough to reproduce it, but since [it's not in 3.11|https://app.circleci.com/pipelines/github/driftx/cassandra/1456/workflows/40a5e77e-5637-4010-96bc-55fce00eec2f/jobs/71133] nor in [4.0|https://app.circleci.com/pipelines/github/driftx/cassandra/1455/workflows/3dadc395-5c98-4670-9647-324a845b96a5/jobs/71101], I guess if there's a problem we'll deal with it when we get there. > Backport CASSANDRA-16418: Cleanup behaviour during node decommission caused > missing replica > --- > > Key: CASSANDRA-18824 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18824 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Bootstrap and Decommission >Reporter: Szymon Miezal >Assignee: Szymon Miezal >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.0.x, 5.x > > Time Spent: 1.5h > Remaining Estimate: 0h > > Node decommission triggers data transfer to other nodes. While this transfer > is in progress, > receiving nodes temporarily hold token ranges in a pending state. However, > the cleanup process currently doesn't consider these pending ranges when > calculating token ownership. > As a consequence, data that is already stored in sstables gets inadvertently > cleaned up. > STR: > * Create two node cluster > * Create keyspace with RF=1 > * Insert sample data (assert data is available when querying both nodes) > * Start decommission process of node 1 > * Start running cleanup in a loop on node 2 until decommission on node 1 > finishes > * Verify of all rows are in the cluster - it will fail as the previous step > removed some of the rows > It seems that the cleanup process does not take into account the pending > ranges, it uses only the local ranges - > [https://github.com/apache/cassandra/blob/caad2f24f95b494d05c6b5d86a8d25fbee58d7c2/src/java/org/apache/cassandra/db/compaction/CompactionManager.java#L466]. > There are two solutions to the problem. > One would be to change the cleanup process in a way that it start taking > pending ranges into account. Even thought it might sound tempting at first it > will require involving changes and a lot of testing effort. > Alternatively we could interrupt/prevent the cleanup process from running > when any pending range on a node is detected. That sounds like a reasonable > alternative to the problem and something that is relatively easy to implement. > The bug has been already fixed in 4.x with CASSANDRA-16418, the goal of this > ticket is to backport it to 3.x. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18714) Expand CQLSSTableWriter to write SSTable-attached secondary indexes
[
https://issues.apache.org/jira/browse/CASSANDRA-18714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-18714:
Reviewers: Caleb Rackliffe
Status: Review In Progress (was: Patch Available)
> Expand CQLSSTableWriter to write SSTable-attached secondary indexes
> ---
>
> Key: CASSANDRA-18714
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18714
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/SAI, Tool/bulk load
>Reporter: Caleb Rackliffe
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{CQLSSTableWriter}} currently has no way of writing any secondary indexes
> inline as it writes the core SSTable components. With SAI, this has become
> tractable problem, and we should be able to enhance both it and
> {{SSTableImporter}} to handle cases where we might want to write SSTables
> somewhere in bulk (and in parallel) and then import them without waiting for
> index building on import. It would require the following changes:
> 1.) {{CQLSSTableWriter}} must accept 2i definitions on top of its current
> table schema definition. Once added to the schema, any {{ColumnFamilyStore}}
> instances opened will have those 2i defined in their index managers.
> 2.) All {{AbstractSSTableSimpleWriter}} instances must register index groups,
> allowing the proper {{SSTableFlushObservers}} to be attached to
> {{SSTableWriter}}. Once this is done, SAI (and any other SSTable-attached
> indexes) components will be built incrementally along w/ the SSTable data
> file, and will be finalized when the newly written SSTable is finalized.
> 3.) Provide an example (in a unit test?) of how a third-party tool might,
> assuming access to the right C* JAR, validate/checksum SAI components outside
> C* proper.
> 4.) {{SSTableImporter}} should have two new options:
> a.) an option that fails import if any SSTable-attached 2i must be built
> (i.e. has not already been built and brought along w/ the other new SSTable
> components)
> b.) an option that allows us to bypass full checksum validation on
> imported/already-built SSTable-attached indexes (assuming they have just been
> written by {{CQLSSTableWriter}})
--
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-18714) Expand CQLSSTableWriter to write SSTable-attached secondary indexes
[
https://issues.apache.org/jira/browse/CASSANDRA-18714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17804393#comment-17804393
]
Caleb Rackliffe commented on CASSANDRA-18714:
-
{quote}Why only SAI? It should be possible to build SASI indexes too.
{quote}
I'd be 100% fine if we don't support SASI or legacy 2i, at least in this patch.
The whole point of this SAI effort is to replace them.
> Expand CQLSSTableWriter to write SSTable-attached secondary indexes
> ---
>
> Key: CASSANDRA-18714
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18714
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/SAI, Tool/bulk load
>Reporter: Caleb Rackliffe
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{CQLSSTableWriter}} currently has no way of writing any secondary indexes
> inline as it writes the core SSTable components. With SAI, this has become
> tractable problem, and we should be able to enhance both it and
> {{SSTableImporter}} to handle cases where we might want to write SSTables
> somewhere in bulk (and in parallel) and then import them without waiting for
> index building on import. It would require the following changes:
> 1.) {{CQLSSTableWriter}} must accept 2i definitions on top of its current
> table schema definition. Once added to the schema, any {{ColumnFamilyStore}}
> instances opened will have those 2i defined in their index managers.
> 2.) All {{AbstractSSTableSimpleWriter}} instances must register index groups,
> allowing the proper {{SSTableFlushObservers}} to be attached to
> {{SSTableWriter}}. Once this is done, SAI (and any other SSTable-attached
> indexes) components will be built incrementally along w/ the SSTable data
> file, and will be finalized when the newly written SSTable is finalized.
> 3.) Provide an example (in a unit test?) of how a third-party tool might,
> assuming access to the right C* JAR, validate/checksum SAI components outside
> C* proper.
> 4.) {{SSTableImporter}} should have two new options:
> a.) an option that fails import if any SSTable-attached 2i must be built
> (i.e. has not already been built and brought along w/ the other new SSTable
> components)
> b.) an option that allows us to bypass full checksum validation on
> imported/already-built SSTable-attached indexes (assuming they have just been
> written by {{CQLSSTableWriter}})
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRASC-89) Consider updating guice to 5+
[
https://issues.apache.org/jira/browse/CASSANDRASC-89?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17804395#comment-17804395
]
Yifan Cai commented on CASSANDRASC-89:
--
+1 on the patch.
> Consider updating guice to 5+
> -
>
> Key: CASSANDRASC-89
> URL: https://issues.apache.org/jira/browse/CASSANDRASC-89
> Project: Sidecar for Apache Cassandra
> Issue Type: Task
> Components: Configuration
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Labels: pull-request-available
> Fix For: 1.0
>
>
> I am getting this when I run sidecar
> {code}
> WARNING: An illegal reflective access operation has occurred
> WARNING: Illegal reflective access by
> com.google.inject.internal.cglib.core.$ReflectUtils$1
> (file:/home/fermat/.gradle/caches/modules-2/files-2.1/com.google.inject/guice/4.2.2/6dacbe18e5eaa7f6c9c36db33b42e7985e94ce77/guice-4.2.2.jar)
> to method
> java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain)
> WARNING: Please consider reporting this to the maintainers of
> com.google.inject.internal.cglib.core.$ReflectUtils$1
> WARNING: Use --illegal-access=warn to enable warnings of further illegal
> reflective access operations
> WARNING: All illegal access operations will be denied in a future release
> {code}
> Sidecar is currently running guice of version 4.2.2. Mere bumping to guice
> 5.1.0 solves this and it goes away. I run integration tests as well as units
> and all seems to be passing just fine. I will need to double check though and
> run a formal build.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRASC-86) Startup Validation Failures when Checking Sidecar Connectivity
[ https://issues.apache.org/jira/browse/CASSANDRASC-86?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yifan Cai reassigned CASSANDRASC-86: Assignee: Yuriy Semchyshyn > Startup Validation Failures when Checking Sidecar Connectivity > -- > > Key: CASSANDRASC-86 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-86 > Project: Sidecar for Apache Cassandra > Issue Type: Improvement > Components: Configuration >Reporter: Yuriy Semchyshyn >Assignee: Yuriy Semchyshyn >Priority: Normal > Labels: pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > We have experienced repeated startup validation failures caused by Sidecar > health checks for some jobs with a large number of Spark executors. > These failures are likely caused by the thundering herd problem, and have > been so far worked around by disabling startup validations altogether. > In order to prevent them going forward, a random delay needs to be added > between retries of health checks in Sidecar client. > It is also worth increasing the overall timeout for Sidecar health checks > from current 30 seconds to 60 seconds. -- 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-18714) Expand CQLSSTableWriter to write SSTable-attached secondary indexes
[
https://issues.apache.org/jira/browse/CASSANDRA-18714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17804403#comment-17804403
]
Caleb Rackliffe commented on CASSANDRA-18714:
-
{quote}b.) an option that allows us to bypass full checksum validation on
imported/already-built SSTable-attached indexes (assuming they have just been
written by {{{}CQLSSTableWriter{}}})
{quote}
Take a look at {{SSTableImporter#importNewSSTables()}}:
{noformat}
// Validate existing SSTable-attached indexes, and then build any that are
missing:
if (!cfs.indexManager.validateSSTableAttachedIndexes(newSSTables, false))
cfs.indexManager.buildSSTableAttachedIndexesBlocking(newSSTables);
{noformat}
When we validate here, we're checksumming as well. There may be a case where we
want to just bypass that and, in SAI's case, do simple header/footer validation
instead. (The idea being that {{CQLSSTableWriter}} just wrote them.) It's not
exposed super cleanly as an option via
{{Group#validateSSTableAttachedIndexes()}}, but I think we could just add a
boolean for whether to checksum, and then have {{StorageAttachedIndexGroup}} 's
implementation of that call a modified version of
{{checksumPerSSTableComponents()}} that just forwards the boolean to the
{{IndexDescriptor}} method that actually does the validation.
> Expand CQLSSTableWriter to write SSTable-attached secondary indexes
> ---
>
> Key: CASSANDRA-18714
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18714
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/SAI, Tool/bulk load
>Reporter: Caleb Rackliffe
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{CQLSSTableWriter}} currently has no way of writing any secondary indexes
> inline as it writes the core SSTable components. With SAI, this has become
> tractable problem, and we should be able to enhance both it and
> {{SSTableImporter}} to handle cases where we might want to write SSTables
> somewhere in bulk (and in parallel) and then import them without waiting for
> index building on import. It would require the following changes:
> 1.) {{CQLSSTableWriter}} must accept 2i definitions on top of its current
> table schema definition. Once added to the schema, any {{ColumnFamilyStore}}
> instances opened will have those 2i defined in their index managers.
> 2.) All {{AbstractSSTableSimpleWriter}} instances must register index groups,
> allowing the proper {{SSTableFlushObservers}} to be attached to
> {{SSTableWriter}}. Once this is done, SAI (and any other SSTable-attached
> indexes) components will be built incrementally along w/ the SSTable data
> file, and will be finalized when the newly written SSTable is finalized.
> 3.) Provide an example (in a unit test?) of how a third-party tool might,
> assuming access to the right C* JAR, validate/checksum SAI components outside
> C* proper.
> 4.) {{SSTableImporter}} should have two new options:
> a.) an option that fails import if any SSTable-attached 2i must be built
> (i.e. has not already been built and brought along w/ the other new SSTable
> components)
> b.) an option that allows us to bypass full checksum validation on
> imported/already-built SSTable-attached indexes (assuming they have just been
> written by {{CQLSSTableWriter}})
--
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-18824) Backport CASSANDRA-16418: Cleanup behaviour during node decommission caused missing replica
[ https://issues.apache.org/jira/browse/CASSANDRA-18824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17804407#comment-17804407 ] Jacek Lewandowski commented on CASSANDRA-18824: --- [~brandon.williams] thank you for running the tests. I didn't run them, was waiting for feedback > Backport CASSANDRA-16418: Cleanup behaviour during node decommission caused > missing replica > --- > > Key: CASSANDRA-18824 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18824 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Bootstrap and Decommission >Reporter: Szymon Miezal >Assignee: Szymon Miezal >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.0.x, 5.x > > Time Spent: 1.5h > Remaining Estimate: 0h > > Node decommission triggers data transfer to other nodes. While this transfer > is in progress, > receiving nodes temporarily hold token ranges in a pending state. However, > the cleanup process currently doesn't consider these pending ranges when > calculating token ownership. > As a consequence, data that is already stored in sstables gets inadvertently > cleaned up. > STR: > * Create two node cluster > * Create keyspace with RF=1 > * Insert sample data (assert data is available when querying both nodes) > * Start decommission process of node 1 > * Start running cleanup in a loop on node 2 until decommission on node 1 > finishes > * Verify of all rows are in the cluster - it will fail as the previous step > removed some of the rows > It seems that the cleanup process does not take into account the pending > ranges, it uses only the local ranges - > [https://github.com/apache/cassandra/blob/caad2f24f95b494d05c6b5d86a8d25fbee58d7c2/src/java/org/apache/cassandra/db/compaction/CompactionManager.java#L466]. > There are two solutions to the problem. > One would be to change the cleanup process in a way that it start taking > pending ranges into account. Even thought it might sound tempting at first it > will require involving changes and a lot of testing effort. > Alternatively we could interrupt/prevent the cleanup process from running > when any pending range on a node is detected. That sounds like a reasonable > alternative to the problem and something that is relatively easy to implement. > The bug has been already fixed in 4.x with CASSANDRA-16418, the goal of this > ticket is to backport it to 3.x. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19016) CEP-15: (C*) per-table transactional configuration
[ https://issues.apache.org/jira/browse/CASSANDRA-19016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17804417#comment-17804417 ] Blake Eggleston commented on CASSANDRA-19016: - PR: [https://github.com/apache/cassandra/pull/3032] > CEP-15: (C*) per-table transactional configuration > -- > > Key: CASSANDRA-19016 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19016 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: Blake Eggleston >Assignee: Blake Eggleston >Priority: Normal > Fix For: 5.x > > > Accord configuration options should be rolled into as few options as > possible, with as few touch points as possible and, with support for > per-table configuration -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRASC-89) Consider updating guice to 5+
[
https://issues.apache.org/jira/browse/CASSANDRASC-89?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17804418#comment-17804418
]
Stefan Miklosovic commented on CASSANDRASC-89:
--
It doesnt work ... I should reflect the status of this ticket, sorry. Ask
[~frankgh] where the problem is.
> Consider updating guice to 5+
> -
>
> Key: CASSANDRASC-89
> URL: https://issues.apache.org/jira/browse/CASSANDRASC-89
> Project: Sidecar for Apache Cassandra
> Issue Type: Task
> Components: Configuration
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Labels: pull-request-available
> Fix For: 1.0
>
>
> I am getting this when I run sidecar
> {code}
> WARNING: An illegal reflective access operation has occurred
> WARNING: Illegal reflective access by
> com.google.inject.internal.cglib.core.$ReflectUtils$1
> (file:/home/fermat/.gradle/caches/modules-2/files-2.1/com.google.inject/guice/4.2.2/6dacbe18e5eaa7f6c9c36db33b42e7985e94ce77/guice-4.2.2.jar)
> to method
> java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain)
> WARNING: Please consider reporting this to the maintainers of
> com.google.inject.internal.cglib.core.$ReflectUtils$1
> WARNING: Use --illegal-access=warn to enable warnings of further illegal
> reflective access operations
> WARNING: All illegal access operations will be denied in a future release
> {code}
> Sidecar is currently running guice of version 4.2.2. Mere bumping to guice
> 5.1.0 solves this and it goes away. I run integration tests as well as units
> and all seems to be passing just fine. I will need to double check though and
> run a formal build.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRASC-89) Consider updating guice to 5+
[
https://issues.apache.org/jira/browse/CASSANDRASC-89?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRASC-89:
-
Status: Open (was: Patch Available)
> Consider updating guice to 5+
> -
>
> Key: CASSANDRASC-89
> URL: https://issues.apache.org/jira/browse/CASSANDRASC-89
> Project: Sidecar for Apache Cassandra
> Issue Type: Task
> Components: Configuration
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Labels: pull-request-available
> Fix For: 1.0
>
>
> I am getting this when I run sidecar
> {code}
> WARNING: An illegal reflective access operation has occurred
> WARNING: Illegal reflective access by
> com.google.inject.internal.cglib.core.$ReflectUtils$1
> (file:/home/fermat/.gradle/caches/modules-2/files-2.1/com.google.inject/guice/4.2.2/6dacbe18e5eaa7f6c9c36db33b42e7985e94ce77/guice-4.2.2.jar)
> to method
> java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain)
> WARNING: Please consider reporting this to the maintainers of
> com.google.inject.internal.cglib.core.$ReflectUtils$1
> WARNING: Use --illegal-access=warn to enable warnings of further illegal
> reflective access operations
> WARNING: All illegal access operations will be denied in a future release
> {code}
> Sidecar is currently running guice of version 4.2.2. Mere bumping to guice
> 5.1.0 solves this and it goes away. I run integration tests as well as units
> and all seems to be passing just fine. I will need to double check though and
> run a formal build.
--
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-19126) Streaming appears to be incompatible with different storage_compatibility_mode settings
[
https://issues.apache.org/jira/browse/CASSANDRA-19126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17804419#comment-17804419
]
Jacek Lewandowski commented on CASSANDRA-19126:
---
What is the conclusion here - is the PR acceptable as an immediate solution?
[~blambov], [~Bereng] ?
> Streaming appears to be incompatible with different
> storage_compatibility_mode settings
> ---
>
> Key: CASSANDRA-19126
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19126
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Streaming, Legacy/Streaming and Messaging,
> Messaging/Internode, Tool/bulk load
>Reporter: Branimir Lambov
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
>
> In particular, SSTableLoader appears to be incompatible with
> storage_compatibility_mode: NONE, which manifests as a failure of
> {{org.apache.cassandra.distributed.test.SSTableLoaderEncryptionOptionsTest}}
> when the flag is turned on (found during CASSANDRA-18753 testing). Setting
> {{storage_compatibility_mode: NONE}} in the tool configuration yaml does not
> help (according to the docs, this setting is not picked up).
> This is likely a bigger problem as the acceptable streaming version for C* 5
> is 12 only in legacy mode and 13 only in none, i.e. two C* 5 nodes do not
> appear to be able to stream with each other if their setting for the
> compatibility mode is different.
--
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-18714) Expand CQLSSTableWriter to write SSTable-attached secondary indexes
[
https://issues.apache.org/jira/browse/CASSANDRA-18714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17804450#comment-17804450
]
Stefan Miklosovic commented on CASSANDRA-18714:
---
OK. All done. I removed SASI support.
https://github.com/apache/cassandra/pull/3029/commits
> Expand CQLSSTableWriter to write SSTable-attached secondary indexes
> ---
>
> Key: CASSANDRA-18714
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18714
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/SAI, Tool/bulk load
>Reporter: Caleb Rackliffe
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{CQLSSTableWriter}} currently has no way of writing any secondary indexes
> inline as it writes the core SSTable components. With SAI, this has become
> tractable problem, and we should be able to enhance both it and
> {{SSTableImporter}} to handle cases where we might want to write SSTables
> somewhere in bulk (and in parallel) and then import them without waiting for
> index building on import. It would require the following changes:
> 1.) {{CQLSSTableWriter}} must accept 2i definitions on top of its current
> table schema definition. Once added to the schema, any {{ColumnFamilyStore}}
> instances opened will have those 2i defined in their index managers.
> 2.) All {{AbstractSSTableSimpleWriter}} instances must register index groups,
> allowing the proper {{SSTableFlushObservers}} to be attached to
> {{SSTableWriter}}. Once this is done, SAI (and any other SSTable-attached
> indexes) components will be built incrementally along w/ the SSTable data
> file, and will be finalized when the newly written SSTable is finalized.
> 3.) Provide an example (in a unit test?) of how a third-party tool might,
> assuming access to the right C* JAR, validate/checksum SAI components outside
> C* proper.
> 4.) {{SSTableImporter}} should have two new options:
> a.) an option that fails import if any SSTable-attached 2i must be built
> (i.e. has not already been built and brought along w/ the other new SSTable
> components)
> b.) an option that allows us to bypass full checksum validation on
> imported/already-built SSTable-attached indexes (assuming they have just been
> written by {{CQLSSTableWriter}})
--
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-17667) Text value containing "/*" interpreted as multiline comment in cqlsh
[
https://issues.apache.org/jira/browse/CASSANDRA-17667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-17667:
-
Fix Version/s: 5.0.x
> Text value containing "/*" interpreted as multiline comment in cqlsh
>
>
> Key: CASSANDRA-17667
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17667
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: ANOOP THOMAS
>Assignee: Brad Schoening
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x
>
>
> I use CQLSH command line utility to load some DDLs. The version of utility I
> use is this:
> {noformat}
> [cqlsh 6.0.0 | Cassandra 4.0.0.47 | CQL spec 3.4.5 | Native protocol
> v5]{noformat}
> Command that loads DDL.cql:
> {noformat}
> cqlsh -u username -p password cassandra.example.com 65503 --ssl -f DDL.cql
> {noformat}
> I have a line in CQL script that breaks the syntax.
> {noformat}
> INSERT into tablename (key,columnname1,columnname2) VALUES
> ('keyName','value1','/value2/*/value3');{noformat}
> {{/*}} here is interpreted as start of multi-line comment. It used to work on
> older versions of cqlsh. The error I see looks like this:
> {noformat}
> SyntaxException: line 4:2 mismatched input 'Update' expecting ')'
> (...,'value1','/value2INSERT into tablename(INSERT into tablename
> (key,columnname1,columnname2)) VALUES ('[Update]-...) SyntaxException: line
> 1:0 no viable alternative at input '(' ([(]...)
> {noformat}
> Same behavior while running in interactive mode too. {{/*}} inside a CQL
> statement should not be interpreted as start of multi-line comment.
> With schema:
> {code:java}
> CREATE TABLE tablename ( key text primary key, columnname1 text, columnname2
> text);{code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17667) Text value containing "/*" interpreted as multiline comment in cqlsh
[
https://issues.apache.org/jira/browse/CASSANDRA-17667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17804457#comment-17804457
]
Brandon Williams commented on CASSANDRA-17667:
--
Reminder that we are going to need PRs for all the branches where we intend to
fix this.
> Text value containing "/*" interpreted as multiline comment in cqlsh
>
>
> Key: CASSANDRA-17667
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17667
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: ANOOP THOMAS
>Assignee: Brad Schoening
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x
>
>
> I use CQLSH command line utility to load some DDLs. The version of utility I
> use is this:
> {noformat}
> [cqlsh 6.0.0 | Cassandra 4.0.0.47 | CQL spec 3.4.5 | Native protocol
> v5]{noformat}
> Command that loads DDL.cql:
> {noformat}
> cqlsh -u username -p password cassandra.example.com 65503 --ssl -f DDL.cql
> {noformat}
> I have a line in CQL script that breaks the syntax.
> {noformat}
> INSERT into tablename (key,columnname1,columnname2) VALUES
> ('keyName','value1','/value2/*/value3');{noformat}
> {{/*}} here is interpreted as start of multi-line comment. It used to work on
> older versions of cqlsh. The error I see looks like this:
> {noformat}
> SyntaxException: line 4:2 mismatched input 'Update' expecting ')'
> (...,'value1','/value2INSERT into tablename(INSERT into tablename
> (key,columnname1,columnname2)) VALUES ('[Update]-...) SyntaxException: line
> 1:0 no viable alternative at input '(' ([(]...)
> {noformat}
> Same behavior while running in interactive mode too. {{/*}} inside a CQL
> statement should not be interpreted as start of multi-line comment.
> With schema:
> {code:java}
> CREATE TABLE tablename ( key text primary key, columnname1 text, columnname2
> text);{code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18999) Gossiper::hasMajorVersion3Nodes returns true when a cluster is upgrading patch version without Cassandra 3 nodes.
[
https://issues.apache.org/jira/browse/CASSANDRA-18999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17804463#comment-17804463
]
Stefan Miklosovic commented on CASSANDRA-18999:
---
Yeah, baseline fails too. I think this was broken already.
> Gossiper::hasMajorVersion3Nodes returns true when a cluster is upgrading
> patch version without Cassandra 3 nodes.
> -
>
> Key: CASSANDRA-18999
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18999
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Distributed Metadata
>Reporter: Isaac Reath
>Assignee: Isaac Reath
>Priority: Low
> Labels: lhf
> Fix For: 4.0.x, 4.1.x, 5.0.x
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> When working on https://issues.apache.org/jira/browse/CASSANDRA-18968 we
> found that {{Gossiper::hasMajorVersion3Nodes}} will return true when the
> cluster is undergoing an upgrade from a patch version even if the cluster has
> no Cassandra 3 nodes in it.
> This can be reproduced by running this Gossiper test:
> {code:java}
> @Test
> public void
> testHasVersion3NodesShouldReturnFalseWhenNoVersion3NodesDetectedAndCassandra4UpgradeInProgress()
> throws Exception
> {
> Gossiper.instance.start(0);
> Gossiper.instance.expireUpgradeFromVersion();
> VersionedValue.VersionedValueFactory factory = new
> VersionedValue.VersionedValueFactory(null);
> EndpointState es = new EndpointState((HeartBeatState) null);
> es.addApplicationState(ApplicationState.RELEASE_VERSION,
> factory.releaseVersion(CURRENT_VERSION.toString()));
>
> Gossiper.instance.endpointStateMap.put(InetAddressAndPort.getByName("127.0.0.1"),
> es);
>
> Gossiper.instance.liveEndpoints.add(InetAddressAndPort.getByName("127.0.0.1"));
> es = new EndpointState((HeartBeatState) null);
> String previousPatchVersion = String.valueOf(CURRENT_VERSION.major) +
> '.' + (CURRENT_VERSION.minor) + '.' + (CURRENT_VERSION.patch - 1);
> es.addApplicationState(ApplicationState.RELEASE_VERSION,
> factory.releaseVersion(previousPatchVersion));
>
> Gossiper.instance.endpointStateMap.put(InetAddressAndPort.getByName("127.0.0.2"),
> es);
>
> Gossiper.instance.liveEndpoints.add(InetAddressAndPort.getByName("127.0.0.2"));
> assertFalse(Gossiper.instance.hasMajorVersion3Nodes());
> }
> {code}
> This seems to be because of
> [https://github.com/apache/cassandra/blob/cassandra-4.1/src/java/org/apache/cassandra/gms/Gossiper.java#L2360],
> where an upgrade in progress is possible but we are not upgrading from a
> lower family version (i.e from 4.1.1 to 4.1.2).
> From the comment in this function, it seems instead of the existing check, we
> would want to iterate over all known endpoints in gossip and return true if
> any of them do not have a version (similar to
> [https://github.com/apache/cassandra/blob/cassandra-4.1/src/java/org/apache/cassandra/gms/Gossiper.java#L227-L236)
>
> |https://github.com/apache/cassandra/blob/cassandra-4.1/src/java/org/apache/cassandra/gms/Gossiper.java#L227-L236).]
--
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-19107) Revert unnecessary read lock acquisition when reading ring version in TokenMetadata introduced in CASSANDRA-16286
[
https://issues.apache.org/jira/browse/CASSANDRA-19107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-19107:
Fix Version/s: (was: 5.x)
> Revert unnecessary read lock acquisition when reading ring version in
> TokenMetadata introduced in CASSANDRA-16286
> -
>
> Key: CASSANDRA-19107
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19107
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Distributed Metadata
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0.x
>
>
> CASSANDRA-16286 achieved its goal of making sure that concurrent increments
> to the ring version would independently increment the version (i.e. not
> "merge" multiple invalidations into single versions), but it also
> unnecessarily replaced the volatile read on {{ringVersion}} w/ making
> {{readVersion}} non-volatile and acquiring the read lock on the fair
> {{ReadWriteLock}} in {{TokenMetadata}}. This can result in unnecessary
> queueing w/ high CPU usage/read volume. For example, you might see this on a
> 4.0 cluster...
> {noformat}
> "Native-Transport-Requests-99" #271 daemon prio=5 os_prio=0 cpu=5822566.56ms
> elapsed=1949.40s tid=0x7fcc96c31b00 nid=0xb7bd waiting on condition
> [0x7fcb7f144000]
> java.lang.Thread.State: WAITING (parking)
>at jdk.internal.misc.Unsafe.park(java.base@11.0.16/Native Method)
>- parking to wait for <0x0005c0ab92a0> (a
> java.util.concurrent.locks.ReentrantReadWriteLock$FairSync)
>at
> java.util.concurrent.locks.LockSupport.park(java.base@11.0.16/LockSupport.java:194)
>at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(java.base@11.0.16/AbstractQueuedSynchronizer.java:885)
>at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireShared(java.base@11.0.16/AbstractQueuedSynchronizer.java:1009)
>at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireShared(java.base@11.0.16/AbstractQueuedSynchronizer.java:1324)
>at
> java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.lock(java.base@11.0.16/ReentrantReadWriteLock.java:738)
>at
> org.apache.cassandra.locator.TokenMetadata.getRingVersion(TokenMetadata.java:1389)
>at
> org.apache.cassandra.locator.AbstractReplicationStrategy.getCachedReplicas(AbstractReplicationStrategy.java:82)
>at
> org.apache.cassandra.locator.AbstractReplicationStrategy.getNaturalReplicas(AbstractReplicationStrategy.java:116)
>at
> org.apache.cassandra.locator.AbstractReplicationStrategy.getNaturalReplicasForToken(AbstractReplicationStrategy.java:109)
>at
> org.apache.cassandra.locator.ReplicaLayout.forTokenWriteLiveAndDown(ReplicaLayout.java:209)
>at
> org.apache.cassandra.locator.ReplicaPlans.forWrite(ReplicaPlans.java:328)
>at
> org.apache.cassandra.service.StorageProxy.performWrite(StorageProxy.java:1426)
>at
> org.apache.cassandra.service.StorageProxy.mutate(StorageProxy.java:937)
> {noformat}
> Reverting to a volatile read makes this no longer possible, but keeps the fix
> from CASSANDRA-16286 intact.
--
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-19107) Revert unnecessary read lock acquisition when reading ring version in TokenMetadata introduced in CASSANDRA-16286
[
https://issues.apache.org/jira/browse/CASSANDRA-19107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17804465#comment-17804465
]
Caleb Rackliffe commented on CASSANDRA-19107:
-
TCM makes this irrelevant in 5.x/5.1
> Revert unnecessary read lock acquisition when reading ring version in
> TokenMetadata introduced in CASSANDRA-16286
> -
>
> Key: CASSANDRA-19107
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19107
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Distributed Metadata
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0.x
>
>
> CASSANDRA-16286 achieved its goal of making sure that concurrent increments
> to the ring version would independently increment the version (i.e. not
> "merge" multiple invalidations into single versions), but it also
> unnecessarily replaced the volatile read on {{ringVersion}} w/ making
> {{readVersion}} non-volatile and acquiring the read lock on the fair
> {{ReadWriteLock}} in {{TokenMetadata}}. This can result in unnecessary
> queueing w/ high CPU usage/read volume. For example, you might see this on a
> 4.0 cluster...
> {noformat}
> "Native-Transport-Requests-99" #271 daemon prio=5 os_prio=0 cpu=5822566.56ms
> elapsed=1949.40s tid=0x7fcc96c31b00 nid=0xb7bd waiting on condition
> [0x7fcb7f144000]
> java.lang.Thread.State: WAITING (parking)
>at jdk.internal.misc.Unsafe.park(java.base@11.0.16/Native Method)
>- parking to wait for <0x0005c0ab92a0> (a
> java.util.concurrent.locks.ReentrantReadWriteLock$FairSync)
>at
> java.util.concurrent.locks.LockSupport.park(java.base@11.0.16/LockSupport.java:194)
>at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(java.base@11.0.16/AbstractQueuedSynchronizer.java:885)
>at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireShared(java.base@11.0.16/AbstractQueuedSynchronizer.java:1009)
>at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireShared(java.base@11.0.16/AbstractQueuedSynchronizer.java:1324)
>at
> java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.lock(java.base@11.0.16/ReentrantReadWriteLock.java:738)
>at
> org.apache.cassandra.locator.TokenMetadata.getRingVersion(TokenMetadata.java:1389)
>at
> org.apache.cassandra.locator.AbstractReplicationStrategy.getCachedReplicas(AbstractReplicationStrategy.java:82)
>at
> org.apache.cassandra.locator.AbstractReplicationStrategy.getNaturalReplicas(AbstractReplicationStrategy.java:116)
>at
> org.apache.cassandra.locator.AbstractReplicationStrategy.getNaturalReplicasForToken(AbstractReplicationStrategy.java:109)
>at
> org.apache.cassandra.locator.ReplicaLayout.forTokenWriteLiveAndDown(ReplicaLayout.java:209)
>at
> org.apache.cassandra.locator.ReplicaPlans.forWrite(ReplicaPlans.java:328)
>at
> org.apache.cassandra.service.StorageProxy.performWrite(StorageProxy.java:1426)
>at
> org.apache.cassandra.service.StorageProxy.mutate(StorageProxy.java:937)
> {noformat}
> Reverting to a volatile read makes this no longer possible, but keeps the fix
> from CASSANDRA-16286 intact.
--
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-19107) Revert unnecessary read lock acquisition when reading ring version in TokenMetadata introduced in CASSANDRA-16286
[
https://issues.apache.org/jira/browse/CASSANDRA-19107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-19107:
Fix Version/s: 5.0-rc
(was: 5.0.x)
> Revert unnecessary read lock acquisition when reading ring version in
> TokenMetadata introduced in CASSANDRA-16286
> -
>
> Key: CASSANDRA-19107
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19107
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Distributed Metadata
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0-rc
>
>
> CASSANDRA-16286 achieved its goal of making sure that concurrent increments
> to the ring version would independently increment the version (i.e. not
> "merge" multiple invalidations into single versions), but it also
> unnecessarily replaced the volatile read on {{ringVersion}} w/ making
> {{readVersion}} non-volatile and acquiring the read lock on the fair
> {{ReadWriteLock}} in {{TokenMetadata}}. This can result in unnecessary
> queueing w/ high CPU usage/read volume. For example, you might see this on a
> 4.0 cluster...
> {noformat}
> "Native-Transport-Requests-99" #271 daemon prio=5 os_prio=0 cpu=5822566.56ms
> elapsed=1949.40s tid=0x7fcc96c31b00 nid=0xb7bd waiting on condition
> [0x7fcb7f144000]
> java.lang.Thread.State: WAITING (parking)
>at jdk.internal.misc.Unsafe.park(java.base@11.0.16/Native Method)
>- parking to wait for <0x0005c0ab92a0> (a
> java.util.concurrent.locks.ReentrantReadWriteLock$FairSync)
>at
> java.util.concurrent.locks.LockSupport.park(java.base@11.0.16/LockSupport.java:194)
>at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(java.base@11.0.16/AbstractQueuedSynchronizer.java:885)
>at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireShared(java.base@11.0.16/AbstractQueuedSynchronizer.java:1009)
>at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireShared(java.base@11.0.16/AbstractQueuedSynchronizer.java:1324)
>at
> java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.lock(java.base@11.0.16/ReentrantReadWriteLock.java:738)
>at
> org.apache.cassandra.locator.TokenMetadata.getRingVersion(TokenMetadata.java:1389)
>at
> org.apache.cassandra.locator.AbstractReplicationStrategy.getCachedReplicas(AbstractReplicationStrategy.java:82)
>at
> org.apache.cassandra.locator.AbstractReplicationStrategy.getNaturalReplicas(AbstractReplicationStrategy.java:116)
>at
> org.apache.cassandra.locator.AbstractReplicationStrategy.getNaturalReplicasForToken(AbstractReplicationStrategy.java:109)
>at
> org.apache.cassandra.locator.ReplicaLayout.forTokenWriteLiveAndDown(ReplicaLayout.java:209)
>at
> org.apache.cassandra.locator.ReplicaPlans.forWrite(ReplicaPlans.java:328)
>at
> org.apache.cassandra.service.StorageProxy.performWrite(StorageProxy.java:1426)
>at
> org.apache.cassandra.service.StorageProxy.mutate(StorageProxy.java:937)
> {noformat}
> Reverting to a volatile read makes this no longer possible, but keeps the fix
> from CASSANDRA-16286 intact.
--
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-19107) Revert unnecessary read lock acquisition when reading ring version in TokenMetadata introduced in CASSANDRA-16286
[
https://issues.apache.org/jira/browse/CASSANDRA-19107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-19107:
Reviewers: Francisco Guerrero
> Revert unnecessary read lock acquisition when reading ring version in
> TokenMetadata introduced in CASSANDRA-16286
> -
>
> Key: CASSANDRA-19107
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19107
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Distributed Metadata
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0-rc
>
>
> CASSANDRA-16286 achieved its goal of making sure that concurrent increments
> to the ring version would independently increment the version (i.e. not
> "merge" multiple invalidations into single versions), but it also
> unnecessarily replaced the volatile read on {{ringVersion}} w/ making
> {{readVersion}} non-volatile and acquiring the read lock on the fair
> {{ReadWriteLock}} in {{TokenMetadata}}. This can result in unnecessary
> queueing w/ high CPU usage/read volume. For example, you might see this on a
> 4.0 cluster...
> {noformat}
> "Native-Transport-Requests-99" #271 daemon prio=5 os_prio=0 cpu=5822566.56ms
> elapsed=1949.40s tid=0x7fcc96c31b00 nid=0xb7bd waiting on condition
> [0x7fcb7f144000]
> java.lang.Thread.State: WAITING (parking)
>at jdk.internal.misc.Unsafe.park(java.base@11.0.16/Native Method)
>- parking to wait for <0x0005c0ab92a0> (a
> java.util.concurrent.locks.ReentrantReadWriteLock$FairSync)
>at
> java.util.concurrent.locks.LockSupport.park(java.base@11.0.16/LockSupport.java:194)
>at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(java.base@11.0.16/AbstractQueuedSynchronizer.java:885)
>at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireShared(java.base@11.0.16/AbstractQueuedSynchronizer.java:1009)
>at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireShared(java.base@11.0.16/AbstractQueuedSynchronizer.java:1324)
>at
> java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.lock(java.base@11.0.16/ReentrantReadWriteLock.java:738)
>at
> org.apache.cassandra.locator.TokenMetadata.getRingVersion(TokenMetadata.java:1389)
>at
> org.apache.cassandra.locator.AbstractReplicationStrategy.getCachedReplicas(AbstractReplicationStrategy.java:82)
>at
> org.apache.cassandra.locator.AbstractReplicationStrategy.getNaturalReplicas(AbstractReplicationStrategy.java:116)
>at
> org.apache.cassandra.locator.AbstractReplicationStrategy.getNaturalReplicasForToken(AbstractReplicationStrategy.java:109)
>at
> org.apache.cassandra.locator.ReplicaLayout.forTokenWriteLiveAndDown(ReplicaLayout.java:209)
>at
> org.apache.cassandra.locator.ReplicaPlans.forWrite(ReplicaPlans.java:328)
>at
> org.apache.cassandra.service.StorageProxy.performWrite(StorageProxy.java:1426)
>at
> org.apache.cassandra.service.StorageProxy.mutate(StorageProxy.java:937)
> {noformat}
> Reverting to a volatile read makes this no longer possible, but keeps the fix
> from CASSANDRA-16286 intact.
--
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-19107) Revert unnecessary read lock acquisition when reading ring version in TokenMetadata introduced in CASSANDRA-16286
[
https://issues.apache.org/jira/browse/CASSANDRA-19107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-19107:
Test and Documentation Plan: Existing tests in TokenMetadataTest should
backstop this well enough
Status: Patch Available (was: In Progress)
4.0 patch: [https://github.com/apache/cassandra/pull/3034]
(Will post tests shortly. This is a 3-4 line patch, and should port cleanly to
4.1 and 5.0)
> Revert unnecessary read lock acquisition when reading ring version in
> TokenMetadata introduced in CASSANDRA-16286
> -
>
> Key: CASSANDRA-19107
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19107
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Distributed Metadata
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0-rc
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> CASSANDRA-16286 achieved its goal of making sure that concurrent increments
> to the ring version would independently increment the version (i.e. not
> "merge" multiple invalidations into single versions), but it also
> unnecessarily replaced the volatile read on {{ringVersion}} w/ making
> {{readVersion}} non-volatile and acquiring the read lock on the fair
> {{ReadWriteLock}} in {{TokenMetadata}}. This can result in unnecessary
> queueing w/ high CPU usage/read volume. For example, you might see this on a
> 4.0 cluster...
> {noformat}
> "Native-Transport-Requests-99" #271 daemon prio=5 os_prio=0 cpu=5822566.56ms
> elapsed=1949.40s tid=0x7fcc96c31b00 nid=0xb7bd waiting on condition
> [0x7fcb7f144000]
> java.lang.Thread.State: WAITING (parking)
>at jdk.internal.misc.Unsafe.park(java.base@11.0.16/Native Method)
>- parking to wait for <0x0005c0ab92a0> (a
> java.util.concurrent.locks.ReentrantReadWriteLock$FairSync)
>at
> java.util.concurrent.locks.LockSupport.park(java.base@11.0.16/LockSupport.java:194)
>at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(java.base@11.0.16/AbstractQueuedSynchronizer.java:885)
>at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireShared(java.base@11.0.16/AbstractQueuedSynchronizer.java:1009)
>at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireShared(java.base@11.0.16/AbstractQueuedSynchronizer.java:1324)
>at
> java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.lock(java.base@11.0.16/ReentrantReadWriteLock.java:738)
>at
> org.apache.cassandra.locator.TokenMetadata.getRingVersion(TokenMetadata.java:1389)
>at
> org.apache.cassandra.locator.AbstractReplicationStrategy.getCachedReplicas(AbstractReplicationStrategy.java:82)
>at
> org.apache.cassandra.locator.AbstractReplicationStrategy.getNaturalReplicas(AbstractReplicationStrategy.java:116)
>at
> org.apache.cassandra.locator.AbstractReplicationStrategy.getNaturalReplicasForToken(AbstractReplicationStrategy.java:109)
>at
> org.apache.cassandra.locator.ReplicaLayout.forTokenWriteLiveAndDown(ReplicaLayout.java:209)
>at
> org.apache.cassandra.locator.ReplicaPlans.forWrite(ReplicaPlans.java:328)
>at
> org.apache.cassandra.service.StorageProxy.performWrite(StorageProxy.java:1426)
>at
> org.apache.cassandra.service.StorageProxy.mutate(StorageProxy.java:937)
> {noformat}
> Reverting to a volatile read makes this no longer possible, but keeps the fix
> from CASSANDRA-16286 intact.
--
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-19107) Revert unnecessary read lock acquisition when reading ring version in TokenMetadata introduced in CASSANDRA-16286
[
https://issues.apache.org/jira/browse/CASSANDRA-19107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francisco Guerrero updated CASSANDRA-19107:
---
Status: Review In Progress (was: Patch Available)
> Revert unnecessary read lock acquisition when reading ring version in
> TokenMetadata introduced in CASSANDRA-16286
> -
>
> Key: CASSANDRA-19107
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19107
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Distributed Metadata
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0-rc
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> CASSANDRA-16286 achieved its goal of making sure that concurrent increments
> to the ring version would independently increment the version (i.e. not
> "merge" multiple invalidations into single versions), but it also
> unnecessarily replaced the volatile read on {{ringVersion}} w/ making
> {{readVersion}} non-volatile and acquiring the read lock on the fair
> {{ReadWriteLock}} in {{TokenMetadata}}. This can result in unnecessary
> queueing w/ high CPU usage/read volume. For example, you might see this on a
> 4.0 cluster...
> {noformat}
> "Native-Transport-Requests-99" #271 daemon prio=5 os_prio=0 cpu=5822566.56ms
> elapsed=1949.40s tid=0x7fcc96c31b00 nid=0xb7bd waiting on condition
> [0x7fcb7f144000]
> java.lang.Thread.State: WAITING (parking)
>at jdk.internal.misc.Unsafe.park(java.base@11.0.16/Native Method)
>- parking to wait for <0x0005c0ab92a0> (a
> java.util.concurrent.locks.ReentrantReadWriteLock$FairSync)
>at
> java.util.concurrent.locks.LockSupport.park(java.base@11.0.16/LockSupport.java:194)
>at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(java.base@11.0.16/AbstractQueuedSynchronizer.java:885)
>at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireShared(java.base@11.0.16/AbstractQueuedSynchronizer.java:1009)
>at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireShared(java.base@11.0.16/AbstractQueuedSynchronizer.java:1324)
>at
> java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.lock(java.base@11.0.16/ReentrantReadWriteLock.java:738)
>at
> org.apache.cassandra.locator.TokenMetadata.getRingVersion(TokenMetadata.java:1389)
>at
> org.apache.cassandra.locator.AbstractReplicationStrategy.getCachedReplicas(AbstractReplicationStrategy.java:82)
>at
> org.apache.cassandra.locator.AbstractReplicationStrategy.getNaturalReplicas(AbstractReplicationStrategy.java:116)
>at
> org.apache.cassandra.locator.AbstractReplicationStrategy.getNaturalReplicasForToken(AbstractReplicationStrategy.java:109)
>at
> org.apache.cassandra.locator.ReplicaLayout.forTokenWriteLiveAndDown(ReplicaLayout.java:209)
>at
> org.apache.cassandra.locator.ReplicaPlans.forWrite(ReplicaPlans.java:328)
>at
> org.apache.cassandra.service.StorageProxy.performWrite(StorageProxy.java:1426)
>at
> org.apache.cassandra.service.StorageProxy.mutate(StorageProxy.java:937)
> {noformat}
> Reverting to a volatile read makes this no longer possible, but keeps the fix
> from CASSANDRA-16286 intact.
--
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-19107) Revert unnecessary read lock acquisition when reading ring version in TokenMetadata introduced in CASSANDRA-16286
[
https://issues.apache.org/jira/browse/CASSANDRA-19107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17804471#comment-17804471
]
Francisco Guerrero commented on CASSANDRA-19107:
+1 Thanks for the patch
> Revert unnecessary read lock acquisition when reading ring version in
> TokenMetadata introduced in CASSANDRA-16286
> -
>
> Key: CASSANDRA-19107
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19107
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Distributed Metadata
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0-rc
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> CASSANDRA-16286 achieved its goal of making sure that concurrent increments
> to the ring version would independently increment the version (i.e. not
> "merge" multiple invalidations into single versions), but it also
> unnecessarily replaced the volatile read on {{ringVersion}} w/ making
> {{readVersion}} non-volatile and acquiring the read lock on the fair
> {{ReadWriteLock}} in {{TokenMetadata}}. This can result in unnecessary
> queueing w/ high CPU usage/read volume. For example, you might see this on a
> 4.0 cluster...
> {noformat}
> "Native-Transport-Requests-99" #271 daemon prio=5 os_prio=0 cpu=5822566.56ms
> elapsed=1949.40s tid=0x7fcc96c31b00 nid=0xb7bd waiting on condition
> [0x7fcb7f144000]
> java.lang.Thread.State: WAITING (parking)
>at jdk.internal.misc.Unsafe.park(java.base@11.0.16/Native Method)
>- parking to wait for <0x0005c0ab92a0> (a
> java.util.concurrent.locks.ReentrantReadWriteLock$FairSync)
>at
> java.util.concurrent.locks.LockSupport.park(java.base@11.0.16/LockSupport.java:194)
>at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(java.base@11.0.16/AbstractQueuedSynchronizer.java:885)
>at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireShared(java.base@11.0.16/AbstractQueuedSynchronizer.java:1009)
>at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireShared(java.base@11.0.16/AbstractQueuedSynchronizer.java:1324)
>at
> java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.lock(java.base@11.0.16/ReentrantReadWriteLock.java:738)
>at
> org.apache.cassandra.locator.TokenMetadata.getRingVersion(TokenMetadata.java:1389)
>at
> org.apache.cassandra.locator.AbstractReplicationStrategy.getCachedReplicas(AbstractReplicationStrategy.java:82)
>at
> org.apache.cassandra.locator.AbstractReplicationStrategy.getNaturalReplicas(AbstractReplicationStrategy.java:116)
>at
> org.apache.cassandra.locator.AbstractReplicationStrategy.getNaturalReplicasForToken(AbstractReplicationStrategy.java:109)
>at
> org.apache.cassandra.locator.ReplicaLayout.forTokenWriteLiveAndDown(ReplicaLayout.java:209)
>at
> org.apache.cassandra.locator.ReplicaPlans.forWrite(ReplicaPlans.java:328)
>at
> org.apache.cassandra.service.StorageProxy.performWrite(StorageProxy.java:1426)
>at
> org.apache.cassandra.service.StorageProxy.mutate(StorageProxy.java:937)
> {noformat}
> Reverting to a volatile read makes this no longer possible, but keeps the fix
> from CASSANDRA-16286 intact.
--
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-19001) Check whether the startup warnings for unknown modules represent a legit problem or cosmetic issue
[
https://issues.apache.org/jira/browse/CASSANDRA-19001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17804491#comment-17804491
]
Ekaterina Dimitrova commented on CASSANDRA-19001:
-
Thank you, [~paulo] for the extensive review and the patches! I truly
appreciate it!
Please find my responses below:
{quote}JRE is on {{/opt/java/openjdk/bin/java}}
{quote}
LGTM, sorry I forgot about that earlier.
{quote} I updated the check [on this
commit|https://github.com/pauloricardomg/cassandra/commit/97472afcc4f63291ebbbcc6aab476b0ccf12ce06]
to check for the presence of the {{javac}} executable on the {{$PATH}} or
{{$JAVA_HOME}} to detect whether a JDK is present. Let me know what do you
think.
{quote}
I was using the runtime check, not the javac command check, because you can
have a few different installations on a machine, and while you try to use JRE,
the check for javac still passes as you also have jdk11 for example, on the
same machine
{quote}Added [this
commit|https://github.com/pauloricardomg/cassandra/commit/cdc4124873f2b29c4d42e3265a9c7f408bcd98c4]
to
[pauloricardomg/19001-5.0-patch|https://github.com/apache/cassandra/compare/trunk...pauloricardomg:cassandra:19001-5.0-patch]
to fail "nodetool sjk" with a nicer message when a JDK is not found:
{quote}
I get below on my machine with that patch and JRE, just local build running on
my laptop (I would have to clear from my path the jdk11 for the check to pass
as expected):
{code:java}
bin/nodetool sjk jps
WARNING: Unknown module: jdk.compiler specified to --add-exports
WARNING: Unknown module: jdk.attach specified to --add-exports
WARNING: Unknown module: jdk.compiler specified to --add-opens
ERROR 14:04:02,644 Java home points to
/Library/Java/JavaVirtualMachines/temurin-17.jre/Contents/Home make sure it is
not a JRE path
ERROR 14:04:02,645 Failed to add tools.jar to classpath
java.lang.ClassNotFoundException: com.sun.tools.attach.VirtualMachine
at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(Unknown Source)
at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(Unknown
Source)
at java.base/java.lang.ClassLoader.loadClass(Unknown Source)
at org.gridkit.lab.jvm.attach.AttachAPI.(AttachAPI.java:52)
at org.gridkit.lab.jvm.attach.AttachManager.(AttachManager.java:75)
at org.gridkit.jvmtool.cmd.ProcListCmd$JPS.run(ProcListCmd.java:74)
at org.apache.cassandra.tools.nodetool.Sjk$Wrapper.run(Sjk.java:219)
at org.apache.cassandra.tools.nodetool.Sjk.runInternal(Sjk.java:83)
at org.apache.cassandra.tools.NodeTool$NodeToolCmd.run(NodeTool.java:368)
at org.apache.cassandra.tools.NodeTool.execute(NodeTool.java:267)
at org.apache.cassandra.tools.NodeTool.main(NodeTool.java:85)
java.lang.NoClassDefFoundError: com/sun/tools/attach/VirtualMachine
at
org.gridkit.lab.jvm.attach.AttachManager$AttachManagerInt.getVmList(AttachManager.java:217)
at
org.gridkit.lab.jvm.attach.AttachManager$AttachManagerInt.internalListJavaProcesses(AttachManager.java:224)
at
org.gridkit.lab.jvm.attach.AttachManager.listJavaProcesses(AttachManager.java:105)
at org.gridkit.jvmtool.cmd.ProcListCmd$JPS.run(ProcListCmd.java:74)
at org.apache.cassandra.tools.nodetool.Sjk$Wrapper.run(Sjk.java:219)
at org.apache.cassandra.tools.nodetool.Sjk.runInternal(Sjk.java:83)
at org.apache.cassandra.tools.NodeTool$NodeToolCmd.run(NodeTool.java:368)
at org.apache.cassandra.tools.NodeTool.execute(NodeTool.java:267)
at org.apache.cassandra.tools.NodeTool.main(NodeTool.java:85)
Caused by: java.lang.ClassNotFoundException: com.sun.tools.attach.VirtualMachine
at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(Unknown Source)
at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(Unknown
Source)
at java.base/java.lang.ClassLoader.loadClass(Unknown Source)
... 9 more
{code}
Also, I believe we should not prevent from running all sjk commands with JRE.
There are some which do not require the modules.
For example - sjk ttop
{quote}I inspected chronicle queue code and documentation
{quote}
There was lazy consensus on the ML around chronicle and JRE. Thus, I did not
finish digging there but documented the recommendation. Also, we use
chronicle-queue, chronicle-core, chronicle-bytes, chronicle-wire, and
chronicle-threads, and [the
docs|https://chronicle.software/chronicle-support-java-17/] are not
particularly for chronicle-queue. If the community goes into that road, we must
check them all. Furthermore, it could be performance-related, not definitive
failure.
> Check whether the startup warnings for unknown modules represent a legit
> problem or cosmetic issue
> --
>
> Key: CASSANDRA-19001
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19001
> Project: Cassandra
>
[jira] [Comment Edited] (CASSANDRA-19107) Revert unnecessary read lock acquisition when reading ring version in TokenMetadata introduced in CASSANDRA-16286
[
https://issues.apache.org/jira/browse/CASSANDRA-19107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17804470#comment-17804470
]
Caleb Rackliffe edited comment on CASSANDRA-19107 at 1/8/24 10:40 PM:
--
4.0 patch: https://github.com/apache/cassandra/pull/3034
4.1 patch: https://github.com/apache/cassandra/pull/3035
5.0 patch: TODO
(Will post tests shortly. This is a 3-4 line patch, and should port cleanly to
4.1 and 5.0)
was (Author: maedhroz):
4.0 patch: [https://github.com/apache/cassandra/pull/3034]
(Will post tests shortly. This is a 3-4 line patch, and should port cleanly to
4.1 and 5.0)
> Revert unnecessary read lock acquisition when reading ring version in
> TokenMetadata introduced in CASSANDRA-16286
> -
>
> Key: CASSANDRA-19107
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19107
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Distributed Metadata
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0-rc
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> CASSANDRA-16286 achieved its goal of making sure that concurrent increments
> to the ring version would independently increment the version (i.e. not
> "merge" multiple invalidations into single versions), but it also
> unnecessarily replaced the volatile read on {{ringVersion}} w/ making
> {{readVersion}} non-volatile and acquiring the read lock on the fair
> {{ReadWriteLock}} in {{TokenMetadata}}. This can result in unnecessary
> queueing w/ high CPU usage/read volume. For example, you might see this on a
> 4.0 cluster...
> {noformat}
> "Native-Transport-Requests-99" #271 daemon prio=5 os_prio=0 cpu=5822566.56ms
> elapsed=1949.40s tid=0x7fcc96c31b00 nid=0xb7bd waiting on condition
> [0x7fcb7f144000]
> java.lang.Thread.State: WAITING (parking)
>at jdk.internal.misc.Unsafe.park(java.base@11.0.16/Native Method)
>- parking to wait for <0x0005c0ab92a0> (a
> java.util.concurrent.locks.ReentrantReadWriteLock$FairSync)
>at
> java.util.concurrent.locks.LockSupport.park(java.base@11.0.16/LockSupport.java:194)
>at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(java.base@11.0.16/AbstractQueuedSynchronizer.java:885)
>at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireShared(java.base@11.0.16/AbstractQueuedSynchronizer.java:1009)
>at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireShared(java.base@11.0.16/AbstractQueuedSynchronizer.java:1324)
>at
> java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.lock(java.base@11.0.16/ReentrantReadWriteLock.java:738)
>at
> org.apache.cassandra.locator.TokenMetadata.getRingVersion(TokenMetadata.java:1389)
>at
> org.apache.cassandra.locator.AbstractReplicationStrategy.getCachedReplicas(AbstractReplicationStrategy.java:82)
>at
> org.apache.cassandra.locator.AbstractReplicationStrategy.getNaturalReplicas(AbstractReplicationStrategy.java:116)
>at
> org.apache.cassandra.locator.AbstractReplicationStrategy.getNaturalReplicasForToken(AbstractReplicationStrategy.java:109)
>at
> org.apache.cassandra.locator.ReplicaLayout.forTokenWriteLiveAndDown(ReplicaLayout.java:209)
>at
> org.apache.cassandra.locator.ReplicaPlans.forWrite(ReplicaPlans.java:328)
>at
> org.apache.cassandra.service.StorageProxy.performWrite(StorageProxy.java:1426)
>at
> org.apache.cassandra.service.StorageProxy.mutate(StorageProxy.java:937)
> {noformat}
> Reverting to a volatile read makes this no longer possible, but keeps the fix
> from CASSANDRA-16286 intact.
--
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-19107) Revert unnecessary read lock acquisition when reading ring version in TokenMetadata introduced in CASSANDRA-16286
[
https://issues.apache.org/jira/browse/CASSANDRA-19107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17804470#comment-17804470
]
Caleb Rackliffe edited comment on CASSANDRA-19107 at 1/8/24 10:49 PM:
--
4.0 patch: https://github.com/apache/cassandra/pull/3034
4.1 patch: https://github.com/apache/cassandra/pull/3035
5.0 patch: https://github.com/apache/cassandra/pull/3037
(Will post tests shortly...)
was (Author: maedhroz):
4.0 patch: https://github.com/apache/cassandra/pull/3034
4.1 patch: https://github.com/apache/cassandra/pull/3035
5.0 patch: TODO
(Will post tests shortly. This is a 3-4 line patch, and should port cleanly to
4.1 and 5.0)
> Revert unnecessary read lock acquisition when reading ring version in
> TokenMetadata introduced in CASSANDRA-16286
> -
>
> Key: CASSANDRA-19107
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19107
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Distributed Metadata
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0-rc
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> CASSANDRA-16286 achieved its goal of making sure that concurrent increments
> to the ring version would independently increment the version (i.e. not
> "merge" multiple invalidations into single versions), but it also
> unnecessarily replaced the volatile read on {{ringVersion}} w/ making
> {{readVersion}} non-volatile and acquiring the read lock on the fair
> {{ReadWriteLock}} in {{TokenMetadata}}. This can result in unnecessary
> queueing w/ high CPU usage/read volume. For example, you might see this on a
> 4.0 cluster...
> {noformat}
> "Native-Transport-Requests-99" #271 daemon prio=5 os_prio=0 cpu=5822566.56ms
> elapsed=1949.40s tid=0x7fcc96c31b00 nid=0xb7bd waiting on condition
> [0x7fcb7f144000]
> java.lang.Thread.State: WAITING (parking)
>at jdk.internal.misc.Unsafe.park(java.base@11.0.16/Native Method)
>- parking to wait for <0x0005c0ab92a0> (a
> java.util.concurrent.locks.ReentrantReadWriteLock$FairSync)
>at
> java.util.concurrent.locks.LockSupport.park(java.base@11.0.16/LockSupport.java:194)
>at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(java.base@11.0.16/AbstractQueuedSynchronizer.java:885)
>at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireShared(java.base@11.0.16/AbstractQueuedSynchronizer.java:1009)
>at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireShared(java.base@11.0.16/AbstractQueuedSynchronizer.java:1324)
>at
> java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.lock(java.base@11.0.16/ReentrantReadWriteLock.java:738)
>at
> org.apache.cassandra.locator.TokenMetadata.getRingVersion(TokenMetadata.java:1389)
>at
> org.apache.cassandra.locator.AbstractReplicationStrategy.getCachedReplicas(AbstractReplicationStrategy.java:82)
>at
> org.apache.cassandra.locator.AbstractReplicationStrategy.getNaturalReplicas(AbstractReplicationStrategy.java:116)
>at
> org.apache.cassandra.locator.AbstractReplicationStrategy.getNaturalReplicasForToken(AbstractReplicationStrategy.java:109)
>at
> org.apache.cassandra.locator.ReplicaLayout.forTokenWriteLiveAndDown(ReplicaLayout.java:209)
>at
> org.apache.cassandra.locator.ReplicaPlans.forWrite(ReplicaPlans.java:328)
>at
> org.apache.cassandra.service.StorageProxy.performWrite(StorageProxy.java:1426)
>at
> org.apache.cassandra.service.StorageProxy.mutate(StorageProxy.java:937)
> {noformat}
> Reverting to a volatile read makes this no longer possible, but keeps the fix
> from CASSANDRA-16286 intact.
--
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-19205) Fix flaky test: org.apache.cassandra.tools.BulkLoaderTest.testBulkLoader_WithArgs1-_jdk17
[
https://issues.apache.org/jira/browse/CASSANDRA-19205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17804522#comment-17804522
]
Ekaterina Dimitrova commented on CASSANDRA-19205:
-
Thank you for the review and the testing.
The test is presented on 4.0+.
||Patches||Repeatable Run||
|[4.0
|https://github.com/ekaterinadimitrova2/cassandra/commit/715d18e4c7cf0e770ee8d1439690779decd05b7b]|[CircleCI
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra?branch=19205-4.0]|
|[4.1
|https://github.com/ekaterinadimitrova2/cassandra/commit/238dc362786ba4cba7e9363db6d293e05c67680e]|[CircleCI
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra?branch=19205-4.1]|
|[5.0
|https://github.com/ekaterinadimitrova2/cassandra/commit/049b8de5962db8c972b182662f3556ee3b636521]|[CircleCI
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra?branch=C19205-rebased]|
|[trunk
|https://github.com/ekaterinadimitrova2/cassandra/commit/0c6dbe822fb66fc834a91eb7464cc238d54225c0]|[CircleCI
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra?branch=C19205-trunk]|
> Fix flaky test:
> org.apache.cassandra.tools.BulkLoaderTest.testBulkLoader_WithArgs1-_jdk17
> -
>
> Key: CASSANDRA-19205
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19205
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/bulk load
>Reporter: Brandon Williams
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
>
> Seen here:
> https://app.circleci.com/pipelines/github/driftx/cassandra/1418/workflows/5d108993-69f8-4bb8-a616-93a1d904ff1a/jobs/67177/tests
> {quote}
> junit.framework.AssertionFailedError: Wrong thread status, active threads
> unaccounted for: [cluster2-nio-worker-2]
> at
> org.apache.cassandra.tools.OfflineToolUtils.assertNoUnexpectedThreadsStarted(OfflineToolUtils.java:120)
> at
> org.apache.cassandra.tools.BulkLoaderTest.testBulkLoader_WithArgs1(BulkLoaderTest.java:97)
> 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)
> {quote}
> Looks like either a thread is hanging around too long or we need to except 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] [Comment Edited] (CASSANDRA-19205) Fix flaky test: org.apache.cassandra.tools.BulkLoaderTest.testBulkLoader_WithArgs1-_jdk17
[
https://issues.apache.org/jira/browse/CASSANDRA-19205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17804522#comment-17804522
]
Ekaterina Dimitrova edited comment on CASSANDRA-19205 at 1/9/24 12:11 AM:
--
Thank you for the review and the testing.
The test is presented on 4.0+.
||Patches||Repeatable Run||
|[4.0
|https://github.com/ekaterinadimitrova2/cassandra/commit/715d18e4c7cf0e770ee8d1439690779decd05b7b]|[CircleCI
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra?branch=19205-4.0]|
|[4.1
|https://github.com/ekaterinadimitrova2/cassandra/commit/238dc362786ba4cba7e9363db6d293e05c67680e]|[CircleCI
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra?branch=19205-4.1]|
|[5.0
|https://github.com/ekaterinadimitrova2/cassandra/commit/049b8de5962db8c972b182662f3556ee3b636521]|[CircleCI
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra?branch=C19205-rebased]|
|[trunk
|https://github.com/ekaterinadimitrova2/cassandra/commit/0c6dbe822fb66fc834a91eb7464cc238d54225c0]|[CircleCI
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra?branch=C19205-trunk]|
EDIT: The repeated runs are still running, I will check the results tomorrow
morning
was (Author: e.dimitrova):
Thank you for the review and the testing.
The test is presented on 4.0+.
||Patches||Repeatable Run||
|[4.0
|https://github.com/ekaterinadimitrova2/cassandra/commit/715d18e4c7cf0e770ee8d1439690779decd05b7b]|[CircleCI
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra?branch=19205-4.0]|
|[4.1
|https://github.com/ekaterinadimitrova2/cassandra/commit/238dc362786ba4cba7e9363db6d293e05c67680e]|[CircleCI
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra?branch=19205-4.1]|
|[5.0
|https://github.com/ekaterinadimitrova2/cassandra/commit/049b8de5962db8c972b182662f3556ee3b636521]|[CircleCI
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra?branch=C19205-rebased]|
|[trunk
|https://github.com/ekaterinadimitrova2/cassandra/commit/0c6dbe822fb66fc834a91eb7464cc238d54225c0]|[CircleCI
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra?branch=C19205-trunk]|
> Fix flaky test:
> org.apache.cassandra.tools.BulkLoaderTest.testBulkLoader_WithArgs1-_jdk17
> -
>
> Key: CASSANDRA-19205
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19205
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/bulk load
>Reporter: Brandon Williams
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
>
> Seen here:
> https://app.circleci.com/pipelines/github/driftx/cassandra/1418/workflows/5d108993-69f8-4bb8-a616-93a1d904ff1a/jobs/67177/tests
> {quote}
> junit.framework.AssertionFailedError: Wrong thread status, active threads
> unaccounted for: [cluster2-nio-worker-2]
> at
> org.apache.cassandra.tools.OfflineToolUtils.assertNoUnexpectedThreadsStarted(OfflineToolUtils.java:120)
> at
> org.apache.cassandra.tools.BulkLoaderTest.testBulkLoader_WithArgs1(BulkLoaderTest.java:97)
> 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)
> {quote}
> Looks like either a thread is hanging around too long or we need to except 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
(cassandra-website) branch asf-staging updated (f4b4d7f30 -> 24d17bb25)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git discard f4b4d7f30 generate docs for 8ea493af new 24d17bb25 generate docs for 8ea493af This update added new revisions after undoing existing revisions. That is to say, some revisions that were in the old version of the branch are not in the new version. This situation occurs when a user --force pushes a change and generates a repository containing something like this: * -- * -- B -- O -- O -- O (f4b4d7f30) \ N -- N -- N refs/heads/asf-staging (24d17bb25) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: .../managing/configuration/cass_yaml_file.html | 40 + .../managing/configuration/cass_yaml_file.html | 40 + .../managing/configuration/cass_yaml_file.html | 40 + .../managing/configuration/cass_yaml_file.html | 40 + content/search-index.js| 2 +- site-ui/build/ui-bundle.zip| Bin 4883726 -> 4883726 bytes 6 files changed, 161 insertions(+), 1 deletion(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17667) Text value containing "/*" interpreted as multiline comment in cqlsh
[
https://issues.apache.org/jira/browse/CASSANDRA-17667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17804539#comment-17804539
]
Brad Schoening commented on CASSANDRA-17667:
I spoke with [~ahomoki] and he isn't able to work on this anymore, and Vineet
who had picked it up in August was an intern who has since moved on. I'll pick
this up to update the branch PRs and see if adding new unit tests is
straightforward.
> Text value containing "/*" interpreted as multiline comment in cqlsh
>
>
> Key: CASSANDRA-17667
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17667
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: ANOOP THOMAS
>Assignee: Brad Schoening
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x
>
>
> I use CQLSH command line utility to load some DDLs. The version of utility I
> use is this:
> {noformat}
> [cqlsh 6.0.0 | Cassandra 4.0.0.47 | CQL spec 3.4.5 | Native protocol
> v5]{noformat}
> Command that loads DDL.cql:
> {noformat}
> cqlsh -u username -p password cassandra.example.com 65503 --ssl -f DDL.cql
> {noformat}
> I have a line in CQL script that breaks the syntax.
> {noformat}
> INSERT into tablename (key,columnname1,columnname2) VALUES
> ('keyName','value1','/value2/*/value3');{noformat}
> {{/*}} here is interpreted as start of multi-line comment. It used to work on
> older versions of cqlsh. The error I see looks like this:
> {noformat}
> SyntaxException: line 4:2 mismatched input 'Update' expecting ')'
> (...,'value1','/value2INSERT into tablename(INSERT into tablename
> (key,columnname1,columnname2)) VALUES ('[Update]-...) SyntaxException: line
> 1:0 no viable alternative at input '(' ([(]...)
> {noformat}
> Same behavior while running in interactive mode too. {{/*}} inside a CQL
> statement should not be interpreted as start of multi-line comment.
> With schema:
> {code:java}
> CREATE TABLE tablename ( key text primary key, columnname1 text, columnname2
> text);{code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18688) Limit Java runtime in 5.0 to JDK 11 and 17 in scripts; add a flag to opt out of that
[ https://issues.apache.org/jira/browse/CASSANDRA-18688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17804545#comment-17804545 ] shylaja kokoori commented on CASSANDRA-18688: - Thank you, updated the changes [here |[https://github.com/apache/cassandra/pull/2563/commits/0a77b30a326ea0e3c77ebd369a4b504c4e6ad354]] > Limit Java runtime in 5.0 to JDK 11 and 17 in scripts; add a flag to opt out > of that > > > Key: CASSANDRA-18688 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18688 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Ekaterina Dimitrova >Assignee: shylaja kokoori >Priority: Normal > Fix For: 5.0.x, 5.x > > Time Spent: 3.5h > Remaining Estimate: 0h > > Currently, we limit our users from building with non-default Java versions in > build.xml. > They can easily hack build.xml for test purposes with different versions. > Cassandra–5.0 will be run on JDK11 and JDK17, but on startup, we do not limit > people to those two, but only to everything >= 11. We should also put an > upper limit of 17 in our Cassandra startup scripts. We can also add a flag to > opt-out if someone wants to test with newer versions. -- 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-18688) Limit Java runtime in 5.0 to JDK 11 and 17 in scripts; add a flag to opt out of that
[ https://issues.apache.org/jira/browse/CASSANDRA-18688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17804545#comment-17804545 ] shylaja kokoori edited comment on CASSANDRA-18688 at 1/9/24 1:48 AM: - Thank you, updated the pull request with suggested changes [https://github.com/apache/cassandra/pull/2563/commits/0a77b30a326ea0e3c77ebd369a4b504c4e6ad354] was (Author: shylaja.koko...@intel.com): Thank you, updated the changes [here |[https://github.com/apache/cassandra/pull/2563/commits/0a77b30a326ea0e3c77ebd369a4b504c4e6ad354]] > Limit Java runtime in 5.0 to JDK 11 and 17 in scripts; add a flag to opt out > of that > > > Key: CASSANDRA-18688 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18688 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Ekaterina Dimitrova >Assignee: shylaja kokoori >Priority: Normal > Fix For: 5.0.x, 5.x > > Time Spent: 3.5h > Remaining Estimate: 0h > > Currently, we limit our users from building with non-default Java versions in > build.xml. > They can easily hack build.xml for test purposes with different versions. > Cassandra–5.0 will be run on JDK11 and JDK17, but on startup, we do not limit > people to those two, but only to everything >= 11. We should also put an > upper limit of 17 in our Cassandra startup scripts. We can also add a flag to > opt-out if someone wants to test with newer versions. -- 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-18112) Add the feature of INDEX HINT for CQL
[ https://issues.apache.org/jira/browse/CASSANDRA-18112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17804583#comment-17804583 ] Maxwell Guo commented on CASSANDRA-18112: - Thanks. > Add the feature of INDEX HINT for CQL > -- > > Key: CASSANDRA-18112 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18112 > Project: Cassandra > Issue Type: Improvement > Components: CQL/Syntax, Feature/SAI, Legacy/CQL >Reporter: Maxwell Guo >Assignee: Maxwell Guo >Priority: Normal > Fix For: 5.0.x > > > It seems that CQL do not have the ability of INDEX HINT , such as when we > have more than one secondary index for some data table,And if the query hit > the indexes, the index with more estimate rows will be returned. But if we > want the query to be executed under our willing , we can use a hint like > ,hint specified index or ignore the index. > At first I want to open a jira that to add the feature of hint for CQL ,But I > think that may be a gigantic task with no clear goal. > Besides I think there may need a DISSCUSS for the specific grammatical form > before starting the work. -- 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-7662) Implement templated CREATE TABLE functionality (CREATE TABLE LIKE)
[ https://issues.apache.org/jira/browse/CASSANDRA-7662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17804584#comment-17804584 ] Maxwell Guo commented on CASSANDRA-7662: Any update on this ? [~epsi.rex] , I think I can take over this if you do not have some time . And [~aleksey] , do you think we should make a DISCUSS in the mailing list as we are going to introduce a new grammar. > Implement templated CREATE TABLE functionality (CREATE TABLE LIKE) > -- > > Key: CASSANDRA-7662 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7662 > Project: Cassandra > Issue Type: New Feature > Components: Legacy/CQL >Reporter: Aleksey Yeschenko >Priority: Low > Labels: AdventCalendar2021, lhf > Fix For: 5.x > > Attachments: 7662.patch, CASSANDRA-7662.patch > > > Implement templated CREATE TABLE functionality (CREATE TABLE LIKE) to > simplify creating new tables duplicating existing ones (see parent_table part > of http://www.postgresql.org/docs/9.1/static/sql-createtable.html). > CREATE TABLE LIKE ; - would create a new table with > the same columns and options as > +Additional info for newcomers:+ > In order to implement this change you will need to change the Parser.g ANTLR > file located in the src/antlr directory and the java classes corresponding to > the CREATE statement located in the > org.apache.cassandra.cql3.statements.schema package. > The unit test for the CQL logic are located under > org.apache.cassandra.cql3.validation > cqlsh parsing will need to be modified to support the new LIKE syntax. The > logic is in pylib/cqlshlib/cql3handling.py and the test in > pylib/cqlshlib/test/test_cqlsh_completion.py -- 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-7662) Implement templated CREATE TABLE functionality (CREATE TABLE LIKE)
[ https://issues.apache.org/jira/browse/CASSANDRA-7662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17804584#comment-17804584 ] Maxwell Guo edited comment on CASSANDRA-7662 at 1/9/24 6:06 AM: Any update on this ? [~epsi.rex] , I think I can take over this if you do not have time working on this ticket. And [~aleksey] , do you think we should make a DISCUSS in the mailing list as we are going to introduce a new grammar. was (Author: maxwellguo): Any update on this ? [~epsi.rex] , I think I can take over this if you do not have some time . And [~aleksey] , do you think we should make a DISCUSS in the mailing list as we are going to introduce a new grammar. > Implement templated CREATE TABLE functionality (CREATE TABLE LIKE) > -- > > Key: CASSANDRA-7662 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7662 > Project: Cassandra > Issue Type: New Feature > Components: Legacy/CQL >Reporter: Aleksey Yeschenko >Priority: Low > Labels: AdventCalendar2021, lhf > Fix For: 5.x > > Attachments: 7662.patch, CASSANDRA-7662.patch > > > Implement templated CREATE TABLE functionality (CREATE TABLE LIKE) to > simplify creating new tables duplicating existing ones (see parent_table part > of http://www.postgresql.org/docs/9.1/static/sql-createtable.html). > CREATE TABLE LIKE ; - would create a new table with > the same columns and options as > +Additional info for newcomers:+ > In order to implement this change you will need to change the Parser.g ANTLR > file located in the src/antlr directory and the java classes corresponding to > the CREATE statement located in the > org.apache.cassandra.cql3.statements.schema package. > The unit test for the CQL logic are located under > org.apache.cassandra.cql3.validation > cqlsh parsing will need to be modified to support the new LIKE syntax. The > logic is in pylib/cqlshlib/cql3handling.py and the test in > pylib/cqlshlib/test/test_cqlsh_completion.py -- 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-7662) Implement templated CREATE TABLE functionality (CREATE TABLE LIKE)
[ https://issues.apache.org/jira/browse/CASSANDRA-7662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17804593#comment-17804593 ] Somiparno Chattopadhyay commented on CASSANDRA-7662: [~maxwellguo] Yes go ahead. I got engaged with a lot of other personal and professional work. > Implement templated CREATE TABLE functionality (CREATE TABLE LIKE) > -- > > Key: CASSANDRA-7662 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7662 > Project: Cassandra > Issue Type: New Feature > Components: Legacy/CQL >Reporter: Aleksey Yeschenko >Priority: Low > Labels: AdventCalendar2021, lhf > Fix For: 5.x > > Attachments: 7662.patch, CASSANDRA-7662.patch > > > Implement templated CREATE TABLE functionality (CREATE TABLE LIKE) to > simplify creating new tables duplicating existing ones (see parent_table part > of http://www.postgresql.org/docs/9.1/static/sql-createtable.html). > CREATE TABLE LIKE ; - would create a new table with > the same columns and options as > +Additional info for newcomers:+ > In order to implement this change you will need to change the Parser.g ANTLR > file located in the src/antlr directory and the java classes corresponding to > the CREATE statement located in the > org.apache.cassandra.cql3.statements.schema package. > The unit test for the CQL logic are located under > org.apache.cassandra.cql3.validation > cqlsh parsing will need to be modified to support the new LIKE syntax. The > logic is in pylib/cqlshlib/cql3handling.py and the test in > pylib/cqlshlib/test/test_cqlsh_completion.py -- 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-18714) Expand CQLSSTableWriter to write SSTable-attached secondary indexes
[
https://issues.apache.org/jira/browse/CASSANDRA-18714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-18714:
--
Fix Version/s: 5.0-rc
> Expand CQLSSTableWriter to write SSTable-attached secondary indexes
> ---
>
> Key: CASSANDRA-18714
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18714
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/SAI, Tool/bulk load
>Reporter: Caleb Rackliffe
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{CQLSSTableWriter}} currently has no way of writing any secondary indexes
> inline as it writes the core SSTable components. With SAI, this has become
> tractable problem, and we should be able to enhance both it and
> {{SSTableImporter}} to handle cases where we might want to write SSTables
> somewhere in bulk (and in parallel) and then import them without waiting for
> index building on import. It would require the following changes:
> 1.) {{CQLSSTableWriter}} must accept 2i definitions on top of its current
> table schema definition. Once added to the schema, any {{ColumnFamilyStore}}
> instances opened will have those 2i defined in their index managers.
> 2.) All {{AbstractSSTableSimpleWriter}} instances must register index groups,
> allowing the proper {{SSTableFlushObservers}} to be attached to
> {{SSTableWriter}}. Once this is done, SAI (and any other SSTable-attached
> indexes) components will be built incrementally along w/ the SSTable data
> file, and will be finalized when the newly written SSTable is finalized.
> 3.) Provide an example (in a unit test?) of how a third-party tool might,
> assuming access to the right C* JAR, validate/checksum SAI components outside
> C* proper.
> 4.) {{SSTableImporter}} should have two new options:
> a.) an option that fails import if any SSTable-attached 2i must be built
> (i.e. has not already been built and brought along w/ the other new SSTable
> components)
> b.) an option that allows us to bypass full checksum validation on
> imported/already-built SSTable-attached indexes (assuming they have just been
> written by {{CQLSSTableWriter}})
--
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
