[jira] [Updated] (CASSANDRA-18968) StartupClusterConnectivityChecker fails on upgrade from 3.X
[
https://issues.apache.org/jira/browse/CASSANDRA-18968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-18968:
--
Status: Needs Committer (was: Review In Progress)
> StartupClusterConnectivityChecker fails on upgrade from 3.X
> ---
>
> Key: CASSANDRA-18968
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18968
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Startup and Shutdown
>Reporter: Paulo Motta
>Assignee: Isaac Reath
>Priority: Normal
> Labels: lhf
> Fix For: 4.0.x, 4.1.x
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> Starting up a new 4.X node on a 3.x cluster throws the following warning:
> {noformat}
> WARN [main] 2023-10-27 15:58:22,234
> StartupClusterConnectivityChecker.java:183 - Timed out after 10002
> milliseconds, was waiting for remaining peers to connect: {dc1=[X.Y.Z.W,
> A.B.C.D]}
> {noformat}
> I think this is because the PING messages used by the startup check are not
> available on 3.X.
> To provide a smoother upgrade experience we should probably disable this
> check on a mixed version clusters, or skip peers on versions < 4.x when doing
> the connectivity check.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18968) StartupClusterConnectivityChecker fails on upgrade from 3.X
[
https://issues.apache.org/jira/browse/CASSANDRA-18968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17783911#comment-17783911
]
Stefan Miklosovic commented on CASSANDRA-18968:
---
[4.0
j11-precommit|https://app.circleci.com/pipelines/github/instaclustr/cassandra/3457/workflows/10731e97-21b1-4846-9450-800f8dc0bc05]
[4.0
j8-precommit|https://app.circleci.com/pipelines/github/instaclustr/cassandra/3457/workflows/b37d8e69-cc51-48ea-9d12-75e493eb1351]
[4.1
j11-precommit|https://app.circleci.com/pipelines/github/instaclustr/cassandra/3458/workflows/122fcd49-3e1e-494b-8949-b75bf2b9f6af]
[4.1
j8-precommit|https://app.circleci.com/pipelines/github/instaclustr/cassandra/3458/workflows/5539e1f8-ec73-4201-9ef4-6c12f9858aa9]
+1, I am waiting for another format +1 and we can ship this!
these were the squashed branches I was running CI for:
[4.0|https://github.com/instaclustr/cassandra/commits/CASSANDRA-18968-4.0]
[4.1|https://github.com/instaclustr/cassandra/commits/CASSANDRA-18968-4.1]
> StartupClusterConnectivityChecker fails on upgrade from 3.X
> ---
>
> Key: CASSANDRA-18968
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18968
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Startup and Shutdown
>Reporter: Paulo Motta
>Assignee: Isaac Reath
>Priority: Normal
> Labels: lhf
> Fix For: 4.0.x, 4.1.x
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> Starting up a new 4.X node on a 3.x cluster throws the following warning:
> {noformat}
> WARN [main] 2023-10-27 15:58:22,234
> StartupClusterConnectivityChecker.java:183 - Timed out after 10002
> milliseconds, was waiting for remaining peers to connect: {dc1=[X.Y.Z.W,
> A.B.C.D]}
> {noformat}
> I think this is because the PING messages used by the startup check are not
> available on 3.X.
> To provide a smoother upgrade experience we should probably disable this
> check on a mixed version clusters, or skip peers on versions < 4.x when doing
> the connectivity check.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18993) Harry-found silent data loss issue
[ https://issues.apache.org/jira/browse/CASSANDRA-18993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17783906#comment-17783906 ] Alex Petrov commented on CASSANDRA-18993: - Since we have attributed this to CASSANDRA-18932,i would say no. I see no reason this affects 4.1. > Harry-found silent data loss issue > -- > > Key: CASSANDRA-18993 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18993 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Core >Reporter: Alex Petrov >Assignee: Jacek Lewandowski >Priority: Normal > Fix For: 4.1.x, 5.0-beta, 5.x > > > Harry has discovered a silent data loss bug in trunk, but it goes all the way > back to appx 4.1. > Some rows are not visble after flush. Compared Harry repro running a memtable > instead of a regular Harry model, and it still reproduces (in other words, it > is almost certainly not a Harry issue). > Simple schema, and only one flush is required for repro, so not an unlikely > bug. Max partition size is 1k rows, so not an unlikely setup here, either. No > concurrency involved; reproduces stably. Good chance this is related to the > fact the schema has DESC clusterings. > I am working on posting a Harry branch that stably reproduces 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-18944) Test failure: org.apache.cassandra.simulator.test.ShortPaxosSimulationTest.simulationTest
[
https://issues.apache.org/jira/browse/CASSANDRA-18944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova reassigned CASSANDRA-18944:
---
Assignee: (was: Ekaterina Dimitrova)
> Test failure:
> org.apache.cassandra.simulator.test.ShortPaxosSimulationTest.simulationTest
> -
>
> Key: CASSANDRA-18944
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18944
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Andres de la Peña
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
>
> The simulator test
> {{org.apache.cassandra.simulator.test.ShortPaxosSimulationTest#simulationTest}}
> is flaky on 5.0 and trunk:
> *
> https://app.circleci.com/pipelines/github/mike-tr-adamson/cassandra/332/workflows/946e28f4-2dec-4384-ac38-de011093f6c6/jobs/25735/tests
> *
> https://app.circleci.com/pipelines/github/adelapena/cassandra/3253/workflows/e48b49e9-cf36-412a-a811-d813031e6f01/jobs/83735/tests
> *
> https://app.circleci.com/pipelines/github/adelapena/cassandra/3254/workflows/69f451ef-fb39-48e4-b1d1-40ee4141b0c1/jobs/83739/tests
> {code}
> org.apache.cassandra.simulator.SimulationException: Failed on seed
> 0xb01206bb3b021127
> Caused by: java.lang.ClassCastException: class
> org.apache.cassandra.net.NoPayload cannot be cast to class
> org.apache.cassandra.gms.GossipShutdown (org.apache.cassandra.net.NoPayload
> and org.apache.cassandra.gms.GossipShutdown are in unnamed module of loader
> org.apache.cassandra.distributed.shared.InstanceClassLoader @68801feb)
> at
> org.apache.cassandra.gms.GossipShutdown$Serializer.serialize(GossipShutdown.java:41)
> at
> org.apache.cassandra.net.Message$Serializer.serialize(Message.java:722)
> at
> org.apache.cassandra.distributed.impl.Instance.serializeMessage(Instance.java:427)
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$registerOutboundFilter$5(Instance.java:370)
> at
> org.apache.cassandra.net.OutboundSink$Filtered.accept(OutboundSink.java:54)
> at org.apache.cassandra.net.OutboundSink.accept(OutboundSink.java:70)
> at
> org.apache.cassandra.net.MessagingService.send(MessagingService.java:449)
> at
> org.apache.cassandra.net.MessagingService.send(MessagingService.java:419)
> at
> org.apache.cassandra.gms.Gossiper.unsafeSendShutdown(Gossiper.java:2634)
> at
> org.apache.cassandra.simulator.cluster.OnInstanceSendShutdown.lambda$invokableSendShutdown$1(OnInstanceSendShutdown.java:48)
> 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 org.apache.cassandra.concurrent.FutureTask$1.call(FutureTask.java:96)
> at
> org.apache.cassandra.concurrent.SyncFutureTask$1.call(SyncFutureTask.java:46)
> at
> org.apache.cassandra.concurrent.SyncFutureTask.run(SyncFutureTask.java:68)
> at
> org.apache.cassandra.simulator.systems.InterceptingExecutor$AbstractSingleThreadedExecutorPlus.lambda$new$0(InterceptingExecutor.java:584)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:829)
> {code}
> The test failure can easily be reproduced on CircleCI with:
> {code}
> .circleci/generate.sh -sp \
> -e
> REPEATED_SIMULATOR_DTESTS=org.apache.cassandra.simulator.test.ShortPaxosSimulationTest
> \
> -e REPEATED_SIMULATOR_DTESTS_COUNT=100
> {code}
> Flakiness seems ~18%.
> The test failure is not reported on Butler because simulator tests are not
> run by Jenkins.
--
This message was sent by Atlassian 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-18944) Test failure: org.apache.cassandra.simulator.test.ShortPaxosSimulationTest.simulationTest
[
https://issues.apache.org/jira/browse/CASSANDRA-18944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova reassigned CASSANDRA-18944:
---
Assignee: Ekaterina Dimitrova
> Test failure:
> org.apache.cassandra.simulator.test.ShortPaxosSimulationTest.simulationTest
> -
>
> Key: CASSANDRA-18944
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18944
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Andres de la Peña
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
>
> The simulator test
> {{org.apache.cassandra.simulator.test.ShortPaxosSimulationTest#simulationTest}}
> is flaky on 5.0 and trunk:
> *
> https://app.circleci.com/pipelines/github/mike-tr-adamson/cassandra/332/workflows/946e28f4-2dec-4384-ac38-de011093f6c6/jobs/25735/tests
> *
> https://app.circleci.com/pipelines/github/adelapena/cassandra/3253/workflows/e48b49e9-cf36-412a-a811-d813031e6f01/jobs/83735/tests
> *
> https://app.circleci.com/pipelines/github/adelapena/cassandra/3254/workflows/69f451ef-fb39-48e4-b1d1-40ee4141b0c1/jobs/83739/tests
> {code}
> org.apache.cassandra.simulator.SimulationException: Failed on seed
> 0xb01206bb3b021127
> Caused by: java.lang.ClassCastException: class
> org.apache.cassandra.net.NoPayload cannot be cast to class
> org.apache.cassandra.gms.GossipShutdown (org.apache.cassandra.net.NoPayload
> and org.apache.cassandra.gms.GossipShutdown are in unnamed module of loader
> org.apache.cassandra.distributed.shared.InstanceClassLoader @68801feb)
> at
> org.apache.cassandra.gms.GossipShutdown$Serializer.serialize(GossipShutdown.java:41)
> at
> org.apache.cassandra.net.Message$Serializer.serialize(Message.java:722)
> at
> org.apache.cassandra.distributed.impl.Instance.serializeMessage(Instance.java:427)
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$registerOutboundFilter$5(Instance.java:370)
> at
> org.apache.cassandra.net.OutboundSink$Filtered.accept(OutboundSink.java:54)
> at org.apache.cassandra.net.OutboundSink.accept(OutboundSink.java:70)
> at
> org.apache.cassandra.net.MessagingService.send(MessagingService.java:449)
> at
> org.apache.cassandra.net.MessagingService.send(MessagingService.java:419)
> at
> org.apache.cassandra.gms.Gossiper.unsafeSendShutdown(Gossiper.java:2634)
> at
> org.apache.cassandra.simulator.cluster.OnInstanceSendShutdown.lambda$invokableSendShutdown$1(OnInstanceSendShutdown.java:48)
> 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 org.apache.cassandra.concurrent.FutureTask$1.call(FutureTask.java:96)
> at
> org.apache.cassandra.concurrent.SyncFutureTask$1.call(SyncFutureTask.java:46)
> at
> org.apache.cassandra.concurrent.SyncFutureTask.run(SyncFutureTask.java:68)
> at
> org.apache.cassandra.simulator.systems.InterceptingExecutor$AbstractSingleThreadedExecutorPlus.lambda$new$0(InterceptingExecutor.java:584)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:829)
> {code}
> The test failure can easily be reproduced on CircleCI with:
> {code}
> .circleci/generate.sh -sp \
> -e
> REPEATED_SIMULATOR_DTESTS=org.apache.cassandra.simulator.test.ShortPaxosSimulationTest
> \
> -e REPEATED_SIMULATOR_DTESTS_COUNT=100
> {code}
> Flakiness seems ~18%.
> The test failure is not reported on Butler because simulator tests are not
> run by Jenkins.
--
This message was sent by Atlassian 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-18968) StartupClusterConnectivityChecker fails on upgrade from 3.X
[
https://issues.apache.org/jira/browse/CASSANDRA-18968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17783834#comment-17783834
]
Isaac Reath commented on CASSANDRA-18968:
-
Yeah just 4.0 and 4.1. Afaik 5.0 isn't supposed to support upgrading from 3.x I
think we're ok.
> StartupClusterConnectivityChecker fails on upgrade from 3.X
> ---
>
> Key: CASSANDRA-18968
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18968
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Startup and Shutdown
>Reporter: Paulo Motta
>Assignee: Isaac Reath
>Priority: Normal
> Labels: lhf
> Fix For: 4.0.x, 4.1.x
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> Starting up a new 4.X node on a 3.x cluster throws the following warning:
> {noformat}
> WARN [main] 2023-10-27 15:58:22,234
> StartupClusterConnectivityChecker.java:183 - Timed out after 10002
> milliseconds, was waiting for remaining peers to connect: {dc1=[X.Y.Z.W,
> A.B.C.D]}
> {noformat}
> I think this is because the PING messages used by the startup check are not
> available on 3.X.
> To provide a smoother upgrade experience we should probably disable this
> check on a mixed version clusters, or skip peers on versions < 4.x when doing
> the connectivity check.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19009) CEP-15: (C*/Accord) Schema based fast path reconfiguration
[ https://issues.apache.org/jira/browse/CASSANDRA-19009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17783833#comment-17783833 ] Blake Eggleston commented on CASSANDRA-19009: - [C*|[https://github.com/bdeggleston/cassandra/tree/C19009-accord-fpconfig]] [Accord|[https://github.com/bdeggleston/cassandra-accord/tree/accord-fp-reconfigure-2]] [CI|[https://app.circleci.com/pipelines/github/bdeggleston/cassandra/345/workflows/227bccbd-255e-4a90-a8d8-d2765e746dd1]] > CEP-15: (C*/Accord) Schema based fast path reconfiguration > --- > > Key: CASSANDRA-19009 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19009 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: Blake Eggleston >Assignee: Blake Eggleston >Priority: Normal > Fix For: 5.0.x > > > This adds availability aware accord fast path reconfiguration, as well as > user configurable fast path settings, which are set at the keyspace level and > (optionally) at the table level for increased granularity. > The major parts are: > *Add availability information to cluster metadata* > Accord topology in C* is not stored in cluster metadata, but is meant to > calculated deterministically from cluster metadata state at a given epoch. > This adds the availability data, as well as the failure detector / gossip > listener and state change deduplication to CMS. > *Move C* accord keys/topology from keyspace prefixes to tableid prefixes* > To support per-table fast path settings, topologies and keys need to include > the table id. Since accord topologies could begin to consume a lot of memory > in clusters with a lot of nodes and tables, topology generation has been > updated to reuse previously allocated shards / shard parts where possible, > which will only increase heap sizes when things actually change. > *Make fast path settings configurable via schema* > There are 2.5 strategies: Simple, Parameterized, and InheritKeyspaceSettings. > Simple will use as many available nodes as possible for the fast path > electorate, this is the default for the keyspace fast path strategy. > Parameterized allows you to set a target size, and preferred datacenters for > the FP electorate. InheritKeyspace tells topology generation to just use the > keyspace fast path settings, and is the default for the table fast path > strategy. -- This message was sent by Atlassian 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-19009) CEP-15: (C*/Accord) Schema based fast path reconfiguration
[ https://issues.apache.org/jira/browse/CASSANDRA-19009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Eggleston updated CASSANDRA-19009: Test and Documentation Plan: ci Status: Patch Available (was: Open) > CEP-15: (C*/Accord) Schema based fast path reconfiguration > --- > > Key: CASSANDRA-19009 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19009 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: Blake Eggleston >Assignee: Blake Eggleston >Priority: Normal > Fix For: 5.0.x > > > This adds availability aware accord fast path reconfiguration, as well as > user configurable fast path settings, which are set at the keyspace level and > (optionally) at the table level for increased granularity. > The major parts are: > *Add availability information to cluster metadata* > Accord topology in C* is not stored in cluster metadata, but is meant to > calculated deterministically from cluster metadata state at a given epoch. > This adds the availability data, as well as the failure detector / gossip > listener and state change deduplication to CMS. > *Move C* accord keys/topology from keyspace prefixes to tableid prefixes* > To support per-table fast path settings, topologies and keys need to include > the table id. Since accord topologies could begin to consume a lot of memory > in clusters with a lot of nodes and tables, topology generation has been > updated to reuse previously allocated shards / shard parts where possible, > which will only increase heap sizes when things actually change. > *Make fast path settings configurable via schema* > There are 2.5 strategies: Simple, Parameterized, and InheritKeyspaceSettings. > Simple will use as many available nodes as possible for the fast path > electorate, this is the default for the keyspace fast path strategy. > Parameterized allows you to set a target size, and preferred datacenters for > the FP electorate. InheritKeyspace tells topology generation to just use the > keyspace fast path settings, and is the default for the table fast path > strategy. -- This message was sent by Atlassian 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-19009) CEP-15: (C*/Accord) Schema based fast path reconfiguration
[ https://issues.apache.org/jira/browse/CASSANDRA-19009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Eggleston updated CASSANDRA-19009: Change Category: Operability Complexity: Normal Fix Version/s: 5.0.x Reviewers: David Capwell Assignee: Blake Eggleston Status: Open (was: Triage Needed) > CEP-15: (C*/Accord) Schema based fast path reconfiguration > --- > > Key: CASSANDRA-19009 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19009 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: Blake Eggleston >Assignee: Blake Eggleston >Priority: Normal > Fix For: 5.0.x > > > This adds availability aware accord fast path reconfiguration, as well as > user configurable fast path settings, which are set at the keyspace level and > (optionally) at the table level for increased granularity. > The major parts are: > *Add availability information to cluster metadata* > Accord topology in C* is not stored in cluster metadata, but is meant to > calculated deterministically from cluster metadata state at a given epoch. > This adds the availability data, as well as the failure detector / gossip > listener and state change deduplication to CMS. > *Move C* accord keys/topology from keyspace prefixes to tableid prefixes* > To support per-table fast path settings, topologies and keys need to include > the table id. Since accord topologies could begin to consume a lot of memory > in clusters with a lot of nodes and tables, topology generation has been > updated to reuse previously allocated shards / shard parts where possible, > which will only increase heap sizes when things actually change. > *Make fast path settings configurable via schema* > There are 2.5 strategies: Simple, Parameterized, and InheritKeyspaceSettings. > Simple will use as many available nodes as possible for the fast path > electorate, this is the default for the keyspace fast path strategy. > Parameterized allows you to set a target size, and preferred datacenters for > the FP electorate. InheritKeyspace tells topology generation to just use the > keyspace fast path settings, and is the default for the table fast path > strategy. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-19009) CEP-15: (C*/Accord) Schema based fast path reconfiguration
Blake Eggleston created CASSANDRA-19009: --- Summary: CEP-15: (C*/Accord) Schema based fast path reconfiguration Key: CASSANDRA-19009 URL: https://issues.apache.org/jira/browse/CASSANDRA-19009 Project: Cassandra Issue Type: Improvement Components: Accord Reporter: Blake Eggleston This adds availability aware accord fast path reconfiguration, as well as user configurable fast path settings, which are set at the keyspace level and (optionally) at the table level for increased granularity. The major parts are: *Add availability information to cluster metadata* Accord topology in C* is not stored in cluster metadata, but is meant to calculated deterministically from cluster metadata state at a given epoch. This adds the availability data, as well as the failure detector / gossip listener and state change deduplication to CMS. *Move C* accord keys/topology from keyspace prefixes to tableid prefixes* To support per-table fast path settings, topologies and keys need to include the table id. Since accord topologies could begin to consume a lot of memory in clusters with a lot of nodes and tables, topology generation has been updated to reuse previously allocated shards / shard parts where possible, which will only increase heap sizes when things actually change. *Make fast path settings configurable via schema* There are 2.5 strategies: Simple, Parameterized, and InheritKeyspaceSettings. Simple will use as many available nodes as possible for the fast path electorate, this is the default for the keyspace fast path strategy. Parameterized allows you to set a target size, and preferred datacenters for the FP electorate. InheritKeyspace tells topology generation to just use the keyspace fast path settings, and is the default for the table fast path strategy. -- This message was sent by Atlassian 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-19008) Several simulator fixes not yet merged to cep-15-accord
[ https://issues.apache.org/jira/browse/CASSANDRA-19008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ariel Weisberg updated CASSANDRA-19008: --- Reviewers: David Capwell Source Control Link: https://github.com/apache/cassandra/pull/2835 > Several simulator fixes not yet merged to cep-15-accord > --- > > Key: CASSANDRA-19008 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19008 > Project: Cassandra > Issue Type: Task >Reporter: Ariel Weisberg >Priority: Normal > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-19008) Several simulator fixes not yet merged to cep-15-accord
Ariel Weisberg created CASSANDRA-19008: -- Summary: Several simulator fixes not yet merged to cep-15-accord Key: CASSANDRA-19008 URL: https://issues.apache.org/jira/browse/CASSANDRA-19008 Project: Cassandra Issue Type: Task Reporter: Ariel Weisberg -- This message was sent by Atlassian 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-83) Require gossip to be enabled for ring and token ranges mapping endpoints
[ https://issues.apache.org/jira/browse/CASSANDRASC-83?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17783822#comment-17783822 ] Francisco Guerrero commented on CASSANDRASC-83: --- CI: https://app.circleci.com/pipelines/github/frankgh/cassandra-sidecar/366 > Require gossip to be enabled for ring and token ranges mapping endpoints > > > Key: CASSANDRASC-83 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-83 > Project: Sidecar for Apache Cassandra > Issue Type: Improvement > Components: Rest API >Reporter: Francisco Guerrero >Assignee: Francisco Guerrero >Priority: Normal > Labels: pull-request-available > > The ring and token ranges mapping endpoints leverage JMX to produce the > payload. Ring and token ranges mapping information is derived from gossip > information available to the Cassandra instance. If gossip has been disabled, > the information might provide an inconsistent view of the cluster which is > undesirable. We should instead return a 503 (Service Unavailable) to the > client whenever the client tries to access these endpoints and gossip has > been disabled. -- This message was sent by Atlassian 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-19004) Refactor negotiatedProtocolMustBeAcceptedProtocolTest to more clearly specify supported/deprecated protocol versions
[ https://issues.apache.org/jira/browse/CASSANDRA-19004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ariel Weisberg updated CASSANDRA-19004: --- Source Control Link: 5.0 https://github.com/apache/cassandra/pull/2877 trunk https://github.com/apache/cassandra/pull/2878 (was: 5.0 https://github.com/apache/cassandra/pull/2877, trunk https://github.com/apache/cassandra/pull/2878) > Refactor negotiatedProtocolMustBeAcceptedProtocolTest to more clearly specify > supported/deprecated protocol versions > > > Key: CASSANDRA-19004 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19004 > Project: Cassandra > Issue Type: Improvement >Reporter: Ariel Weisberg >Priority: Normal > > Right now it's a little inconsistent and there is some code duplication > between client and internode versions of the test. -- This message was sent by Atlassian 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-19004) Refactor negotiatedProtocolMustBeAcceptedProtocolTest to more clearly specify supported/deprecated protocol versions
[ https://issues.apache.org/jira/browse/CASSANDRA-19004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ariel Weisberg updated CASSANDRA-19004: --- Source Control Link: 5.0 https://github.com/apache/cassandra/pull/2877 trunk https://github.com/apache/cassandra/pull/2878 (was: https://github.com/apache/cassandra/pull/2877, https://github.com/apache/cassandra/pull/2878) > Refactor negotiatedProtocolMustBeAcceptedProtocolTest to more clearly specify > supported/deprecated protocol versions > > > Key: CASSANDRA-19004 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19004 > Project: Cassandra > Issue Type: Improvement >Reporter: Ariel Weisberg >Priority: Normal > > Right now it's a little inconsistent and there is some code duplication > between client and internode versions of the test. -- This message was sent by Atlassian 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-19004) Refactor negotiatedProtocolMustBeAcceptedProtocolTest to more clearly specify supported/deprecated protocol versions
[ https://issues.apache.org/jira/browse/CASSANDRA-19004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ariel Weisberg updated CASSANDRA-19004: --- Source Control Link: 5.0 https://github.com/apache/cassandra/pull/2877, trunk https://github.com/apache/cassandra/pull/2878 (was: 5.0 https://github.com/apache/cassandra/pull/2877 trunk https://github.com/apache/cassandra/pull/2878) > Refactor negotiatedProtocolMustBeAcceptedProtocolTest to more clearly specify > supported/deprecated protocol versions > > > Key: CASSANDRA-19004 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19004 > Project: Cassandra > Issue Type: Improvement >Reporter: Ariel Weisberg >Priority: Normal > > Right now it's a little inconsistent and there is some code duplication > between client and internode versions of the test. -- This message was sent by Atlassian 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-19004) Refactor negotiatedProtocolMustBeAcceptedProtocolTest to more clearly specify supported/deprecated protocol versions
[ https://issues.apache.org/jira/browse/CASSANDRA-19004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ariel Weisberg updated CASSANDRA-19004: --- Source Control Link: https://github.com/apache/cassandra/pull/2877, https://github.com/apache/cassandra/pull/2878 (was: https://github.com/apache/cassandra/pull/2877) > Refactor negotiatedProtocolMustBeAcceptedProtocolTest to more clearly specify > supported/deprecated protocol versions > > > Key: CASSANDRA-19004 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19004 > Project: Cassandra > Issue Type: Improvement >Reporter: Ariel Weisberg >Priority: Normal > > Right now it's a little inconsistent and there is some code duplication > between client and internode versions of the test. -- This message was sent by Atlassian 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-19004) Refactor negotiatedProtocolMustBeAcceptedProtocolTest to more clearly specify supported/deprecated protocol versions
[ https://issues.apache.org/jira/browse/CASSANDRA-19004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ariel Weisberg updated CASSANDRA-19004: --- Source Control Link: https://github.com/apache/cassandra/pull/2877 > Refactor negotiatedProtocolMustBeAcceptedProtocolTest to more clearly specify > supported/deprecated protocol versions > > > Key: CASSANDRA-19004 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19004 > Project: Cassandra > Issue Type: Improvement >Reporter: Ariel Weisberg >Priority: Normal > > Right now it's a little inconsistent and there is some code duplication > between client and internode versions of the test. -- This message was sent by Atlassian 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-19004) Refactor negotiatedProtocolMustBeAcceptedProtocolTest to more clearly specify supported/deprecated protocol versions
[ https://issues.apache.org/jira/browse/CASSANDRA-19004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ariel Weisberg updated CASSANDRA-19004: --- Reviewers: David Capwell > Refactor negotiatedProtocolMustBeAcceptedProtocolTest to more clearly specify > supported/deprecated protocol versions > > > Key: CASSANDRA-19004 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19004 > Project: Cassandra > Issue Type: Improvement >Reporter: Ariel Weisberg >Priority: Normal > > Right now it's a little inconsistent and there is some code duplication > between client and internode versions of the test. -- This message was sent by Atlassian 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-18993) Harry-found silent data loss issue
[ https://issues.apache.org/jira/browse/CASSANDRA-18993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17783817#comment-17783817 ] Paulo Motta commented on CASSANDRA-18993: - Thanks for the repro steps Alex! This reproduces for me in cassandra-5.0 branch, but not on cassandra-4.1. Do you have any reason to believe this affects 4.1? > Harry-found silent data loss issue > -- > > Key: CASSANDRA-18993 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18993 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Core >Reporter: Alex Petrov >Assignee: Jacek Lewandowski >Priority: Normal > Fix For: 4.1.x, 5.0-beta, 5.x > > > Harry has discovered a silent data loss bug in trunk, but it goes all the way > back to appx 4.1. > Some rows are not visble after flush. Compared Harry repro running a memtable > instead of a regular Harry model, and it still reproduces (in other words, it > is almost certainly not a Harry issue). > Simple schema, and only one flush is required for repro, so not an unlikely > bug. Max partition size is 1k rows, so not an unlikely setup here, either. No > concurrency involved; reproduces stably. Good chance this is related to the > fact the schema has DESC clusterings. > I am working on posting a Harry branch that stably reproduces 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-18992) Exclude jna transitive dependecy from the ohc library
[
https://issues.apache.org/jira/browse/CASSANDRA-18992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17783695#comment-17783695
]
Maxim Muzafarov edited comment on CASSANDRA-18992 at 11/7/23 9:01 PM:
--
So I can't get a clean run on the 0.5.1 branch, because the following tests
fail (this failure is related to release/0.5.1 branch in the ohc library repo).
I have forked the ohc repo and added GA with mvn package command which runs
tests during the build as well, you can find a result of the project build
below:
https://github.com/Mmuzaf/ohc/actions/runs/6787087412/job/18449112785
{code}
Failed tests:
ChunkedCacheImplTest.testHotKeyBufferIterator:573 expected [true] but found
[false]
ChunkedCacheImplTest.testHotKeyIterator:417 expected [true] but found [false]
ChunkedFixedCacheImplTest.testHotKeyBufferIterator:499 expected [true] but
found [false]
ChunkedFixedCacheImplTest.testHotKeyIterator:365 expected [true] but found
[false]
{code}
If we ignore these tests by adding @Test(enabled = false), then the execution
of all tests and the project build will be successful for both of
the ohc 0.5.1 + JNA 4.1.0 (as it released)
https://github.com/Mmuzaf/ohc/actions/runs/6787282956/job/18449740138
the ohc 0.5.1 + JNA 5.13.0 (as we want to test)
https://github.com/Mmuzaf/ohc/actions/runs/6787399168/job/18450119146
was (Author: mmuzaf):
So I can't get a clean run on the 0.5.1 branch, because the following tests
fail (this failure is related to release/0.5.1 branch):
https://github.com/Mmuzaf/ohc/actions/runs/6787087412/job/18449112785
{code}
Failed tests:
ChunkedCacheImplTest.testHotKeyBufferIterator:573 expected [true] but found
[false]
ChunkedCacheImplTest.testHotKeyIterator:417 expected [true] but found [false]
ChunkedFixedCacheImplTest.testHotKeyBufferIterator:499 expected [true] but
found [false]
ChunkedFixedCacheImplTest.testHotKeyIterator:365 expected [true] but found
[false]
{code}
If we ignore these tests, then the execution of all tests will be successful
for both
JNA 4.1.0
https://github.com/Mmuzaf/ohc/actions/runs/6787282956/job/18449740138
JNA 5.13.0
https://github.com/Mmuzaf/ohc/actions/runs/6787399168/job/18450119146
> Exclude jna transitive dependecy from the ohc library
> -
>
> Key: CASSANDRA-18992
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18992
> Project: Cassandra
> Issue Type: Task
> Components: Dependencies
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Normal
> Fix For: 5.0-beta, 5.0.x, 5.x
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The concern is related to the JNA dependency on the ohc library. We are now
> using version 0.5.1 of the ohc library in Cassandra. The ohc 0.5.1 depends on
> version 4.1.0 of the net.java.dev.jna . For the Cassandra project, JNA has
> been updated since the 4.0 release version up to JNA 5.6.0 in CASSANDRA-16212
> to support running nodes on the arm64 architecture, so I assume that JNA
> 4.1.0 is no longer in Casssandra's classpath.
> The common practice in the Cassandra project is to exclude these kinds of
> transitive dependencies when they are explicitly mentioned in the main parent
> pom, since Ant may resolve them incorrectly. See comment:
> https://issues.apache.org/jira/browse/CASSANDRA-14667?focusedCommentId=17765091=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17765091
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18635) Test failure: org.apache.cassandra.distributed.test.UpgradeSSTablesTest
[
https://issues.apache.org/jira/browse/CASSANDRA-18635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17783778#comment-17783778
]
Ekaterina Dimitrova commented on CASSANDRA-18635:
-
Thanks, appreciate it!
> Test failure: org.apache.cassandra.distributed.test.UpgradeSSTablesTest
> ---
>
> Key: CASSANDRA-18635
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18635
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: Brandon Williams
>Assignee: Josh McKenzie
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
>
> Seen here:
> https://app.circleci.com/pipelines/github/driftx/cassandra/1095/workflows/6114e2e3-8dcc-4bb0-b664-ae7d82c3349f/jobs/33405/tests
> {noformat}
> junit.framework.AssertionFailedError: expected:<0> but was:<2>
> at
> org.apache.cassandra.distributed.test.UpgradeSSTablesTest.upgradeSSTablesInterruptsOngoingCompaction(UpgradeSSTablesTest.java:86)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18635) Test failure: org.apache.cassandra.distributed.test.UpgradeSSTablesTest
[
https://issues.apache.org/jira/browse/CASSANDRA-18635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17783775#comment-17783775
]
Josh McKenzie commented on CASSANDRA-18635:
---
I'll try and carve out time to take a closer look later this week.
> Test failure: org.apache.cassandra.distributed.test.UpgradeSSTablesTest
> ---
>
> Key: CASSANDRA-18635
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18635
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: Brandon Williams
>Assignee: Josh McKenzie
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
>
> Seen here:
> https://app.circleci.com/pipelines/github/driftx/cassandra/1095/workflows/6114e2e3-8dcc-4bb0-b664-ae7d82c3349f/jobs/33405/tests
> {noformat}
> junit.framework.AssertionFailedError: expected:<0> but was:<2>
> at
> org.apache.cassandra.distributed.test.UpgradeSSTablesTest.upgradeSSTablesInterruptsOngoingCompaction(UpgradeSSTablesTest.java:86)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-18635) Test failure: org.apache.cassandra.distributed.test.UpgradeSSTablesTest
[
https://issues.apache.org/jira/browse/CASSANDRA-18635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh McKenzie reassigned CASSANDRA-18635:
-
Assignee: Josh McKenzie
> Test failure: org.apache.cassandra.distributed.test.UpgradeSSTablesTest
> ---
>
> Key: CASSANDRA-18635
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18635
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: Brandon Williams
>Assignee: Josh McKenzie
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
>
> Seen here:
> https://app.circleci.com/pipelines/github/driftx/cassandra/1095/workflows/6114e2e3-8dcc-4bb0-b664-ae7d82c3349f/jobs/33405/tests
> {noformat}
> junit.framework.AssertionFailedError: expected:<0> but was:<2>
> at
> org.apache.cassandra.distributed.test.UpgradeSSTablesTest.upgradeSSTablesInterruptsOngoingCompaction(UpgradeSSTablesTest.java:86)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[PR] JAVA-3107: use slow-profile during initialization of DefaultReactiveResultSetIT [cassandra-java-driver]
hhughes opened a new pull request, #1819: URL: https://github.com/apache/cassandra-java-driver/pull/1819 (no comment) -- 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] (CASSANDRASC-83) Require gossip to be enabled for ring and token ranges mapping endpoints
[ https://issues.apache.org/jira/browse/CASSANDRASC-83?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francisco Guerrero updated CASSANDRASC-83: -- Test and Documentation Plan: Added test to ensure the expected response is returned when gossip is disabled for the ring endpoint and the token ranges mapping endpoint. Status: Patch Available (was: In Progress) PR: https://github.com/apache/cassandra-sidecar/pull/77/files > Require gossip to be enabled for ring and token ranges mapping endpoints > > > Key: CASSANDRASC-83 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-83 > Project: Sidecar for Apache Cassandra > Issue Type: Improvement > Components: Rest API >Reporter: Francisco Guerrero >Assignee: Francisco Guerrero >Priority: Normal > Labels: pull-request-available > > The ring and token ranges mapping endpoints leverage JMX to produce the > payload. Ring and token ranges mapping information is derived from gossip > information available to the Cassandra instance. If gossip has been disabled, > the information might provide an inconsistent view of the cluster which is > undesirable. We should instead return a 503 (Service Unavailable) to the > client whenever the client tries to access these endpoints and gossip has > been disabled. -- This message was sent by Atlassian 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-accord) branch trunk updated: Ninja fix for CASSANDRA-18874. Make sure to add clojars repo to accord-core to pick up elle
This is an automated email from the ASF dual-hosted git repository.
dcapwell pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra-accord.git
The following commit(s) were added to refs/heads/trunk by this push:
new 3056d13b Ninja fix for CASSANDRA-18874. Make sure to add clojars repo
to accord-core to pick up elle
3056d13b is described below
commit 3056d13bc8c45a22ec794e0979d02f469cc4e209
Author: David Capwell
AuthorDate: Tue Nov 7 10:56:51 2023 -0800
Ninja fix for CASSANDRA-18874. Make sure to add clojars repo to
accord-core to pick up elle
---
accord-core/build.gradle | 6 ++
1 file changed, 6 insertions(+)
diff --git a/accord-core/build.gradle b/accord-core/build.gradle
index db395aaf..46b29308 100644
--- a/accord-core/build.gradle
+++ b/accord-core/build.gradle
@@ -26,6 +26,12 @@ java {
withSourcesJar()
}
+repositories {
+mavenCentral()
+// needed for clojure dependencies
+maven { url "https://clojars.org/repo; }
+}
+
dependencies {
implementation group: "com.google.guava", name: "guava", version:
"27.0-jre"
implementation group: "net.ju-n.compile-command-annotations", name:
"compile-command-annotations", version: "1.2.0"
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRASC-83) Require gossip to be enabled for ring and token ranges mapping endpoints
[ https://issues.apache.org/jira/browse/CASSANDRASC-83?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CASSANDRASC-83: -- Labels: pull-request-available (was: ) > Require gossip to be enabled for ring and token ranges mapping endpoints > > > Key: CASSANDRASC-83 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-83 > Project: Sidecar for Apache Cassandra > Issue Type: Improvement > Components: Rest API >Reporter: Francisco Guerrero >Assignee: Francisco Guerrero >Priority: Normal > Labels: pull-request-available > > The ring and token ranges mapping endpoints leverage JMX to produce the > payload. Ring and token ranges mapping information is derived from gossip > information available to the Cassandra instance. If gossip has been disabled, > the information might provide an inconsistent view of the cluster which is > undesirable. We should instead return a 503 (Service Unavailable) to the > client whenever the client tries to access these endpoints and gossip has > been disabled. -- This message was sent by Atlassian 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-83) Require gossip to be enabled for ring and token ranges mapping endpoints
[ https://issues.apache.org/jira/browse/CASSANDRASC-83?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francisco Guerrero updated CASSANDRASC-83: -- Change Category: Semantic Complexity: Normal Component/s: Rest API Status: Open (was: Triage Needed) > Require gossip to be enabled for ring and token ranges mapping endpoints > > > Key: CASSANDRASC-83 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-83 > Project: Sidecar for Apache Cassandra > Issue Type: Improvement > Components: Rest API >Reporter: Francisco Guerrero >Assignee: Francisco Guerrero >Priority: Normal > > The ring and token ranges mapping endpoints leverage JMX to produce the > payload. Ring and token ranges mapping information is derived from gossip > information available to the Cassandra instance. If gossip has been disabled, > the information might provide an inconsistent view of the cluster which is > undesirable. We should instead return a 503 (Service Unavailable) to the > client whenever the client tries to access these endpoints and gossip has > been disabled. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRASC-83) Require gossip to be enabled for ring and token ranges mapping endpoints
Francisco Guerrero created CASSANDRASC-83: - Summary: Require gossip to be enabled for ring and token ranges mapping endpoints Key: CASSANDRASC-83 URL: https://issues.apache.org/jira/browse/CASSANDRASC-83 Project: Sidecar for Apache Cassandra Issue Type: Improvement Reporter: Francisco Guerrero Assignee: Francisco Guerrero The ring and token ranges mapping endpoints leverage JMX to produce the payload. Ring and token ranges mapping information is derived from gossip information available to the Cassandra instance. If gossip has been disabled, the information might provide an inconsistent view of the cluster which is undesirable. We should instead return a 503 (Service Unavailable) to the client whenever the client tries to access these endpoints and gossip has been disabled. -- This message was sent by Atlassian 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-18874) Add Jepsen's Elle to Accord and Paxos validation
[ https://issues.apache.org/jira/browse/CASSANDRA-18874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-18874: -- Status: Ready to Commit (was: Review In Progress) got +1 from [~maedhroz] in GH > Add Jepsen's Elle to Accord and Paxos validation > > > Key: CASSANDRA-18874 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18874 > Project: Cassandra > Issue Type: Improvement > Components: Accord, Feature/Lightweight Transactions >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Labels: pull-request-available > Fix For: 5.x > > > Paxos and Accord both use a custom validator to make sure we offer Strict > Serializability, but to increase confidence we should use external validators > as well, such as Jepson’s Elle. -- This message was sent by Atlassian 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-18874) Add Jepsen's Elle to Accord and Paxos validation
[ https://issues.apache.org/jira/browse/CASSANDRA-18874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-18874: -- Fix Version/s: 5.1 (was: 5.x) Source Control Link: https://github.com/apache/cassandra-accord/commit/11ced982a6e78810268677b4b6aeed90bc06e25b Resolution: Fixed Status: Resolved (was: Ready to Commit) > Add Jepsen's Elle to Accord and Paxos validation > > > Key: CASSANDRA-18874 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18874 > Project: Cassandra > Issue Type: Improvement > Components: Accord, Feature/Lightweight Transactions >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Labels: pull-request-available > Fix For: 5.1 > > > Paxos and Accord both use a custom validator to make sure we offer Strict > Serializability, but to increase confidence we should use external validators > as well, such as Jepson’s Elle. -- This message was sent by Atlassian 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-accord) branch trunk updated: Add Jepsen's Elle to Accord and Paxos validation (#67)
This is an automated email from the ASF dual-hosted git repository.
dcapwell pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra-accord.git
The following commit(s) were added to refs/heads/trunk by this push:
new 11ced982 Add Jepsen's Elle to Accord and Paxos validation (#67)
11ced982 is described below
commit 11ced982a6e78810268677b4b6aeed90bc06e25b
Author: dcapwell
AuthorDate: Tue Nov 7 10:15:19 2023 -0800
Add Jepsen's Elle to Accord and Paxos validation (#67)
patch by David Capwell, Jaroslaw Kijanowski; reviewed by Caleb Rackliffe
for CASSANDRA-18874
---
accord-core/build.gradle | 10 +
.../src/test/java/accord/burn/BurnTest.java| 42 ++-
.../test/java/accord/verify/CompositeVerifier.java | 81 +
.../src/test/java/accord/verify/ElleVerifier.java | 381 +
.../test/java/accord/verify/ElleVerifierTest.java | 138
.../verify/StrictSerializabilityVerifier.java | 29 +-
.../src/test/java/accord/verify/Verifier.java | 36 ++
7 files changed, 701 insertions(+), 16 deletions(-)
diff --git a/accord-core/build.gradle b/accord-core/build.gradle
index df6203b9..db395aaf 100644
--- a/accord-core/build.gradle
+++ b/accord-core/build.gradle
@@ -36,6 +36,16 @@ dependencies {
implementation 'org.agrona:agrona:1.17.1'
testImplementation group: 'org.assertj', name: 'assertj-core', version:
'3.24.2'
+testImplementation 'org.clojure:clojure:1.11.1'
+testImplementation 'elle:elle:0.1.7'
+// for some reason this isn't pulled in properly? Have to be explicit
+testImplementation('spootnik:unilog:0.7.31') {
+exclude group: 'ch.qos.logback'
+
+exclude group: 'org.slf4j', module: 'slf4j-api'
+exclude group: 'org.slf4j', module: 'log4j-over-slf4j'
+exclude group: 'org.slf4j', module: 'jcl-over-slf4j'
+}
}
task burn(type: JavaExec) {
diff --git a/accord-core/src/test/java/accord/burn/BurnTest.java
b/accord-core/src/test/java/accord/burn/BurnTest.java
index 5fa84f75..b147efb7 100644
--- a/accord-core/src/test/java/accord/burn/BurnTest.java
+++ b/accord-core/src/test/java/accord/burn/BurnTest.java
@@ -42,6 +42,10 @@ import java.util.function.Supplier;
import accord.burn.random.FrequentLargeRange;
import accord.impl.MessageListener;
+import accord.verify.CompositeVerifier;
+import accord.verify.ElleVerifier;
+import accord.verify.StrictSerializabilityVerifier;
+import accord.verify.Verifier;
import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.Timeout;
import org.slf4j.Logger;
@@ -73,7 +77,6 @@ import accord.primitives.Txn;
import accord.utils.DefaultRandom;
import accord.utils.RandomSource;
import accord.utils.async.AsyncExecutor;
-import accord.verify.StrictSerializabilityVerifier;
import static accord.impl.IntHashKey.forHash;
import static accord.utils.Utils.toArray;
@@ -212,8 +215,9 @@ public class BurnTest
.asLongSupplier(forked);
};
-StrictSerializabilityVerifier strictSerializable = new
StrictSerializabilityVerifier(keyCount);
+Verifier verifier = createVerifier(keyCount);
SimulatedDelayedExecutorService globalExecutor = new
SimulatedDelayedExecutorService(queue, agent);
+
Function executor = ignore ->
globalExecutor;
MessageListener listener = MessageListener.get();
@@ -280,23 +284,22 @@ public class BurnTest
}
acks.incrementAndGet();
-strictSerializable.begin();
-
-for (int i = 0 ; i < reply.read.length ; ++i)
+try (Verifier.Checker check = verifier.witness(start, end))
{
-Key key = reply.responseKeys.get(i);
-int k = key(key);
+for (int i = 0 ; i < reply.read.length ; ++i)
+{
+Key key = reply.responseKeys.get(i);
+int k = key(key);
-int[] read = reply.read[i];
-int write = reply.update == null ? -1 :
reply.update.getOrDefault(key, -1);
+int[] read = reply.read[i];
+int write = reply.update == null ? -1 :
reply.update.getOrDefault(key, -1);
-if (read != null)
-strictSerializable.witnessRead(k, read);
-if (write >= 0)
-strictSerializable.witnessWrite(k, write);
+if (read != null)
+check.read(k, read);
+if (write >= 0)
+check.write(k, write);
+}
}
-
-strictSerializable.apply(start, end);
}
catch (Throwable t)
{
@@ -313,6 +316,7 @@ public class BurnTest
[jira] [Updated] (CASSANDRA-19007) Queries with multi-column replica-side filtering can miss rows
[
https://issues.apache.org/jira/browse/CASSANDRA-19007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-19007:
Reviewers: Caleb Rackliffe
> Queries with multi-column replica-side filtering can miss rows
> --
>
> Key: CASSANDRA-19007
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19007
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination
>Reporter: Andres de la Peña
>Priority: Normal
>
> {{SELECT}} queries with multi-column replica-side filtering can miss rows if
> the filtered columns are spread across out-of-sync replicas. This dtest
> reproduces the issue:
> {code:java}
> @Test
> public void testMultiColumnReplicaSideFiltering() throws IOException
> {
> try (Cluster cluster = init(Cluster.build().withNodes(2).start()))
> {
> cluster.schemaChange(withKeyspace("CREATE TABLE %s.t (k int PRIMARY
> KEY, a int, b int)"));
> // insert a split row
> cluster.get(1).executeInternal(withKeyspace("INSERT INTO %s.t(k, a)
> VALUES (0, 1)"));
> cluster.get(2).executeInternal(withKeyspace("INSERT INTO %s.t(k, b)
> VALUES (0, 2)"));
> String select = withKeyspace("SELECT * FROM %s.t WHERE a = 1 AND b =
> 2 ALLOW FILTERING");
> Object[][] initialRows = cluster.coordinator(1).execute(select, ALL);
> assertRows(initialRows, row(0, 1, 2)); // not found!!
> }
> }
> {code}
> This edge case affects queries using {{ALLOW FILTERING}} or any index
> implementation.
> It affects all branches since multi-column replica-side filtering queries
> were introduced, long before 3.0.
> The protection mechanism added by CASSANDRA-8272/8273 won't deal with this
> case, since it only solves single-column conflicts where stale rows could
> resurrect. This bug however doesn't resurrect data, it can only miss rows
> while the replicas are out-of-sync.
--
This message was sent by Atlassian 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-19007) Queries with multi-column replica-side filtering can miss rows
[
https://issues.apache.org/jira/browse/CASSANDRA-19007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17783737#comment-17783737
]
Caleb Rackliffe commented on CASSANDRA-19007:
-
[~adelapena] Let me know if you need any help w/ this one. Marking myself a
reviewer for now...
> Queries with multi-column replica-side filtering can miss rows
> --
>
> Key: CASSANDRA-19007
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19007
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination
>Reporter: Andres de la Peña
>Priority: Normal
>
> {{SELECT}} queries with multi-column replica-side filtering can miss rows if
> the filtered columns are spread across out-of-sync replicas. This dtest
> reproduces the issue:
> {code:java}
> @Test
> public void testMultiColumnReplicaSideFiltering() throws IOException
> {
> try (Cluster cluster = init(Cluster.build().withNodes(2).start()))
> {
> cluster.schemaChange(withKeyspace("CREATE TABLE %s.t (k int PRIMARY
> KEY, a int, b int)"));
> // insert a split row
> cluster.get(1).executeInternal(withKeyspace("INSERT INTO %s.t(k, a)
> VALUES (0, 1)"));
> cluster.get(2).executeInternal(withKeyspace("INSERT INTO %s.t(k, b)
> VALUES (0, 2)"));
> String select = withKeyspace("SELECT * FROM %s.t WHERE a = 1 AND b =
> 2 ALLOW FILTERING");
> Object[][] initialRows = cluster.coordinator(1).execute(select, ALL);
> assertRows(initialRows, row(0, 1, 2)); // not found!!
> }
> }
> {code}
> This edge case affects queries using {{ALLOW FILTERING}} or any index
> implementation.
> It affects all branches since multi-column replica-side filtering queries
> were introduced, long before 3.0.
> The protection mechanism added by CASSANDRA-8272/8273 won't deal with this
> case, since it only solves single-column conflicts where stale rows could
> resurrect. This bug however doesn't resurrect data, it can only miss rows
> while the replicas are out-of-sync.
--
This message was sent by Atlassian 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-19007) Queries with multi-column replica-side filtering can miss rows
[
https://issues.apache.org/jira/browse/CASSANDRA-19007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-19007:
--
Description:
{{SELECT}} queries with multi-column replica-side filtering can miss rows if
the filtered columns are spread across out-of-sync replicas. This dtest
reproduces the issue:
{code:java}
@Test
public void testMultiColumnReplicaSideFiltering() throws IOException
{
try (Cluster cluster = init(Cluster.build().withNodes(2).start()))
{
cluster.schemaChange(withKeyspace("CREATE TABLE %s.t (k int PRIMARY
KEY, a int, b int)"));
// insert a split row
cluster.get(1).executeInternal(withKeyspace("INSERT INTO %s.t(k, a)
VALUES (0, 1)"));
cluster.get(2).executeInternal(withKeyspace("INSERT INTO %s.t(k, b)
VALUES (0, 2)"));
String select = withKeyspace("SELECT * FROM %s.t WHERE a = 1 AND b = 2
ALLOW FILTERING");
Object[][] initialRows = cluster.coordinator(1).execute(select, ALL);
assertRows(initialRows, row(0, 1, 2)); // not found!!
}
}
{code}
This edge case affects queries using {{ALLOW FILTERING}} or any index
implementation.
It affects all branches since multi-column replica-side filtering queries were
introduced, long before 3.0.
The protection mechanism added by CASSANDRA-8272/8273 won't deal with this
case, since it only solves single-column conflicts where stale rows could
resurrect. This bug however doesn't resurrect data, it can only miss rows while
the replicas are out-of-sync.
was:
{{SELECT}} queries with multi-column replica-side filtering can miss rows if
the filtered columns are spread across out-of-sync replicas. This dtest
reproduces the issue:
{code:java}
@Test
public void testMultiColumnReplicaSideFiltering() throws IOException
{
try (Cluster cluster = init(Cluster.build().withNodes(2).start()))
{
cluster.schemaChange(withKeyspace("CREATE TABLE %s.t (k int PRIMARY
KEY, a int, b int)"));
// insert a split row
cluster.get(1).executeInternal(withKeyspace("INSERT INTO %s.t(k, a)
VALUES (0, 1)"));
cluster.get(2).executeInternal(withKeyspace("INSERT INTO %s.t(k, b)
VALUES (0, 2)"));
String select = withKeyspace("SELECT * FROM %s.t WHERE a = 1 AND b = 2
ALLOW FILTERING");
Object[][] initialRows = cluster.coordinator(1).execute(select, ALL);
assertRows(initialRows, row(0, 1, 2)); // not found!!
}
}
{code}
This edge case affects queries using {{ALLOW FILTERING}} or any index
implementation.
It affects all branches since multi-column replica-side filtering queries were
introduced, long before 3.0.
The protection mechanism added by CASSANDRA-8272/8273 won't deal with this
case, since it only solves single-column conflicts.
> Queries with multi-column replica-side filtering can miss rows
> --
>
> Key: CASSANDRA-19007
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19007
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination
>Reporter: Andres de la Peña
>Priority: Normal
>
> {{SELECT}} queries with multi-column replica-side filtering can miss rows if
> the filtered columns are spread across out-of-sync replicas. This dtest
> reproduces the issue:
> {code:java}
> @Test
> public void testMultiColumnReplicaSideFiltering() throws IOException
> {
> try (Cluster cluster = init(Cluster.build().withNodes(2).start()))
> {
> cluster.schemaChange(withKeyspace("CREATE TABLE %s.t (k int PRIMARY
> KEY, a int, b int)"));
> // insert a split row
> cluster.get(1).executeInternal(withKeyspace("INSERT INTO %s.t(k, a)
> VALUES (0, 1)"));
> cluster.get(2).executeInternal(withKeyspace("INSERT INTO %s.t(k, b)
> VALUES (0, 2)"));
> String select = withKeyspace("SELECT * FROM %s.t WHERE a = 1 AND b =
> 2 ALLOW FILTERING");
> Object[][] initialRows = cluster.coordinator(1).execute(select, ALL);
> assertRows(initialRows, row(0, 1, 2)); // not found!!
> }
> }
> {code}
> This edge case affects queries using {{ALLOW FILTERING}} or any index
> implementation.
> It affects all branches since multi-column replica-side filtering queries
> were introduced, long before 3.0.
> The protection mechanism added by CASSANDRA-8272/8273 won't deal with this
> case, since it only solves single-column conflicts where stale rows could
> resurrect. This bug however doesn't resurrect data, it can only miss rows
> while the replicas are out-of-sync.
--
This message was sent by Atlassian 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-19003) Get Sidecar port through CassandraContext for more flexibility
[ https://issues.apache.org/jira/browse/CASSANDRA-19003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17783718#comment-17783718 ] Francisco Guerrero commented on CASSANDRA-19003: +1, thanks for the patch! > Get Sidecar port through CassandraContext for more flexibility > --- > > Key: CASSANDRA-19003 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19003 > Project: Cassandra > Issue Type: Task > Components: Analytics Library >Reporter: Saranya Krishnakumar >Assignee: Saranya Krishnakumar >Priority: Normal > Time Spent: 10m > Remaining Estimate: 0h > > We get sidecar port from `BulkSparkConf` but it will be better if we get it > from `CassandraContext` provides more flexibility -- This message was sent by Atlassian 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-19007) Queries with multi-column replica-side filtering can miss rows
[
https://issues.apache.org/jira/browse/CASSANDRA-19007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-19007:
--
Description:
{{SELECT}} queries with multi-column replica-side filtering can miss rows if
the filtered columns are spread across out-of-sync replicas. This dtest
reproduces the issue:
{code:java}
@Test
public void testMultiColumnReplicaSideFiltering() throws IOException
{
try (Cluster cluster = init(Cluster.build().withNodes(2).start()))
{
cluster.schemaChange(withKeyspace("CREATE TABLE %s.t (k int PRIMARY
KEY, a int, b int)"));
// insert a split row
cluster.get(1).executeInternal(withKeyspace("INSERT INTO %s.t(k, a)
VALUES (0, 1)"));
cluster.get(2).executeInternal(withKeyspace("INSERT INTO %s.t(k, b)
VALUES (0, 2)"));
String select = withKeyspace("SELECT * FROM %s.t WHERE a = 1 AND b = 2
ALLOW FILTERING");
Object[][] initialRows = cluster.coordinator(1).execute(select, ALL);
assertRows(initialRows, row(0, 1, 2)); // not found!!
}
}
{code}
This edge case affects queries using {{ALLOW FILTERING}} or any index
implementation.
It affects all branches since multi-column replica-side filtering queries were
introduced, long before 3.0.
The protection mechanism added by CASSANDRA-8272/8273 won't deal with this
case, since it only solves single-column conflicts.
was:
{{SELECT}} queries with multi-column replica-side filtering can miss rows if
the filtered columns are spread across out-of-sync replicas. This dtest
reproduces the issue:
{code:java}
@Test
public void testMultiColumnReplicaSideFiltering() throws IOException
{
try (Cluster cluster = init(Cluster.build().withNodes(2).start()))
{
cluster.schemaChange(withKeyspace("CREATE TABLE %s.t (k int PRIMARY
KEY, a int, b int)"));
// insert a split row
cluster.get(1).executeInternal(withKeyspace("INSERT INTO %s.t(k, a)
VALUES (0, 1)"));
cluster.get(2).executeInternal(withKeyspace("INSERT INTO %s.t(k, b)
VALUES (0, 2)"));
String select = withKeyspace("SELECT * FROM %s.t WHERE a = 1 AND b = 2
ALLOW FILTERING");
Object[][] initialRows = cluster.coordinator(1).execute(select, ALL);
assertRows(initialRows, row(0, 1, 2)); // not found!!
}
}
{code}
This edge case affects queries using {{ALLOW FILTERING}} or any index
implementation.
The protection mechanism added by CASSANDRA-8272/8273 won't deal with this
case, since it only solves single-column conflicts.
> Queries with multi-column replica-side filtering can miss rows
> --
>
> Key: CASSANDRA-19007
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19007
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination
>Reporter: Andres de la Peña
>Priority: Normal
>
> {{SELECT}} queries with multi-column replica-side filtering can miss rows if
> the filtered columns are spread across out-of-sync replicas. This dtest
> reproduces the issue:
> {code:java}
> @Test
> public void testMultiColumnReplicaSideFiltering() throws IOException
> {
> try (Cluster cluster = init(Cluster.build().withNodes(2).start()))
> {
> cluster.schemaChange(withKeyspace("CREATE TABLE %s.t (k int PRIMARY
> KEY, a int, b int)"));
> // insert a split row
> cluster.get(1).executeInternal(withKeyspace("INSERT INTO %s.t(k, a)
> VALUES (0, 1)"));
> cluster.get(2).executeInternal(withKeyspace("INSERT INTO %s.t(k, b)
> VALUES (0, 2)"));
> String select = withKeyspace("SELECT * FROM %s.t WHERE a = 1 AND b =
> 2 ALLOW FILTERING");
> Object[][] initialRows = cluster.coordinator(1).execute(select, ALL);
> assertRows(initialRows, row(0, 1, 2)); // not found!!
> }
> }
> {code}
> This edge case affects queries using {{ALLOW FILTERING}} or any index
> implementation.
> It affects all branches since multi-column replica-side filtering queries
> were introduced, long before 3.0.
> The protection mechanism added by CASSANDRA-8272/8273 won't deal with this
> case, since it only solves single-column conflicts.
--
This message was sent by Atlassian 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-19007) Queries with multi-column replica-side filtering can miss rows
[
https://issues.apache.org/jira/browse/CASSANDRA-19007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-19007:
--
Bug Category: Parent values: Correctness(12982)Level 1 values:
Consistency(12989)
Discovered By: Code Inspection
Since Version: 0.3
> Queries with multi-column replica-side filtering can miss rows
> --
>
> Key: CASSANDRA-19007
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19007
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination
>Reporter: Andres de la Peña
>Priority: Normal
>
> {{SELECT}} queries with multi-column replica-side filtering can miss rows if
> the filtered columns are spread across out-of-sync replicas. This dtest
> reproduces the issue:
> {code:java}
> @Test
> public void testMultiColumnReplicaSideFiltering() throws IOException
> {
> try (Cluster cluster = init(Cluster.build().withNodes(2).start()))
> {
> cluster.schemaChange(withKeyspace("CREATE TABLE %s.t (k int PRIMARY
> KEY, a int, b int)"));
> // insert a split row
> cluster.get(1).executeInternal(withKeyspace("INSERT INTO %s.t(k, a)
> VALUES (0, 1)"));
> cluster.get(2).executeInternal(withKeyspace("INSERT INTO %s.t(k, b)
> VALUES (0, 2)"));
> String select = withKeyspace("SELECT * FROM %s.t WHERE a = 1 AND b =
> 2 ALLOW FILTERING");
> Object[][] initialRows = cluster.coordinator(1).execute(select, ALL);
> assertRows(initialRows, row(0, 1, 2)); // not found!!
> }
> }
> {code}
> This edge case affects queries using {{ALLOW FILTERING}} or any index
> implementation.
> The protection mechanism added by CASSANDRA-8272/8273 won't deal with this
> case, since it only solves single-column conflicts.
--
This message was sent by Atlassian 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-19007) Queries with multi-column replica-side filtering can miss rows
[
https://issues.apache.org/jira/browse/CASSANDRA-19007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-19007:
--
Description:
{{SELECT}} queries with multi-column replica-side filtering can miss rows if
the filtered columns are spread across out-of-sync replicas. This dtest
reproduces the issue:
{code:java}
@Test
public void testMultiColumnReplicaSideFiltering() throws IOException
{
try (Cluster cluster = init(Cluster.build().withNodes(2).start()))
{
cluster.schemaChange(withKeyspace("CREATE TABLE %s.t (k int PRIMARY
KEY, a int, b int)"));
// insert a split row
cluster.get(1).executeInternal(withKeyspace("INSERT INTO %s.t(k, a)
VALUES (0, 1)"));
cluster.get(2).executeInternal(withKeyspace("INSERT INTO %s.t(k, b)
VALUES (0, 2)"));
String select = withKeyspace("SELECT * FROM %s.t WHERE a = 1 AND b = 2
ALLOW FILTERING");
Object[][] initialRows = cluster.coordinator(1).execute(select, ALL);
assertRows(initialRows, row(0, 1, 2)); // not found!!
}
}
{code}
This edge case affects queries using {{ALLOW FILTERING}} or any index
implementation.
The protection mechanism added by CASSANDRA-8272/8273 won't deal with this
case, since it only solves single-column conflicts.
was:
{{SELECT}} queries with multi-column replica-side filtering can miss rows if
the filtered columns are spread across out-of-sync replicas. This dtest
reproduces the issue:
{code:java}
@Test
public void testMultiColumnReplicaSideFiltering() throws IOException
{
try (Cluster cluster = init(Cluster.build().withNodes(2).start()))
{
cluster.schemaChange(withKeyspace("CREATE TABLE %s.t (k int PRIMARY
KEY, a int, b int)"));
// insert a split row
cluster.get(1).executeInternal(withKeyspace("INSERT INTO %s.t(k, a)
VALUES (0, 1)"));
cluster.get(2).executeInternal(withKeyspace("INSERT INTO %s.t(k, b)
VALUES (0, 2)"));
String select = withKeyspace("SELECT * FROM %s.t WHERE a = 1 AND b = 2
ALLOW FILTERING");
Object[][] initialRows = cluster.coordinator(1).execute(select, ALL);
assertRows(initialRows, row(0, 1, 2)); // not found!!
}
}
{code}
This edge case affects queries using either {{ALLOW FILTERING }}or any index
implementation.
The protection mechanism added by CASSANDRA-8272/8273 won't deal with this
case, since it only solves single-column conflicts.
> Queries with multi-column replica-side filtering can miss rows
> --
>
> Key: CASSANDRA-19007
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19007
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination
>Reporter: Andres de la Peña
>Priority: Normal
>
> {{SELECT}} queries with multi-column replica-side filtering can miss rows if
> the filtered columns are spread across out-of-sync replicas. This dtest
> reproduces the issue:
> {code:java}
> @Test
> public void testMultiColumnReplicaSideFiltering() throws IOException
> {
> try (Cluster cluster = init(Cluster.build().withNodes(2).start()))
> {
> cluster.schemaChange(withKeyspace("CREATE TABLE %s.t (k int PRIMARY
> KEY, a int, b int)"));
> // insert a split row
> cluster.get(1).executeInternal(withKeyspace("INSERT INTO %s.t(k, a)
> VALUES (0, 1)"));
> cluster.get(2).executeInternal(withKeyspace("INSERT INTO %s.t(k, b)
> VALUES (0, 2)"));
> String select = withKeyspace("SELECT * FROM %s.t WHERE a = 1 AND b =
> 2 ALLOW FILTERING");
> Object[][] initialRows = cluster.coordinator(1).execute(select, ALL);
> assertRows(initialRows, row(0, 1, 2)); // not found!!
> }
> }
> {code}
> This edge case affects queries using {{ALLOW FILTERING}} or any index
> implementation.
> The protection mechanism added by CASSANDRA-8272/8273 won't deal with this
> case, since it only solves single-column conflicts.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-19007) Queries with multi-column replica-side filtering can miss rows
Andres de la Peña created CASSANDRA-19007:
-
Summary: Queries with multi-column replica-side filtering can miss
rows
Key: CASSANDRA-19007
URL: https://issues.apache.org/jira/browse/CASSANDRA-19007
Project: Cassandra
Issue Type: Bug
Components: Consistency/Coordination
Reporter: Andres de la Peña
{{SELECT}} queries with multi-column replica-side filtering can miss rows if
the filtered columns are spread across out-of-sync replicas. This dtest
reproduces the issue:
{code:java}
@Test
public void testMultiColumnReplicaSideFiltering() throws IOException
{
try (Cluster cluster = init(Cluster.build().withNodes(2).start()))
{
cluster.schemaChange(withKeyspace("CREATE TABLE %s.t (k int PRIMARY
KEY, a int, b int)"));
// insert a split row
cluster.get(1).executeInternal(withKeyspace("INSERT INTO %s.t(k, a)
VALUES (0, 1)"));
cluster.get(2).executeInternal(withKeyspace("INSERT INTO %s.t(k, b)
VALUES (0, 2)"));
String select = withKeyspace("SELECT * FROM %s.t WHERE a = 1 AND b = 2
ALLOW FILTERING");
Object[][] initialRows = cluster.coordinator(1).execute(select, ALL);
assertRows(initialRows, row(0, 1, 2)); // not found!!
}
}
{code}
This edge case affects queries using either {{ALLOW FILTERING }}or any index
implementation.
The protection mechanism added by CASSANDRA-8272/8273 won't deal with this
case, since it only solves single-column conflicts.
--
This message was sent by Atlassian 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-19003) Get Sidecar port through CassandraContext for more flexibility
[ https://issues.apache.org/jira/browse/CASSANDRA-19003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Saranya Krishnakumar updated CASSANDRA-19003: - Test and Documentation Plan: Unit test Status: Patch Available (was: In Progress) [https://github.com/apache/cassandra-analytics/pull/18] > Get Sidecar port through CassandraContext for more flexibility > --- > > Key: CASSANDRA-19003 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19003 > Project: Cassandra > Issue Type: Task > Components: Analytics Library >Reporter: Saranya Krishnakumar >Assignee: Saranya Krishnakumar >Priority: Normal > Time Spent: 10m > Remaining Estimate: 0h > > We get sidecar port from `BulkSparkConf` but it will be better if we get it > from `CassandraContext` provides more flexibility -- This message was sent by Atlassian 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-18932) Harry-found CorruptSSTableException / RT Closer issue when reading entire partition
[
https://issues.apache.org/jira/browse/CASSANDRA-18932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17783706#comment-17783706
]
Maxim Muzafarov commented on CASSANDRA-18932:
-
[~jlewandowski] as agreed upon in private messages I've assigned it to you.
> Harry-found CorruptSSTableException / RT Closer issue when reading entire
> partition
> ---
>
> Key: CASSANDRA-18932
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18932
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
>Reporter: Alex Petrov
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 5.0-beta, 5.0.x, 5.x
>
> Attachments: node1_.zip, operation.log.zip, screenshot-1.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> While testing some new machinery for Harry, I have encountered a new RT
> closer / SSTable Corruption issue. I have grounds to believe this was
> introduced during the last year.
> Issue seems to happen because of intricate interleaving of flushes with
> writes and deletes.
> {code:java}
> ERROR [ReadStage-2] 2023-10-16 18:47:06,696 JVMStabilityInspector.java:76 -
> Exception in thread Thread[ReadStage-2,5,SharedPool]
> org.apache.cassandra.io.sstable.CorruptSSTableException: Corrupted:
> RandomAccessReader:BufferManagingRebufferer.Aligned:CompressedChunkReader.Mmap(/Users/ifesdjeen/foss/java/apache-cassandra-4.0/data/data1/harry/table_1-07c35a606c0a11eeae7a4f6ca489eb0c/nc-5-big-Data.db
> - LZ4Compressor, chunk length 16384, data length 232569)
> at
> org.apache.cassandra.io.sstable.AbstractSSTableIterator$AbstractReader.hasNext(AbstractSSTableIterator.java:381)
> at
> org.apache.cassandra.io.sstable.AbstractSSTableIterator.hasNext(AbstractSSTableIterator.java:242)
> at
> org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.computeNext(LazilyInitializedUnfilteredRowIterator.java:95)
> at
> org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.computeNext(LazilyInitializedUnfilteredRowIterator.java:32)
> at
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47)
> at
> org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:133)
> at
> org.apache.cassandra.utils.MergeIterator$Candidate.advance(MergeIterator.java:376)
> at
> org.apache.cassandra.utils.MergeIterator$ManyToOne.advance(MergeIterator.java:188)
> at
> org.apache.cassandra.utils.MergeIterator$ManyToOne.computeNext(MergeIterator.java:157)
> at
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47)
> at
> org.apache.cassandra.db.rows.UnfilteredRowIterators$UnfilteredRowMergeIterator.computeNext(UnfilteredRowIterators.java:534)
> at
> org.apache.cassandra.db.rows.UnfilteredRowIterators$UnfilteredRowMergeIterator.computeNext(UnfilteredRowIterators.java:402)
> at
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47)
> at
> org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.computeNext(LazilyInitializedUnfilteredRowIterator.java:95)
> at
> org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.computeNext(LazilyInitializedUnfilteredRowIterator.java:32)
> at
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47)
> at
> org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:133)
> at
> org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:133)
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:151)
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:101)
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:86)
> at
> org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$Serializer.serialize(UnfilteredPartitionIterators.java:343)
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.build(ReadResponse.java:201)
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:186)
> at
> org.apache.cassandra.db.ReadResponse.createDataResponse(ReadResponse.java:48)
> at
> org.apache.cassandra.db.ReadCommand.createResponse(ReadCommand.java:346)
> at
> org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:2186)
> at
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2581)
> at
>
[jira] [Assigned] (CASSANDRA-18932) Harry-found CorruptSSTableException / RT Closer issue when reading entire partition
[
https://issues.apache.org/jira/browse/CASSANDRA-18932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov reassigned CASSANDRA-18932:
---
Assignee: Jacek Lewandowski (was: Maxim Muzafarov)
> Harry-found CorruptSSTableException / RT Closer issue when reading entire
> partition
> ---
>
> Key: CASSANDRA-18932
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18932
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
>Reporter: Alex Petrov
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 5.0-beta, 5.0.x, 5.x
>
> Attachments: node1_.zip, operation.log.zip, screenshot-1.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> While testing some new machinery for Harry, I have encountered a new RT
> closer / SSTable Corruption issue. I have grounds to believe this was
> introduced during the last year.
> Issue seems to happen because of intricate interleaving of flushes with
> writes and deletes.
> {code:java}
> ERROR [ReadStage-2] 2023-10-16 18:47:06,696 JVMStabilityInspector.java:76 -
> Exception in thread Thread[ReadStage-2,5,SharedPool]
> org.apache.cassandra.io.sstable.CorruptSSTableException: Corrupted:
> RandomAccessReader:BufferManagingRebufferer.Aligned:CompressedChunkReader.Mmap(/Users/ifesdjeen/foss/java/apache-cassandra-4.0/data/data1/harry/table_1-07c35a606c0a11eeae7a4f6ca489eb0c/nc-5-big-Data.db
> - LZ4Compressor, chunk length 16384, data length 232569)
> at
> org.apache.cassandra.io.sstable.AbstractSSTableIterator$AbstractReader.hasNext(AbstractSSTableIterator.java:381)
> at
> org.apache.cassandra.io.sstable.AbstractSSTableIterator.hasNext(AbstractSSTableIterator.java:242)
> at
> org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.computeNext(LazilyInitializedUnfilteredRowIterator.java:95)
> at
> org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.computeNext(LazilyInitializedUnfilteredRowIterator.java:32)
> at
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47)
> at
> org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:133)
> at
> org.apache.cassandra.utils.MergeIterator$Candidate.advance(MergeIterator.java:376)
> at
> org.apache.cassandra.utils.MergeIterator$ManyToOne.advance(MergeIterator.java:188)
> at
> org.apache.cassandra.utils.MergeIterator$ManyToOne.computeNext(MergeIterator.java:157)
> at
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47)
> at
> org.apache.cassandra.db.rows.UnfilteredRowIterators$UnfilteredRowMergeIterator.computeNext(UnfilteredRowIterators.java:534)
> at
> org.apache.cassandra.db.rows.UnfilteredRowIterators$UnfilteredRowMergeIterator.computeNext(UnfilteredRowIterators.java:402)
> at
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47)
> at
> org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.computeNext(LazilyInitializedUnfilteredRowIterator.java:95)
> at
> org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.computeNext(LazilyInitializedUnfilteredRowIterator.java:32)
> at
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47)
> at
> org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:133)
> at
> org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:133)
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:151)
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:101)
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:86)
> at
> org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$Serializer.serialize(UnfilteredPartitionIterators.java:343)
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.build(ReadResponse.java:201)
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:186)
> at
> org.apache.cassandra.db.ReadResponse.createDataResponse(ReadResponse.java:48)
> at
> org.apache.cassandra.db.ReadCommand.createResponse(ReadCommand.java:346)
> at
> org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:2186)
> at
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2581)
> at
> org.apache.cassandra.concurrent.ExecutionFailure$2.run(ExecutionFailure.java:163)
> at
[jira] [Updated] (CASSANDRA-19003) Get Sidecar port through CassandraContext for more flexibility
[ https://issues.apache.org/jira/browse/CASSANDRA-19003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francisco Guerrero updated CASSANDRA-19003: --- Reviewers: Dinesh Joshi, Francisco Guerrero, Josh McKenzie (was: Dinesh Joshi, Josh McKenzie) > Get Sidecar port through CassandraContext for more flexibility > --- > > Key: CASSANDRA-19003 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19003 > Project: Cassandra > Issue Type: Task > Components: Analytics Library >Reporter: Saranya Krishnakumar >Assignee: Saranya Krishnakumar >Priority: Normal > > We get sidecar port from `BulkSparkConf` but it will be better if we get it > from `CassandraContext` provides more flexibility -- This message was sent by Atlassian 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-19003 Get sidecar port through cassandra context [cassandra-analytics]
frankgh commented on code in PR #18: URL: https://github.com/apache/cassandra-analytics/pull/18#discussion_r1385266670 ## cassandra-analytics-core/src/main/java/org/apache/cassandra/spark/bulkwriter/CassandraContext.java: ## @@ -96,6 +96,11 @@ public SidecarClient getSidecarClient() return sidecarClient; } +public int getSidecarPort() Review Comment: NIT: ```suggestion public int sidecarPort() ``` -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18992) Exclude jna transitive dependecy from the ohc library
[
https://issues.apache.org/jira/browse/CASSANDRA-18992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17783701#comment-17783701
]
Maxim Muzafarov commented on CASSANDRA-18992:
-
{quote}
https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra?branch=18992-review-5.0
{quote}
The test results look good as well. As for the asm dependency, it only appears
in the 0.7.5 release and it doesn't exist in 0.5.1
https://github.com/snazy/ohc/blob/develop/pom.xml#L162
https://github.com/snazy/ohc/blob/0.5.1/pom.xml
> Exclude jna transitive dependecy from the ohc library
> -
>
> Key: CASSANDRA-18992
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18992
> Project: Cassandra
> Issue Type: Task
> Components: Dependencies
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Normal
> Fix For: 5.0-beta, 5.0.x, 5.x
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The concern is related to the JNA dependency on the ohc library. We are now
> using version 0.5.1 of the ohc library in Cassandra. The ohc 0.5.1 depends on
> version 4.1.0 of the net.java.dev.jna . For the Cassandra project, JNA has
> been updated since the 4.0 release version up to JNA 5.6.0 in CASSANDRA-16212
> to support running nodes on the arm64 architecture, so I assume that JNA
> 4.1.0 is no longer in Casssandra's classpath.
> The common practice in the Cassandra project is to exclude these kinds of
> transitive dependencies when they are explicitly mentioned in the main parent
> pom, since Ant may resolve them incorrectly. See comment:
> https://issues.apache.org/jira/browse/CASSANDRA-14667?focusedCommentId=17765091=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17765091
--
This message was sent by Atlassian 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-18992) Exclude jna transitive dependecy from the ohc library
[
https://issues.apache.org/jira/browse/CASSANDRA-18992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17783695#comment-17783695
]
Maxim Muzafarov commented on CASSANDRA-18992:
-
So I can't get a clean run on the 0.5.1 branch, because the following tests
fail (this failure is related to release/0.5.1 branch):
https://github.com/Mmuzaf/ohc/actions/runs/6787087412/job/18449112785
{code}
Failed tests:
ChunkedCacheImplTest.testHotKeyBufferIterator:573 expected [true] but found
[false]
ChunkedCacheImplTest.testHotKeyIterator:417 expected [true] but found [false]
ChunkedFixedCacheImplTest.testHotKeyBufferIterator:499 expected [true] but
found [false]
ChunkedFixedCacheImplTest.testHotKeyIterator:365 expected [true] but found
[false]
{code}
If we ignore these tests, then the execution of all tests will be successful
for both
JNA 4.1.0
https://github.com/Mmuzaf/ohc/actions/runs/6787282956/job/18449740138
JNA 5.13.0
https://github.com/Mmuzaf/ohc/actions/runs/6787399168/job/18450119146
> Exclude jna transitive dependecy from the ohc library
> -
>
> Key: CASSANDRA-18992
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18992
> Project: Cassandra
> Issue Type: Task
> Components: Dependencies
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Normal
> Fix For: 5.0-beta, 5.0.x, 5.x
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The concern is related to the JNA dependency on the ohc library. We are now
> using version 0.5.1 of the ohc library in Cassandra. The ohc 0.5.1 depends on
> version 4.1.0 of the net.java.dev.jna . For the Cassandra project, JNA has
> been updated since the 4.0 release version up to JNA 5.6.0 in CASSANDRA-16212
> to support running nodes on the arm64 architecture, so I assume that JNA
> 4.1.0 is no longer in Casssandra's classpath.
> The common practice in the Cassandra project is to exclude these kinds of
> transitive dependencies when they are explicitly mentioned in the main parent
> pom, since Ant may resolve them incorrectly. See comment:
> https://issues.apache.org/jira/browse/CASSANDRA-14667?focusedCommentId=17765091=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17765091
--
This message was sent by Atlassian 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-18968) StartupClusterConnectivityChecker fails on upgrade from 3.X
[
https://issues.apache.org/jira/browse/CASSANDRA-18968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-18968:
--
Fix Version/s: 4.0.x
4.1.x
> StartupClusterConnectivityChecker fails on upgrade from 3.X
> ---
>
> Key: CASSANDRA-18968
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18968
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Startup and Shutdown
>Reporter: Paulo Motta
>Assignee: Isaac Reath
>Priority: Normal
> Labels: lhf
> Fix For: 4.0.x, 4.1.x
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> Starting up a new 4.X node on a 3.x cluster throws the following warning:
> {noformat}
> WARN [main] 2023-10-27 15:58:22,234
> StartupClusterConnectivityChecker.java:183 - Timed out after 10002
> milliseconds, was waiting for remaining peers to connect: {dc1=[X.Y.Z.W,
> A.B.C.D]}
> {noformat}
> I think this is because the PING messages used by the startup check are not
> available on 3.X.
> To provide a smoother upgrade experience we should probably disable this
> check on a mixed version clusters, or skip peers on versions < 4.x when doing
> the connectivity check.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18968) StartupClusterConnectivityChecker fails on upgrade from 3.X
[
https://issues.apache.org/jira/browse/CASSANDRA-18968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-18968:
--
Reviewers: Stefan Miklosovic, Stefan Miklosovic
Stefan Miklosovic, Stefan Miklosovic (was: Stefan Miklosovic)
Status: Review In Progress (was: Patch Available)
> StartupClusterConnectivityChecker fails on upgrade from 3.X
> ---
>
> Key: CASSANDRA-18968
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18968
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Startup and Shutdown
>Reporter: Paulo Motta
>Assignee: Isaac Reath
>Priority: Normal
> Labels: lhf
> Fix For: 4.0.x, 4.1.x
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> Starting up a new 4.X node on a 3.x cluster throws the following warning:
> {noformat}
> WARN [main] 2023-10-27 15:58:22,234
> StartupClusterConnectivityChecker.java:183 - Timed out after 10002
> milliseconds, was waiting for remaining peers to connect: {dc1=[X.Y.Z.W,
> A.B.C.D]}
> {noformat}
> I think this is because the PING messages used by the startup check are not
> available on 3.X.
> To provide a smoother upgrade experience we should probably disable this
> check on a mixed version clusters, or skip peers on versions < 4.x when doing
> the connectivity check.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18968) StartupClusterConnectivityChecker fails on upgrade from 3.X
[
https://issues.apache.org/jira/browse/CASSANDRA-18968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17783684#comment-17783684
]
Stefan Miklosovic commented on CASSANDRA-18968:
---
This goes just to 4.0 and 4.1, correct? [~isaacreath] [~paulo]
> StartupClusterConnectivityChecker fails on upgrade from 3.X
> ---
>
> Key: CASSANDRA-18968
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18968
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Startup and Shutdown
>Reporter: Paulo Motta
>Assignee: Isaac Reath
>Priority: Normal
> Labels: lhf
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> Starting up a new 4.X node on a 3.x cluster throws the following warning:
> {noformat}
> WARN [main] 2023-10-27 15:58:22,234
> StartupClusterConnectivityChecker.java:183 - Timed out after 10002
> milliseconds, was waiting for remaining peers to connect: {dc1=[X.Y.Z.W,
> A.B.C.D]}
> {noformat}
> I think this is because the PING messages used by the startup check are not
> available on 3.X.
> To provide a smoother upgrade experience we should probably disable this
> check on a mixed version clusters, or skip peers on versions < 4.x when doing
> the connectivity check.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18911) KeyCacheTest is failing with sstable_preemptive_open_interval < 0
[ https://issues.apache.org/jira/browse/CASSANDRA-18911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17783683#comment-17783683 ] Stefan Miklosovic edited comment on CASSANDRA-18911 at 11/7/23 4:22 PM: trunk CI https://app.circleci.com/pipelines/github/instaclustr/cassandra/3456/workflows/dbe75d31-4423-4226-9a63-030563aef214/jobs/147398 PR is among links above was (Author: smiklosovic): trunk CI https://app.circleci.com/pipelines/github/instaclustr/cassandra/3456/workflows/dbe75d31-4423-4226-9a63-030563aef214/jobs/147398 PR is among links above > KeyCacheTest is failing with sstable_preemptive_open_interval < 0 > - > > Key: CASSANDRA-18911 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18911 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Jacek Lewandowski >Assignee: Jacek Lewandowski >Priority: Normal > Fix For: 5.0-beta, 5.1 > > Time Spent: 10m > Remaining Estimate: 0h > > Discovered by [~maedhroz] -- This message was sent by Atlassian 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-18911) KeyCacheTest is failing with sstable_preemptive_open_interval < 0
[ https://issues.apache.org/jira/browse/CASSANDRA-18911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17783683#comment-17783683 ] Stefan Miklosovic commented on CASSANDRA-18911: --- trunk CI https://app.circleci.com/pipelines/github/instaclustr/cassandra/3456/workflows/dbe75d31-4423-4226-9a63-030563aef214/jobs/147398 PR is among links above > KeyCacheTest is failing with sstable_preemptive_open_interval < 0 > - > > Key: CASSANDRA-18911 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18911 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Jacek Lewandowski >Assignee: Jacek Lewandowski >Priority: Normal > Fix For: 5.0-beta, 5.1 > > Time Spent: 10m > Remaining Estimate: 0h > > Discovered by [~maedhroz] -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-19006) DROPing a non-existant function with parameter types results in bizarre error
Nadav Har'El created CASSANDRA-19006:
Summary: DROPing a non-existant function with parameter types
results in bizarre error
Key: CASSANDRA-19006
URL: https://issues.apache.org/jira/browse/CASSANDRA-19006
Project: Cassandra
Issue Type: Bug
Reporter: Nadav Har'El
When attempting a command like
{{DROP FUNCTION ks.fun(int)}}
Where the keyspace "ks" exists, but "fun" doesn't - and note also an attempt to
choose which of several (non-existent) overloads to remove - one gets a bizarre
error from Cassandra - instead of InvalidRequest (or maybe
ConfigurationException), we get a SyntaxError, with the strange message
"NoSuchElementException No value present". Neither the SyntaxError type nor
this specific message makes much sense. This is not a syntax error, and the
same request would have worked if this specific function existed.
--
This message was sent by Atlassian 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-18963) Test Failure: sstableutil_test.TestSSTableUtil
[
https://issues.apache.org/jira/browse/CASSANDRA-18963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17783681#comment-17783681
]
Brandon Williams commented on CASSANDRA-18963:
--
[~blerer], [~e.dimitrova], [~jlewandowski] it looks like CASSANDRA-18747 is
responsible for both this ticket and CASSANDRA-18991. On 4.1 the [initial
commit|https://app.circleci.com/pipelines/github/driftx/cassandra/1355/workflows/066deee5-e1a4-434c-91e5-fe8602084e86/jobs/60281]
fails while the one [before
passes|https://app.circleci.com/pipelines/github/driftx/cassandra/1357/workflows/97a73b15-8b23-4617-969b-9077284e664d/jobs/60483]
(CASSANDRA-18991), and then the [merge to 5.0
fails|https://app.circleci.com/pipelines/github/driftx/cassandra/1354/workflows/5dc4d5b4-4f1a-46c8-8208-78715b409068/jobs/60184]
where it previously [did
not|https://app.circleci.com/pipelines/github/driftx/cassandra/1356/workflows/fe99cc03-588a-469c-8ffb-ae62bf73d672/jobs/60386].
> Test Failure: sstableutil_test.TestSSTableUtil
> --
>
> Key: CASSANDRA-18963
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18963
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Berenguer Blasi
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 5.0-beta
>
>
> Seems flaky
> [https://app.circleci.com/pipelines/github/driftx/cassandra/1342/workflows/9554c7b5-dd60-4f08-8db5-c954febc8ad6/jobs/58957/tests]
> *
> h4. test_abortedcompaction
> sstableutil_test.TestSSTableUtil
>
> {code:java}
> self = def
> test_abortedcompaction(self): """ @jira_ticket CASSANDRA-7066 @jira_ticket
> CASSANDRA-11497 Check that we can cleanup temporary files after a compaction
> is aborted. """ log_file_name = 'debug.log' cluster = self.cluster
> cluster.populate(1).start() node = cluster.nodelist()[0] numrecords = 25
> self._create_data(node, KeyspaceName, TableName, numrecords) finalfiles,
> tmpfiles = self._check_files(node, KeyspaceName, TableName) assert
> len(finalfiles) > 0, "Expected to find some final files" assert 0 ==
> len(tmpfiles), "Expected no tmp files" t = InterruptCompaction(node,
> TableName, filename=log_file_name, delay=2) t.start() try:
> logger.debug("Compacting...") node.compact() except ToolError: pass #
> expected to fail t.join() finalfiles =
> _normcase_all(self._invoke_sstableutil(KeyspaceName, TableName,
> type='final')) tmpfiles =
> _normcase_all(self._invoke_sstableutil(KeyspaceName, TableName, type='tmp'))
> # In most cases we should end up with some temporary files to clean up, but
> it may happen # that no temporary files are created if compaction finishes
> too early or starts too late # see CASSANDRA-11497 logger.debug("Got {} final
> files and {} tmp files after compaction was interrupted"
> .format(len(finalfiles), len(tmpfiles)))
> self._invoke_sstableutil(KeyspaceName, TableName, cleanup=True)
> self._check_files(node, KeyspaceName, TableName, finalfiles, []) # restart to
> make sure not data is lost logger.debug("Restarting node...") >
> node.start(wait_for_binary_proto=True) sstableutil_test.py:97: _ _ _ _ _ _ _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> ../env3.6/lib/python3.6/site-packages/ccmlib/node.py:914: in start
> self.wait_for_binary_interface(from_mark=self.mark)
> ../env3.6/lib/python3.6/site-packages/ccmlib/node.py:702: in
> wait_for_binary_interface self.watch_log_for("Starting listening for CQL
> clients", **kwargs) ../env3.6/lib/python3.6/site-packages/ccmlib/node.py:599:
> in watch_log_for self.raise_node_error_if_cassandra_process_is_terminated() _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> self = def
> raise_node_error_if_cassandra_process_is_terminated(self): if not
> self._is_pid_running(): msg = "C* process with {pid} is
> terminated".format(pid=self.pid) common.debug(msg) > raise NodeError(msg) E
> ccmlib.node.NodeError: C* process with 19530 is terminated
> ../env3.6/lib/python3.6/site-packages/ccmlib/node.py:683: NodeError{code}
> {code:java}
> failed on teardown with "Unexpected error found in node logs (see stdout for
> full details). Errors: [[node1] 'ERROR [SSTableBatchOpen:1] 2023-10-19
> 22:25:07,449 DefaultFSErrorHandler.java:129 - Exiting forcefully due to file
> system exception on startup, disk failure policy
> "stop"\norg.apache.cassandra.io.sstable.CorruptSSTableException: Corrupted:
> /tmp/dtest-ahz16wrh/test/node1/data0/system/prepared_statements-18a9c2576a0c3841ba718cd529849fef/nc-4-big\n\tat
>
> org.apache.cassandra.io.sstable.format.SSTableReaderLoadingBuilder.build(SSTableReaderLoadingBuilder.java:111)\n\tat
>
> org.apache.cassandra.io.sstable.format.SSTableReader.open(SSTableReader.java:397)\n\tat
>
>
[jira] [Created] (CASSANDRA-19005) DROPing an overloaded UDF produces the wrong error message if drop permissions are lacking
Nadav Har'El created CASSANDRA-19005: Summary: DROPing an overloaded UDF produces the wrong error message if drop permissions are lacking Key: CASSANDRA-19005 URL: https://issues.apache.org/jira/browse/CASSANDRA-19005 Project: Cassandra Issue Type: Bug Reporter: Nadav Har'El When a user creates two user-defined functions with the same name but different parameters, to later remove these functions with DROP FUNCTION, the user must disambiguate which one to delete. For example, "DROP FUNCTION ks.fun(int, int)". If the user tries just "DROP FUNCTION ks.fun", Cassandra will return an InvalidRequest, complaining about "multiple functions" with the same name. So far so good. Now, if the user has (via GRANT) permissions to drop only one of these functions and no permissions to drop the second, trying to do "DROP FUNCTION ks.fun" should still return the good old InvalidRequest, because the request is still just as ambiguous as it was when permissions weren't involved. But, Cassandra instead notices that one of the variants, e.g., ks.fun(int, int), doesn't have drop permissions, and returns an Unauthorized error (instead of InvalidRequest), saying that "ks.fun(int, int)" doesn't have drop permissions. This is true - but irrelevant - the user didn't ask to drop that specific overload of the function. Moreover, it's misleading because it can lead the user to GRANT these supposedly-missing permissions, but after granting them, the DROP FUNCTION command still won't work, because it will still be ambiguous. This is a minor error-path bug, but I noticed it while trying to exhaustively look how permissions and functions interact in Cassandra. -- This message was sent by Atlassian 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-18932) Harry-found CorruptSSTableException / RT Closer issue when reading entire partition
[
https://issues.apache.org/jira/browse/CASSANDRA-18932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacek Lewandowski updated CASSANDRA-18932:
--
Test and Documentation Plan: regression test, fuzz tests
Status: Patch Available (was: In Progress)
> Harry-found CorruptSSTableException / RT Closer issue when reading entire
> partition
> ---
>
> Key: CASSANDRA-18932
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18932
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
>Reporter: Alex Petrov
>Assignee: Maxim Muzafarov
>Priority: Normal
> Fix For: 5.0-beta, 5.0.x, 5.x
>
> Attachments: node1_.zip, operation.log.zip, screenshot-1.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> While testing some new machinery for Harry, I have encountered a new RT
> closer / SSTable Corruption issue. I have grounds to believe this was
> introduced during the last year.
> Issue seems to happen because of intricate interleaving of flushes with
> writes and deletes.
> {code:java}
> ERROR [ReadStage-2] 2023-10-16 18:47:06,696 JVMStabilityInspector.java:76 -
> Exception in thread Thread[ReadStage-2,5,SharedPool]
> org.apache.cassandra.io.sstable.CorruptSSTableException: Corrupted:
> RandomAccessReader:BufferManagingRebufferer.Aligned:CompressedChunkReader.Mmap(/Users/ifesdjeen/foss/java/apache-cassandra-4.0/data/data1/harry/table_1-07c35a606c0a11eeae7a4f6ca489eb0c/nc-5-big-Data.db
> - LZ4Compressor, chunk length 16384, data length 232569)
> at
> org.apache.cassandra.io.sstable.AbstractSSTableIterator$AbstractReader.hasNext(AbstractSSTableIterator.java:381)
> at
> org.apache.cassandra.io.sstable.AbstractSSTableIterator.hasNext(AbstractSSTableIterator.java:242)
> at
> org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.computeNext(LazilyInitializedUnfilteredRowIterator.java:95)
> at
> org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.computeNext(LazilyInitializedUnfilteredRowIterator.java:32)
> at
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47)
> at
> org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:133)
> at
> org.apache.cassandra.utils.MergeIterator$Candidate.advance(MergeIterator.java:376)
> at
> org.apache.cassandra.utils.MergeIterator$ManyToOne.advance(MergeIterator.java:188)
> at
> org.apache.cassandra.utils.MergeIterator$ManyToOne.computeNext(MergeIterator.java:157)
> at
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47)
> at
> org.apache.cassandra.db.rows.UnfilteredRowIterators$UnfilteredRowMergeIterator.computeNext(UnfilteredRowIterators.java:534)
> at
> org.apache.cassandra.db.rows.UnfilteredRowIterators$UnfilteredRowMergeIterator.computeNext(UnfilteredRowIterators.java:402)
> at
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47)
> at
> org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.computeNext(LazilyInitializedUnfilteredRowIterator.java:95)
> at
> org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.computeNext(LazilyInitializedUnfilteredRowIterator.java:32)
> at
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47)
> at
> org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:133)
> at
> org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:133)
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:151)
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:101)
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:86)
> at
> org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$Serializer.serialize(UnfilteredPartitionIterators.java:343)
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.build(ReadResponse.java:201)
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:186)
> at
> org.apache.cassandra.db.ReadResponse.createDataResponse(ReadResponse.java:48)
> at
> org.apache.cassandra.db.ReadCommand.createResponse(ReadCommand.java:346)
> at
> org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:2186)
> at
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2581)
> at
>
[jira] [Comment Edited] (CASSANDRA-18902) Test failure: org.apache.cassandra.distributed.test.MigrationCoordinatorTest.explicitEndpointIgnore
[
https://issues.apache.org/jira/browse/CASSANDRA-18902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17783669#comment-17783669
]
Ekaterina Dimitrova edited comment on CASSANDRA-18902 at 11/7/23 3:08 PM:
--
[~adelapena] noticed that both branches fail on
{{FBUtilities#getReleaseVersionMajor}} , but 4.1 seems to get a release version
different to {{UNKNOWN_RELEASE_VERSION = "Unknown"}} that doesn’t contain dots,
whereas 5.0 fails because it gets {{{}UNKNOWN_RELEASE_VERSION{}}}. I missed
seeing that last week.
was (Author: e.dimitrova):
[~adelapena] noticed that both branches fail on
{{FBUtilities#getReleaseVersionMajor}} , but 4.1 seems to get a release version
different to {{UNKNOWN_RELEASE_VERSION }}{{= "Unknown"}} that doesn’t contain
dots, whereas 5.0 fails because it gets {{{}UNKNOWN_RELEASE_VERSION{}}}. I
missed seeing that last week.
> Test failure:
> org.apache.cassandra.distributed.test.MigrationCoordinatorTest.explicitEndpointIgnore
> ---
>
> Key: CASSANDRA-18902
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18902
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: Jacek Lewandowski
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
>
> Repeated run from `cassandra-4.1`
> [https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/941/workflows/46fc6cb7-135e-4862-b9d3-6996c0993de8]
>
--
This message was sent by Atlassian 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-18902) Test failure: org.apache.cassandra.distributed.test.MigrationCoordinatorTest.explicitEndpointIgnore
[
https://issues.apache.org/jira/browse/CASSANDRA-18902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17783669#comment-17783669
]
Ekaterina Dimitrova commented on CASSANDRA-18902:
-
[~adelapena] noticed that both branches fail on
{{FBUtilities#getReleaseVersionMajor}} , but 4.1 seems to get a release version
different to {{UNKNOWN_RELEASE_VERSION}}{{ __ }}{{= "Unknown"}} that doesn’t
contain dots, whereas 5.0 fails because it gets
{{{}UNKNOWN_RELEASE_VERSION{}}}. I missed seeing that last week.
> Test failure:
> org.apache.cassandra.distributed.test.MigrationCoordinatorTest.explicitEndpointIgnore
> ---
>
> Key: CASSANDRA-18902
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18902
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: Jacek Lewandowski
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
>
> Repeated run from `cassandra-4.1`
> [https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/941/workflows/46fc6cb7-135e-4862-b9d3-6996c0993de8]
>
--
This message was sent by Atlassian 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-18902) Test failure: org.apache.cassandra.distributed.test.MigrationCoordinatorTest.explicitEndpointIgnore
[
https://issues.apache.org/jira/browse/CASSANDRA-18902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17783669#comment-17783669
]
Ekaterina Dimitrova edited comment on CASSANDRA-18902 at 11/7/23 3:07 PM:
--
[~adelapena] noticed that both branches fail on
{{FBUtilities#getReleaseVersionMajor}} , but 4.1 seems to get a release version
different to {{UNKNOWN_RELEASE_VERSION }}{{= "Unknown"}} that doesn’t contain
dots, whereas 5.0 fails because it gets {{{}UNKNOWN_RELEASE_VERSION{}}}. I
missed seeing that last week.
was (Author: e.dimitrova):
[~adelapena] noticed that both branches fail on
{{FBUtilities#getReleaseVersionMajor}} , but 4.1 seems to get a release version
different to {{UNKNOWN_RELEASE_VERSION}}{{ __ }}{{= "Unknown"}} that doesn’t
contain dots, whereas 5.0 fails because it gets
{{{}UNKNOWN_RELEASE_VERSION{}}}. I missed seeing that last week.
> Test failure:
> org.apache.cassandra.distributed.test.MigrationCoordinatorTest.explicitEndpointIgnore
> ---
>
> Key: CASSANDRA-18902
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18902
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: Jacek Lewandowski
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
>
> Repeated run from `cassandra-4.1`
> [https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/941/workflows/46fc6cb7-135e-4862-b9d3-6996c0993de8]
>
--
This message was sent by Atlassian 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-18731) Add declarative root CI structure
[
https://issues.apache.org/jira/browse/CASSANDRA-18731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh McKenzie updated CASSANDRA-18731:
--
Status: Open (was: Patch Available)
> Add declarative root CI structure
> -
>
> Key: CASSANDRA-18731
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18731
> Project: Cassandra
> Issue Type: Improvement
> Components: CI
>Reporter: Josh McKenzie
>Assignee: Josh McKenzie
>Priority: Normal
> Fix For: 5.x
>
>
> Currently we have a somewhat declarative structure in .circleci, however
> there's still quite a bit that's baked in (resource limitations, parallelism,
> which suites qualify for which pipelines (pre-commit vs. post-commit vs.
> ???), etc). Further, while CASSANDRA-18133 brings the build scripts in-tree,
> all these parameters (pipelines, env vars, job definitions, resource
> constraints) are all still scattered throughout the shell scripts and/or
> reliant on the {{JenkinsFile}} to determine what suites comprise what
> pipelines.
> This ticket aims to decouple the definition of pipelines and jobs for CI from
> the implementations themselves. The goal here is to define, establish, and
> test both the base config and some helper methods to provide _other_
> configurations (circle, ASF CI, etc) the tools they need to programmatically
> inherit base CI config from a purely declarative structure.
> Follow-up tickets will involve rewriting the in-tree build scripts and
> JenkinsFile generation to rely on this structure, as well as integrating the
> config parsing unit tests into our CI.
--
This message was sent by Atlassian 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-19002) Create / update tests to ensure commit logs and hints for all versions in MS are ingestible in 5.0
[ https://issues.apache.org/jira/browse/CASSANDRA-19002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-19002: -- Test and Documentation Plan: ci Status: Patch Available (was: In Progress) https://github.com/apache/cassandra/pulls?q=CASSANDRA-19002 > Create / update tests to ensure commit logs and hints for all versions in MS > are ingestible in 5.0 > -- > > Key: CASSANDRA-19002 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19002 > Project: Cassandra > Issue Type: Task > Components: Test/unit >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 5.0-beta, 5.x > > Time Spent: 1h > Remaining Estimate: 0h > > This is follow up of CASSANDRA-18314 -- This message was sent by Atlassian 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-18932) Harry-found CorruptSSTableException / RT Closer issue when reading entire partition
[
https://issues.apache.org/jira/browse/CASSANDRA-18932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17783645#comment-17783645
]
Alex Petrov commented on CASSANDRA-18932:
-
Sure, sounds good!
> Harry-found CorruptSSTableException / RT Closer issue when reading entire
> partition
> ---
>
> Key: CASSANDRA-18932
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18932
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
>Reporter: Alex Petrov
>Assignee: Maxim Muzafarov
>Priority: Normal
> Fix For: 5.0-beta, 5.0.x, 5.x
>
> Attachments: node1_.zip, operation.log.zip, screenshot-1.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> While testing some new machinery for Harry, I have encountered a new RT
> closer / SSTable Corruption issue. I have grounds to believe this was
> introduced during the last year.
> Issue seems to happen because of intricate interleaving of flushes with
> writes and deletes.
> {code:java}
> ERROR [ReadStage-2] 2023-10-16 18:47:06,696 JVMStabilityInspector.java:76 -
> Exception in thread Thread[ReadStage-2,5,SharedPool]
> org.apache.cassandra.io.sstable.CorruptSSTableException: Corrupted:
> RandomAccessReader:BufferManagingRebufferer.Aligned:CompressedChunkReader.Mmap(/Users/ifesdjeen/foss/java/apache-cassandra-4.0/data/data1/harry/table_1-07c35a606c0a11eeae7a4f6ca489eb0c/nc-5-big-Data.db
> - LZ4Compressor, chunk length 16384, data length 232569)
> at
> org.apache.cassandra.io.sstable.AbstractSSTableIterator$AbstractReader.hasNext(AbstractSSTableIterator.java:381)
> at
> org.apache.cassandra.io.sstable.AbstractSSTableIterator.hasNext(AbstractSSTableIterator.java:242)
> at
> org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.computeNext(LazilyInitializedUnfilteredRowIterator.java:95)
> at
> org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.computeNext(LazilyInitializedUnfilteredRowIterator.java:32)
> at
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47)
> at
> org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:133)
> at
> org.apache.cassandra.utils.MergeIterator$Candidate.advance(MergeIterator.java:376)
> at
> org.apache.cassandra.utils.MergeIterator$ManyToOne.advance(MergeIterator.java:188)
> at
> org.apache.cassandra.utils.MergeIterator$ManyToOne.computeNext(MergeIterator.java:157)
> at
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47)
> at
> org.apache.cassandra.db.rows.UnfilteredRowIterators$UnfilteredRowMergeIterator.computeNext(UnfilteredRowIterators.java:534)
> at
> org.apache.cassandra.db.rows.UnfilteredRowIterators$UnfilteredRowMergeIterator.computeNext(UnfilteredRowIterators.java:402)
> at
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47)
> at
> org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.computeNext(LazilyInitializedUnfilteredRowIterator.java:95)
> at
> org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.computeNext(LazilyInitializedUnfilteredRowIterator.java:32)
> at
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47)
> at
> org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:133)
> at
> org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:133)
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:151)
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:101)
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:86)
> at
> org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$Serializer.serialize(UnfilteredPartitionIterators.java:343)
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.build(ReadResponse.java:201)
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:186)
> at
> org.apache.cassandra.db.ReadResponse.createDataResponse(ReadResponse.java:48)
> at
> org.apache.cassandra.db.ReadCommand.createResponse(ReadCommand.java:346)
> at
> org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:2186)
> at
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2581)
> at
> org.apache.cassandra.concurrent.ExecutionFailure$2.run(ExecutionFailure.java:163)
> at
[jira] [Commented] (CASSANDRA-18932) Harry-found CorruptSSTableException / RT Closer issue when reading entire partition
[
https://issues.apache.org/jira/browse/CASSANDRA-18932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17783643#comment-17783643
]
Jacek Lewandowski commented on CASSANDRA-18932:
---
[~ifesdjeen] maybe we can move the discussion around fuzz testing to some other
ticket and refer to this one as an example of its usefulness?
> Harry-found CorruptSSTableException / RT Closer issue when reading entire
> partition
> ---
>
> Key: CASSANDRA-18932
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18932
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
>Reporter: Alex Petrov
>Assignee: Maxim Muzafarov
>Priority: Normal
> Fix For: 5.0-beta, 5.0.x, 5.x
>
> Attachments: node1_.zip, operation.log.zip, screenshot-1.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> While testing some new machinery for Harry, I have encountered a new RT
> closer / SSTable Corruption issue. I have grounds to believe this was
> introduced during the last year.
> Issue seems to happen because of intricate interleaving of flushes with
> writes and deletes.
> {code:java}
> ERROR [ReadStage-2] 2023-10-16 18:47:06,696 JVMStabilityInspector.java:76 -
> Exception in thread Thread[ReadStage-2,5,SharedPool]
> org.apache.cassandra.io.sstable.CorruptSSTableException: Corrupted:
> RandomAccessReader:BufferManagingRebufferer.Aligned:CompressedChunkReader.Mmap(/Users/ifesdjeen/foss/java/apache-cassandra-4.0/data/data1/harry/table_1-07c35a606c0a11eeae7a4f6ca489eb0c/nc-5-big-Data.db
> - LZ4Compressor, chunk length 16384, data length 232569)
> at
> org.apache.cassandra.io.sstable.AbstractSSTableIterator$AbstractReader.hasNext(AbstractSSTableIterator.java:381)
> at
> org.apache.cassandra.io.sstable.AbstractSSTableIterator.hasNext(AbstractSSTableIterator.java:242)
> at
> org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.computeNext(LazilyInitializedUnfilteredRowIterator.java:95)
> at
> org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.computeNext(LazilyInitializedUnfilteredRowIterator.java:32)
> at
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47)
> at
> org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:133)
> at
> org.apache.cassandra.utils.MergeIterator$Candidate.advance(MergeIterator.java:376)
> at
> org.apache.cassandra.utils.MergeIterator$ManyToOne.advance(MergeIterator.java:188)
> at
> org.apache.cassandra.utils.MergeIterator$ManyToOne.computeNext(MergeIterator.java:157)
> at
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47)
> at
> org.apache.cassandra.db.rows.UnfilteredRowIterators$UnfilteredRowMergeIterator.computeNext(UnfilteredRowIterators.java:534)
> at
> org.apache.cassandra.db.rows.UnfilteredRowIterators$UnfilteredRowMergeIterator.computeNext(UnfilteredRowIterators.java:402)
> at
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47)
> at
> org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.computeNext(LazilyInitializedUnfilteredRowIterator.java:95)
> at
> org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.computeNext(LazilyInitializedUnfilteredRowIterator.java:32)
> at
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47)
> at
> org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:133)
> at
> org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:133)
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:151)
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:101)
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:86)
> at
> org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$Serializer.serialize(UnfilteredPartitionIterators.java:343)
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.build(ReadResponse.java:201)
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:186)
> at
> org.apache.cassandra.db.ReadResponse.createDataResponse(ReadResponse.java:48)
> at
> org.apache.cassandra.db.ReadCommand.createResponse(ReadCommand.java:346)
> at
> org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:2186)
> at
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2581)
>
[jira] [Commented] (CASSANDRA-18932) Harry-found CorruptSSTableException / RT Closer issue when reading entire partition
[
https://issues.apache.org/jira/browse/CASSANDRA-18932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17783639#comment-17783639
]
Alex Petrov commented on CASSANDRA-18932:
-
While it is probably benefitial to run tests with different column index sizes,
I think we can rely on Harry for fuzzing perturbations. I have stumbled upon
this issue while testing new Harry subsystem which allows more targeted tests,
better API and potentially quicker turnaround, and it has so far caught all
mentioned problems: RT corruption, data loss, infinite iteration, corruption in
several different places. While minimal repros are useful for reviewers, and
should be attached to the patch, they are not likely to be useful for
regression testing, since the chance we will re-introduce exactly same issue is
relatively small. We should rely on fuzzing more: it finds issues quickly,
covers all schemas, and is easy to configure and extend.
> Harry-found CorruptSSTableException / RT Closer issue when reading entire
> partition
> ---
>
> Key: CASSANDRA-18932
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18932
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
>Reporter: Alex Petrov
>Assignee: Maxim Muzafarov
>Priority: Normal
> Fix For: 5.0-beta, 5.0.x, 5.x
>
> Attachments: node1_.zip, operation.log.zip, screenshot-1.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> While testing some new machinery for Harry, I have encountered a new RT
> closer / SSTable Corruption issue. I have grounds to believe this was
> introduced during the last year.
> Issue seems to happen because of intricate interleaving of flushes with
> writes and deletes.
> {code:java}
> ERROR [ReadStage-2] 2023-10-16 18:47:06,696 JVMStabilityInspector.java:76 -
> Exception in thread Thread[ReadStage-2,5,SharedPool]
> org.apache.cassandra.io.sstable.CorruptSSTableException: Corrupted:
> RandomAccessReader:BufferManagingRebufferer.Aligned:CompressedChunkReader.Mmap(/Users/ifesdjeen/foss/java/apache-cassandra-4.0/data/data1/harry/table_1-07c35a606c0a11eeae7a4f6ca489eb0c/nc-5-big-Data.db
> - LZ4Compressor, chunk length 16384, data length 232569)
> at
> org.apache.cassandra.io.sstable.AbstractSSTableIterator$AbstractReader.hasNext(AbstractSSTableIterator.java:381)
> at
> org.apache.cassandra.io.sstable.AbstractSSTableIterator.hasNext(AbstractSSTableIterator.java:242)
> at
> org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.computeNext(LazilyInitializedUnfilteredRowIterator.java:95)
> at
> org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.computeNext(LazilyInitializedUnfilteredRowIterator.java:32)
> at
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47)
> at
> org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:133)
> at
> org.apache.cassandra.utils.MergeIterator$Candidate.advance(MergeIterator.java:376)
> at
> org.apache.cassandra.utils.MergeIterator$ManyToOne.advance(MergeIterator.java:188)
> at
> org.apache.cassandra.utils.MergeIterator$ManyToOne.computeNext(MergeIterator.java:157)
> at
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47)
> at
> org.apache.cassandra.db.rows.UnfilteredRowIterators$UnfilteredRowMergeIterator.computeNext(UnfilteredRowIterators.java:534)
> at
> org.apache.cassandra.db.rows.UnfilteredRowIterators$UnfilteredRowMergeIterator.computeNext(UnfilteredRowIterators.java:402)
> at
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47)
> at
> org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.computeNext(LazilyInitializedUnfilteredRowIterator.java:95)
> at
> org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.computeNext(LazilyInitializedUnfilteredRowIterator.java:32)
> at
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47)
> at
> org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:133)
> at
> org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:133)
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:151)
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:101)
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:86)
> at
>
[jira] [Commented] (CASSANDRA-18993) Harry-found silent data loss issue
[
https://issues.apache.org/jira/browse/CASSANDRA-18993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17783633#comment-17783633
]
Alex Petrov commented on CASSANDRA-18993:
-
Repro:
{code:java}
@Test
public void silentDataLossTest() throws Throwable
{
try (Cluster cluster = builder().withNodes(1)
.withConfig((cfg) -> {
cfg.set("memtable_heap_space",
"512MiB")
.set("column_index_size",
"1KiB");
})
.start())
{
cluster.schemaChange("CREATE KEYSPACE IF NOT EXISTS
distributed_test_keyspace WITH replication = {'class': 'SimpleStrategy',
'replication_factor': 1};");
cluster.schemaChange("CREATE TABLE IF NOT EXISTS
distributed_test_keyspace.sut (pk1 bigint,ck1 ascii,v1 ascii, PRIMARY KEY (pk1,
ck1)) WITH CLUSTERING ORDER BY (ck1 ASC);");
cluster.schemaChange("CREATE TABLE IF NOT EXISTS
distributed_test_keyspace.model (pk1 bigint,ck1 ascii,v1 ascii, PRIMARY KEY
(pk1, ck1)) WITH CLUSTERING ORDER BY (ck1 ASC);");
for (String tbl : new String[]{ "model", "sut" })
{
cluster.coordinator(1).execute("INSERT INTO
distributed_test_keyspace." + tbl + " (pk1,ck1,v1) VALUES (?, ?, ?) USING
TIMESTAMP 2796;", QUORUM,
-5095160963388022135L,
"DPJCvLDEDZnaEbUFhUVaRwdFQDikZLmsxSdVBEqooUAlqDQlStFwlwzVfpdJQfkG5033",
"JcMxGhPTaMHvCWHqbZudusDaZNvVSxVtitaCueFYlOEalFPuJsUkZzOVntcbWeVx473218153102427916835771671002269155241181613830359523821851961238681251252551261956820112990482292349610087946720815012725516116722810220384253253126155718111061170",
-5095160963388022135L);
cluster.coordinator(1).execute("INSERT INTO
distributed_test_keyspace." + tbl + " (pk1,ck1) VALUES (?, ?) USING TIMESTAMP
9673;", QUORUM,
-5095160963388022135L,
"FGTwdBRbABgDknItRjYSvxPXSdhqYCfuhxkTqYESsqPclKMGJAVldTHiQDikZLms101165501834286",
-5095160963388022135L);
cluster.coordinator(1).execute("INSERT INTO
distributed_test_keyspace." + tbl + " (pk1,ck1) VALUES (?, ?) USING TIMESTAMP
7070;", QUORUM,
-5095160963388022135L,
"EZsDzsPMgKaBtQMODPJCvLDEYDzpfKqYCmfLLyPPdvPbsXYqaIEGJuEpRQdJwEup15652246130252128225641091541411815737248488414116225117098",
-5095160963388022135L);
cluster.coordinator(1).execute("INSERT INTO
distributed_test_keyspace." + tbl + " (pk1,ck1,v1) VALUES (?, ?, ?) USING
TIMESTAMP 4095;", QUORUM,
-5095160963388022135L,
"HXuAukuhSFPNmxwcrjcnEtdvhUUEkSvygjEATtVzYDzpfKqYCgbmJQViaymGDgfW1652172243206180157137178201265235112108156237214",
"hxkTqYESCmfLLyPPTLDFowirgerzwhAVJktxaFwAGIzPsPrWoqaYHuFOygLwVHYl8365214226110261426220217513513712816915180102101365921121412719022516064163209173134217205239112",
-5095160963388022135L);
// comment this one to hit RT boundary bug
cluster.coordinator(1).execute("INSERT INTO
distributed_test_keyspace." + tbl + " (pk1,ck1) VALUES (?, ?) USING TIMESTAMP
7938;", QUORUM,
-5095160963388022135L,
"XEFrgBnOLHahCNpPalrmgBCUHHruatGSisXHJxcYntcbWeVxNYJzEiFewKrXnFMQ722181162481551633514112160498813312419378157224137205892202551931861302023013682213024410422023448238221123510211024610918462",
-5095160963388022135L);
cluster.coordinator(1).execute("DELETE FROM
distributed_test_keyspace." + tbl + " USING TIMESTAMP 3628 WHERE pk1 = ? AND
ck1 > ? AND ck1 <= ?;", QUORUM,
-5095160963388022135L,
"EZsDzsPMgKaBtQMODPJCvLDEYDzpfKqYCmfLLyPPdvPbsXYqaIEGJuEpRQdJwEup15652246130252128225641091541411815737248488414116225117098",
"mTNkwIyBQdPlymmMfpdJQfkGsUdSCMlwdvPbsXYqAVokALUTYiqBDfKVctLULPli131882272341129768310816024018356781847012029115110118203905244179237513886822492892054258646145171179206125418068245148147179",
-5095160963388022135L);
cluster.coordinator(1).execute("DELETE FROM
distributed_test_keyspace." + tbl + " USING TIMESTAMP 6463 WHERE pk1 = ? AND
ck1 > ? AND ck1 <= ?;", QUORUM,
-5095160963388022135L,
"HXuAukuhSFPNmxwcrjcnEtdvhUUEkSvygjEATtVzYDzpfKqYCgbmJQViaymGDgfW1652172243206180157137178201265235112108156237214",
"dbqXpTyyKLcKgkLFwKrXnFMQYwRbGDWbGEebeOApZNvVSxVtqwyOnfYGchTAyMjm1971372042587121667129167712108815719922553824520512793206817056105245591888552341941222181",
-5095160963388022135L);
}
cluster.get(1).nodetool("flush", "distributed_test_keyspace",
"sut");
Iterator iterSut =
cluster.coordinator(1).executeWithPaging("SELECT * FROM
[jira] [Commented] (CASSANDRA-18932) Harry-found CorruptSSTableException / RT Closer issue when reading entire partition
[
https://issues.apache.org/jira/browse/CASSANDRA-18932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17783634#comment-17783634
]
Jacek Lewandowski commented on CASSANDRA-18932:
---
I think we nailed down the circumstances at which the problems happen. While
testing we have seen various effects - inifinite looping during paging, silent
data loss, corruption errors while reading. It seems like the repeated pattern
for those problems is that:
- there are more than one primary index blocks
- the last item after non-last index block is created is
{{INCL_END_EXCL_START_BOUNDARY}} tombstone marker
The failure is not related to:
- multiple partition key columns
- multiple clustering key columns
- paging
- clustering order
So far we can see that the bug is in the big table iteration which uses primary
index. When the index block is switched, the unfiltered deserializer is
unnecessarily reset. This is my fault which I introduced in CASSANDRA-17056
(SSTable format API) and the fix is trivial. However, the problem revealed some
holes in our test coverage and we need to address that as well.
> Harry-found CorruptSSTableException / RT Closer issue when reading entire
> partition
> ---
>
> Key: CASSANDRA-18932
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18932
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
>Reporter: Alex Petrov
>Assignee: Maxim Muzafarov
>Priority: Normal
> Fix For: 5.0-beta, 5.0.x, 5.x
>
> Attachments: node1_.zip, operation.log.zip, screenshot-1.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> While testing some new machinery for Harry, I have encountered a new RT
> closer / SSTable Corruption issue. I have grounds to believe this was
> introduced during the last year.
> Issue seems to happen because of intricate interleaving of flushes with
> writes and deletes.
> {code:java}
> ERROR [ReadStage-2] 2023-10-16 18:47:06,696 JVMStabilityInspector.java:76 -
> Exception in thread Thread[ReadStage-2,5,SharedPool]
> org.apache.cassandra.io.sstable.CorruptSSTableException: Corrupted:
> RandomAccessReader:BufferManagingRebufferer.Aligned:CompressedChunkReader.Mmap(/Users/ifesdjeen/foss/java/apache-cassandra-4.0/data/data1/harry/table_1-07c35a606c0a11eeae7a4f6ca489eb0c/nc-5-big-Data.db
> - LZ4Compressor, chunk length 16384, data length 232569)
> at
> org.apache.cassandra.io.sstable.AbstractSSTableIterator$AbstractReader.hasNext(AbstractSSTableIterator.java:381)
> at
> org.apache.cassandra.io.sstable.AbstractSSTableIterator.hasNext(AbstractSSTableIterator.java:242)
> at
> org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.computeNext(LazilyInitializedUnfilteredRowIterator.java:95)
> at
> org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.computeNext(LazilyInitializedUnfilteredRowIterator.java:32)
> at
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47)
> at
> org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:133)
> at
> org.apache.cassandra.utils.MergeIterator$Candidate.advance(MergeIterator.java:376)
> at
> org.apache.cassandra.utils.MergeIterator$ManyToOne.advance(MergeIterator.java:188)
> at
> org.apache.cassandra.utils.MergeIterator$ManyToOne.computeNext(MergeIterator.java:157)
> at
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47)
> at
> org.apache.cassandra.db.rows.UnfilteredRowIterators$UnfilteredRowMergeIterator.computeNext(UnfilteredRowIterators.java:534)
> at
> org.apache.cassandra.db.rows.UnfilteredRowIterators$UnfilteredRowMergeIterator.computeNext(UnfilteredRowIterators.java:402)
> at
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47)
> at
> org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.computeNext(LazilyInitializedUnfilteredRowIterator.java:95)
> at
> org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.computeNext(LazilyInitializedUnfilteredRowIterator.java:32)
> at
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47)
> at
> org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:133)
> at
> org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:133)
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:151)
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:101)
> at
>
[jira] [Comment Edited] (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=17783632#comment-17783632
]
Ekaterina Dimitrova edited comment on CASSANDRA-19001 at 11/7/23 1:52 PM:
--
{quote}{quote}FWIW none of this is probably blocker for beta release since
these are either existing or "unfixable" issues, but it would be a nice to have.
{quote}{quote}
I agree, as long as we clarify the chronicle part is not leading to some big
issues under the hood, we should be good
was (Author: e.dimitrova):
{quote}bq. FWIW none of this is probably blocker for beta release since these
are either existing or "unfixable" issues, but it would be a nice to have.
{quote}
I agree, as long as we clarify the chronicle part is not leading to some big
issues, we should be good
> 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
> Issue Type: Bug
> Components: Local/Other
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0-beta
>
>
> During the 5.0 alpha 2 release
> [vote|https://lists.apache.org/thread/lt3x0obr5cpbcydf5490pj6b2q0mz5zr],
> [~paulo] raised the following concerns:
> {code:java}
> Launched a tarball-based 5.0-alpha2 container on top of
> "eclipse-temurin:17-jre-focal" and the server starts up fine, can run
> nodetool and cqlsh.
> I got these seemingly harmless JDK17 warnings during startup and when
> running nodetool (no warnings on JDK11):
> WARNING: Unknown module: jdk.attach specified to --add-exports
> WARNING: Unknown module: jdk.compiler specified to --add-exports
> WARNING: Unknown module: jdk.compiler specified to --add-opens
> WARNING: A terminally deprecated method in java.lang.System has been called
> WARNING: System::setSecurityManager has been called by
> org.apache.cassandra.security.ThreadAwareSecurityManager
> (file:/opt/cassandra/lib/apache-cassandra-5.0-alpha2-SNAPSHOT.jar)
> WARNING: Please consider reporting this to the maintainers of
> org.apache.cassandra.security.ThreadAwareSecurityManager
> WARNING: System::setSecurityManager will be removed in a future release
> Anybody knows if these warnings are legit/expected ? We can create
> follow-up tickets if needed.
> $ java --version
> openjdk 17.0.9 2023-10-17
> OpenJDK Runtime Environment Temurin-17.0.9+9 (build 17.0.9+9)
> OpenJDK 64-Bit Server VM Temurin-17.0.9+9 (build 17.0.9+9, mixed mode,
> sharing)
> {code}
> {code:java}
> Clarification: - When running nodetool only the "Unknown module" warnings
> show up. All warnings show up during startup.{code}
> We need to verify whether this presents a real problem in the features where
> those modules are expected to be used, or if it is a false alarm.
>
--
This message was sent by Atlassian 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=17783632#comment-17783632
]
Ekaterina Dimitrova commented on CASSANDRA-19001:
-
{quote}bq. FWIW none of this is probably blocker for beta release since these
are either existing or "unfixable" issues, but it would be a nice to have.
{quote}
I agree, as long as we clarify the chronicle part is not leading to some big
issues, we should be good
> 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
> Issue Type: Bug
> Components: Local/Other
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0-beta
>
>
> During the 5.0 alpha 2 release
> [vote|https://lists.apache.org/thread/lt3x0obr5cpbcydf5490pj6b2q0mz5zr],
> [~paulo] raised the following concerns:
> {code:java}
> Launched a tarball-based 5.0-alpha2 container on top of
> "eclipse-temurin:17-jre-focal" and the server starts up fine, can run
> nodetool and cqlsh.
> I got these seemingly harmless JDK17 warnings during startup and when
> running nodetool (no warnings on JDK11):
> WARNING: Unknown module: jdk.attach specified to --add-exports
> WARNING: Unknown module: jdk.compiler specified to --add-exports
> WARNING: Unknown module: jdk.compiler specified to --add-opens
> WARNING: A terminally deprecated method in java.lang.System has been called
> WARNING: System::setSecurityManager has been called by
> org.apache.cassandra.security.ThreadAwareSecurityManager
> (file:/opt/cassandra/lib/apache-cassandra-5.0-alpha2-SNAPSHOT.jar)
> WARNING: Please consider reporting this to the maintainers of
> org.apache.cassandra.security.ThreadAwareSecurityManager
> WARNING: System::setSecurityManager will be removed in a future release
> Anybody knows if these warnings are legit/expected ? We can create
> follow-up tickets if needed.
> $ java --version
> openjdk 17.0.9 2023-10-17
> OpenJDK Runtime Environment Temurin-17.0.9+9 (build 17.0.9+9)
> OpenJDK 64-Bit Server VM Temurin-17.0.9+9 (build 17.0.9+9, mixed mode,
> sharing)
> {code}
> {code:java}
> Clarification: - When running nodetool only the "Unknown module" warnings
> show up. All warnings show up during startup.{code}
> We need to verify whether this presents a real problem in the features where
> those modules are expected to be used, or if it is a false alarm.
>
--
This message was sent by Atlassian 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-18993) Harry-found silent data loss issue
[ https://issues.apache.org/jira/browse/CASSANDRA-18993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Petrov updated CASSANDRA-18993: Description: Harry has discovered a silent data loss bug in trunk, but it goes all the way back to appx 4.1. Some rows are not visble after flush. Compared Harry repro running a memtable instead of a regular Harry model, and it still reproduces (in other words, it is almost certainly not a Harry issue). Simple schema, and only one flush is required for repro, so not an unlikely bug. Max partition size is 1k rows, so not an unlikely setup here, either. No concurrency involved; reproduces stably. Good chance this is related to the fact the schema has DESC clusterings. I am working on posting a Harry branch that stably reproduces it. was: Harry has discovered a silent data loss bug in trunk, but it goes all the way back to appx 4.1. Some rows are not visble after flush. Compared Harry repro running a memtable instead of a regular Harry model, and it still reproduces (in other words, it is almost certainly not a Harry issue). Simple schema, and only one flush is required for repro, so not an unlikely bug. Max partition size is 1k rows, so not an unlikely setup here, either. No concurrency involved; reproduces stably. Good chance this is related to the fact the schema has DESC clusterings. I am working on posting a Harry branch that stably reproduces it. > Harry-found silent data loss issue > -- > > Key: CASSANDRA-18993 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18993 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Core >Reporter: Alex Petrov >Assignee: Jacek Lewandowski >Priority: Normal > Fix For: 4.1.x, 5.0-beta, 5.x > > > Harry has discovered a silent data loss bug in trunk, but it goes all the way > back to appx 4.1. > Some rows are not visble after flush. Compared Harry repro running a memtable > instead of a regular Harry model, and it still reproduces (in other words, it > is almost certainly not a Harry issue). > Simple schema, and only one flush is required for repro, so not an unlikely > bug. Max partition size is 1k rows, so not an unlikely setup here, either. No > concurrency involved; reproduces stably. Good chance this is related to the > fact the schema has DESC clusterings. > I am working on posting a Harry branch that stably reproduces 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-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=17783631#comment-17783631
]
Ekaterina Dimitrova commented on CASSANDRA-19001:
-
https://chronicle.software/chronicle-support-java-17/
> 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
> Issue Type: Bug
> Components: Local/Other
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0-beta
>
>
> During the 5.0 alpha 2 release
> [vote|https://lists.apache.org/thread/lt3x0obr5cpbcydf5490pj6b2q0mz5zr],
> [~paulo] raised the following concerns:
> {code:java}
> Launched a tarball-based 5.0-alpha2 container on top of
> "eclipse-temurin:17-jre-focal" and the server starts up fine, can run
> nodetool and cqlsh.
> I got these seemingly harmless JDK17 warnings during startup and when
> running nodetool (no warnings on JDK11):
> WARNING: Unknown module: jdk.attach specified to --add-exports
> WARNING: Unknown module: jdk.compiler specified to --add-exports
> WARNING: Unknown module: jdk.compiler specified to --add-opens
> WARNING: A terminally deprecated method in java.lang.System has been called
> WARNING: System::setSecurityManager has been called by
> org.apache.cassandra.security.ThreadAwareSecurityManager
> (file:/opt/cassandra/lib/apache-cassandra-5.0-alpha2-SNAPSHOT.jar)
> WARNING: Please consider reporting this to the maintainers of
> org.apache.cassandra.security.ThreadAwareSecurityManager
> WARNING: System::setSecurityManager will be removed in a future release
> Anybody knows if these warnings are legit/expected ? We can create
> follow-up tickets if needed.
> $ java --version
> openjdk 17.0.9 2023-10-17
> OpenJDK Runtime Environment Temurin-17.0.9+9 (build 17.0.9+9)
> OpenJDK 64-Bit Server VM Temurin-17.0.9+9 (build 17.0.9+9, mixed mode,
> sharing)
> {code}
> {code:java}
> Clarification: - When running nodetool only the "Unknown module" warnings
> show up. All warnings show up during startup.{code}
> We need to verify whether this presents a real problem in the features where
> those modules are expected to be used, or if it is a false alarm.
>
--
This message was sent by Atlassian 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-18932) Harry-found CorruptSSTableException / RT Closer issue when reading entire partition
[
https://issues.apache.org/jira/browse/CASSANDRA-18932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17783620#comment-17783620
]
Alex Petrov edited comment on CASSANDRA-18932 at 11/7/23 1:45 PM:
--
Smallest (so far) harry-generated repro:
{code:java}
@Test
public void corruptedSStableDuringReadTest() throws Throwable
{
try (Cluster cluster = builder().withNodes(1)
.withConfig((cfg) -> {
cfg.set("memtable_heap_space",
"512MiB")
.set("column_index_size",
"1KiB");
})
.start())
{
String pk1 =
"ZinzDdUuABgDknItABgDknItABgDknItLhDJFhdNPpEzbCrpSdhqYCfuFeXzSfHt528523179230134153120";
long pk2 = 1607590537L;
cluster.schemaChange("CREATE KEYSPACE IF NOT EXISTS
distributed_test_keyspace WITH replication = {'class': 'SimpleStrategy',
'replication_factor': 1};");
cluster.schemaChange(" CREATE TABLE IF NOT EXISTS
distributed_test_keyspace.table_0 (pk1 ascii,pk2 bigint,ck1 ascii,ck2 ascii,v1
ascii, PRIMARY KEY ((pk1,pk2), ck1, ck2)) WITH CLUSTERING ORDER BY (ck1
DESC,ck2 DESC);");
cluster.coordinator(1).execute("INSERT INTO
distributed_test_keyspace.table_0 (pk1,pk2,ck1,ck2,v1) VALUES (?, ?, ?, ?, ?)
USING TIMESTAMP 2796;",
QUORUM, pk1, pk2,
"XhzszszswKvvPril160",
"XhzszszsBXILetSZ244040129141106771024413922120319382156215212185199207812444823206114747416170251137776288",
"PrqcApcjVlLUPnJu17810922624911817178133246422120325130151891112101812515729917023921424472071312417514176882215010117825115533215");
cluster.coordinator(1).execute("INSERT INTO
distributed_test_keyspace.table_0 (pk1,pk2,ck1,ck2) VALUES (?, ?, ?, ?) USING
TIMESTAMP 9673;",
QUORUM, pk1, pk2,
"XhzszszsvezsgWfS171636154115230246180242212216218139135122313202531842495455392072408614387177166104798029248115180250227",
"XhzszszsPMEZrail5620525123714624177220143195554265108125193170145424203102391711193243114123751720220922122616813119189727170246204240262481152314517235365183217118227135119132104");
cluster.coordinator(1).execute("INSERT INTO
distributed_test_keyspace.table_0 (pk1,pk2,ck1,ck2) VALUES (?, ?, ?, ?) USING
TIMESTAMP 2253;",
QUORUM, pk1, pk2,
"XhzszszsukgWaIRt119213342532141149997211120",
"XhzszszsKYwrbwjS4423671233187241841253408287917304019919636221282271552511886262224501472195223445254234164552508615225511022103174183165108145");
cluster.coordinator(1).execute("DELETE FROM
distributed_test_keyspace.table_0 USING TIMESTAMP 713 WHERE pk1 = ? AND pk2 = ?
AND ck1 = ? AND ck2 >= ? AND ck2 < ?;",
QUORUM, pk1, pk2,
"XhzszszsvezsgWfS171636154115230246180242212216218139135122313202531842495455392072408614387177166104798029248115180250227",
"XhzszszsPMEZrail5620525123714624177220143195554265108125193170145424203102391711193243114123751720220922122616813119189727170246204240262481152314517235365183217118227135119132104",
"XhzszszsuAPqXhcW651655711811739125249255921633060");
cluster.get(1).nodetool("flush", "distributed_test_keyspace",
"table_0");
Iterator iter =
cluster.coordinator(1).executeWithPaging("SELECT * FROM
distributed_test_keyspace.table_0 WHERE pk1 = ? AND pk2 = ?;",
QUORUM, 1, pk1, pk2);
while (iter.hasNext())
iter.next();
}
} {code}
was (Author: ifesdjeen):
Smallest (so far) harry-generated repro:
{code:java}
@Test
public void corruptedSStableDuringReadTest() throws Throwable
{
try (Cluster cluster = builder().withNodes(1)
.withConfig((cfg) -> {
cfg.set("memtable_heap_space",
"512MiB")
.set("column_index_size",
"1KiB");
})
.start())
{
String pk1 =
"ZinzDdUuABgDknItABgDknItABgDknItLhDJFhdNPpEzbCrpSdhqYCfuFeXzSfHt528523179230134153120";
long pk2 = 1607590537L;
cluster.schemaChange("CREATE KEYSPACE IF NOT EXISTS
distributed_test_keyspace WITH replication = {'class': 'SimpleStrategy',
'replication_factor': 1};");
cluster.schemaChange(" CREATE TABLE IF NOT EXISTS
distributed_test_keyspace.table_0 (pk1 ascii,pk2 bigint,ck1 ascii,ck2 ascii,v1
ascii, PRIMARY KEY ((pk1,pk2), ck1, ck2)) WITH CLUSTERING ORDER BY (ck1
DESC,ck2 DESC);");
cluster.coordinator(1).execute("INSERT
[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=17783630#comment-17783630
]
Ekaterina Dimitrova commented on CASSANDRA-19001:
-
I agree with you about sjk hh, but I think you missed that jdk.compiler modules
were added for chronicle queues, used by audit logging. While I did not see any
test failures when those were removed, I am not sure yet how chronicle relies
on them yet and whether we do not have a problem with a code path not exercised
in CI. That is something we need to clarify and I mentioned I am trying to do
that with the chronicle team.
> 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
> Issue Type: Bug
> Components: Local/Other
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0-beta
>
>
> During the 5.0 alpha 2 release
> [vote|https://lists.apache.org/thread/lt3x0obr5cpbcydf5490pj6b2q0mz5zr],
> [~paulo] raised the following concerns:
> {code:java}
> Launched a tarball-based 5.0-alpha2 container on top of
> "eclipse-temurin:17-jre-focal" and the server starts up fine, can run
> nodetool and cqlsh.
> I got these seemingly harmless JDK17 warnings during startup and when
> running nodetool (no warnings on JDK11):
> WARNING: Unknown module: jdk.attach specified to --add-exports
> WARNING: Unknown module: jdk.compiler specified to --add-exports
> WARNING: Unknown module: jdk.compiler specified to --add-opens
> WARNING: A terminally deprecated method in java.lang.System has been called
> WARNING: System::setSecurityManager has been called by
> org.apache.cassandra.security.ThreadAwareSecurityManager
> (file:/opt/cassandra/lib/apache-cassandra-5.0-alpha2-SNAPSHOT.jar)
> WARNING: Please consider reporting this to the maintainers of
> org.apache.cassandra.security.ThreadAwareSecurityManager
> WARNING: System::setSecurityManager will be removed in a future release
> Anybody knows if these warnings are legit/expected ? We can create
> follow-up tickets if needed.
> $ java --version
> openjdk 17.0.9 2023-10-17
> OpenJDK Runtime Environment Temurin-17.0.9+9 (build 17.0.9+9)
> OpenJDK 64-Bit Server VM Temurin-17.0.9+9 (build 17.0.9+9, mixed mode,
> sharing)
> {code}
> {code:java}
> Clarification: - When running nodetool only the "Unknown module" warnings
> show up. All warnings show up during startup.{code}
> We need to verify whether this presents a real problem in the features where
> those modules are expected to be used, or if it is a false alarm.
>
--
This message was sent by Atlassian 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-18932) Harry-found CorruptSSTableException / RT Closer issue when reading entire partition
[
https://issues.apache.org/jira/browse/CASSANDRA-18932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17783620#comment-17783620
]
Alex Petrov edited comment on CASSANDRA-18932 at 11/7/23 1:41 PM:
--
Smallest (so far) harry-generated repro:
{code:java}
@Test
public void corruptedSStableDuringReadTest() throws Throwable
{
try (Cluster cluster = builder().withNodes(1)
.withConfig((cfg) -> {
cfg.set("memtable_heap_space",
"512MiB")
.set("column_index_size",
"1KiB");
})
.start())
{
String pk1 =
"ZinzDdUuABgDknItABgDknItABgDknItLhDJFhdNPpEzbCrpSdhqYCfuFeXzSfHt528523179230134153120";
long pk2 = 1607590537L;
cluster.schemaChange("CREATE KEYSPACE IF NOT EXISTS
distributed_test_keyspace WITH replication = {'class': 'SimpleStrategy',
'replication_factor': 1};");
cluster.schemaChange(" CREATE TABLE IF NOT EXISTS
distributed_test_keyspace.table_0 (pk1 ascii,pk2 bigint,ck1 ascii,ck2 ascii,v1
ascii, PRIMARY KEY ((pk1,pk2), ck1, ck2)) WITH CLUSTERING ORDER BY (ck1
DESC,ck2 DESC);");
cluster.coordinator(1).execute("INSERT INTO
distributed_test_keyspace.table_0 (pk1,pk2,ck1,ck2,v1) VALUES (?, ?, ?, ?, ?)
TIMESTAMP 2796;",
QUORUM, pk1, pk2,
"XhzszszswKvvPril160",
"XhzszszsBXILetSZ244040129141106771024413922120319382156215212185199207812444823206114747416170251137776288",
"PrqcApcjVlLUPnJu17810922624911817178133246422120325130151891112101812515729917023921424472071312417514176882215010117825115533215");
cluster.coordinator(1).execute("INSERT INTO
distributed_test_keyspace.table_0 (pk1,pk2,ck1,ck2) VALUES (?, ?, ?, ?) USING
TIMESTAMP 9673;",
QUORUM, pk1, pk2,
"XhzszszsvezsgWfS171636154115230246180242212216218139135122313202531842495455392072408614387177166104798029248115180250227",
"XhzszszsPMEZrail5620525123714624177220143195554265108125193170145424203102391711193243114123751720220922122616813119189727170246204240262481152314517235365183217118227135119132104");
cluster.coordinator(1).execute("INSERT INTO
distributed_test_keyspace.table_0 (pk1,pk2,ck1,ck2) VALUES (?, ?, ?, ?) USING
TIMESTAMP 2253;",
QUORUM, pk1, pk2,
"XhzszszsukgWaIRt119213342532141149997211120",
"XhzszszsKYwrbwjS4423671233187241841253408287917304019919636221282271552511886262224501472195223445254234164552508615225511022103174183165108145");
cluster.coordinator(1).execute("DELETE FROM
distributed_test_keyspace.table_0 USING TIMESTAMP 713 WHERE pk1 = ? AND pk2 = ?
AND ck1 = ? AND ck2 >= ? AND ck2 < ?;",
QUORUM, pk1, pk2,
"XhzszszsvezsgWfS171636154115230246180242212216218139135122313202531842495455392072408614387177166104798029248115180250227",
"XhzszszsPMEZrail5620525123714624177220143195554265108125193170145424203102391711193243114123751720220922122616813119189727170246204240262481152314517235365183217118227135119132104",
"XhzszszsuAPqXhcW651655711811739125249255921633060");
cluster.get(1).nodetool("flush", "distributed_test_keyspace",
"table_0");
Iterator iter =
cluster.coordinator(1).executeWithPaging("SELECT * FROM
distributed_test_keyspace.table_0 WHERE pk1 = ? AND pk2 = ?;",
QUORUM, 1, pk1, pk2);
while (iter.hasNext())
iter.next();
}
} {code}
was (Author: ifesdjeen):
Smallest (so far) harry-generated repro:
{code:java}
@Test
public void corruptedSStableDuringReadTest() throws Throwable
{
try (Cluster cluster = builder().withNodes(1)
.withConfig((cfg) -> {
cfg.set("memtable_heap_space",
"512MiB")
.set("column_index_size",
"1KiB");
})
.start())
{
String pk1 =
"ZinzDdUuABgDknItABgDknItABgDknItLhDJFhdNPpEzbCrpSdhqYCfuFeXzSfHt528523179230134153120";
long pk2 = 1607590537L;
cluster.schemaChange("CREATE KEYSPACE IF NOT EXISTS
distributed_test_keyspace WITH replication = {'class': 'SimpleStrategy',
'replication_factor': 1};");
cluster.schemaChange(" CREATE TABLE IF NOT EXISTS
distributed_test_keyspace.table_0 (pk1 ascii,pk2 bigint,ck1 ascii,ck2 ascii,v1
ascii, PRIMARY KEY ((pk1,pk2), ck1, ck2)) WITH CLUSTERING ORDER BY (ck1
DESC,ck2 DESC);");
cluster.coordinator(1).execute("INSERT INTO
[jira] [Comment Edited] (CASSANDRA-18994) SAI range query does not play together with "IN"
[
https://issues.apache.org/jira/browse/CASSANDRA-18994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17783628#comment-17783628
]
Stefan Miklosovic edited comment on CASSANDRA-18994 at 11/7/23 1:40 PM:
I will remove myself from the reviewers as I think there are way more
knowledgeable people to fix / review this and my time may be spend on some
other urgent things. Thank you for all the effort!
was (Author: smiklosovic):
I will remove myself from the reviewers as I think there are way more
knowledgeable people to fix / review this and my time may be spend some other
urgent things. Thank you for all the effort!
> SAI range query does not play together with "IN"
>
>
> Key: CASSANDRA-18994
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18994
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/SAI
>Reporter: Stefan Miklosovic
>Assignee: Mike Adamson
>Priority: Normal
> Fix For: 5.0-beta
>
>
> I am using schema from the website's quickstart.
> {code}
> cqlsh> DESCRIBE KEYSPACE cycling ;
> CREATE KEYSPACE cycling WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> CREATE TABLE cycling.cyclist_semi_pro (
> id int PRIMARY KEY,
> affiliation text,
> age int,
> country text,
> firstname text,
> lastname text,
> registration date
> ) WITH additional_write_policy = '99p'
> AND allow_auto_snapshot = true
> AND bloom_filter_fp_chance = 0.01
> AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
> AND cdc = false
> AND comment = ''
> AND compaction = {'class':
> 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy',
> 'max_threshold': '32', 'min_threshold': '4'}
> AND compression = {'chunk_length_in_kb': '16', 'class':
> 'org.apache.cassandra.io.compress.LZ4Compressor'}
> AND memtable = 'default'
> AND crc_check_chance = 1.0
> AND default_time_to_live = 0
> AND extensions = {}
> AND gc_grace_seconds = 864000
> AND incremental_backups = true
> AND max_index_interval = 2048
> AND memtable_flush_period_in_ms = 0
> AND min_index_interval = 128
> AND read_repair = 'BLOCKING'
> AND speculative_retry = '99p';
> CREATE CUSTOM INDEX age_sai_idx ON cycling.cyclist_semi_pro (age) USING
> 'StorageAttachedIndex';
> CREATE CUSTOM INDEX country_sai_idx ON cycling.cyclist_semi_pro (country)
> USING 'StorageAttachedIndex' WITH OPTIONS = {'ascii': 'true',
> 'case_sensitive': 'false', 'normalize': 'true'};
> CREATE CUSTOM INDEX lastname_sai_idx ON cycling.cyclist_semi_pro (lastname)
> USING 'StorageAttachedIndex' WITH OPTIONS = {'ascii': 'true',
> 'case_sensitive': 'false', 'normalize': 'true'};
> CREATE CUSTOM INDEX registration_sai_idx ON cycling.cyclist_semi_pro
> (registration) USING 'StorageAttachedIndex';
> {code}
> Then I do:
> {code}
> cqlsh> SELECT * FROM cycling.cyclist_semi_pro WHERE lastname in ('Cantona',
> 'Boyd');
> InvalidRequest: Error from server: code=2200 [Invalid query] message="Cannot
> execute this query as it might involve data filtering and thus may have
> unpredictable performance. If you want to execute this query despite the
> performance unpredictability, use ALLOW FILTERING"
> cqlsh> SELECT * FROM cycling.cyclist_semi_pro WHERE lastname in ('Cantona',
> 'Boyd') ALLOW FILTERING;
> id | affiliation | age | country | firstname | lastname | registration
> +-+-+-+---+--+--
> 5 | Como Velocità | 24 | ITA | Irene | Cantona | 2012-07-22
> 20 | London Cyclists | 18 | GBR |Leslie | Boyd | 2012-12-15
> {code}
> But check this:
> {code}
> cqlsh> SELECT * FROM cycling.cyclist_semi_pro WHERE registration >
> '2010-01-01' AND registration < '2015-12-31' and lastname in ('Cantona',
> 'Boyd') allow filtering;
> ReadFailure: Error from server: code=1300 [Replica(s) failed to execute read]
> message="Operation failed - received 0 responses and 1 failures: UNKNOWN from
> localhost/127.0.0.1:7000" info={'consistency': 'ONE', 'required_responses':
> 1, 'received_responses': 0, 'failures': 1, 'error_code_map': {'127.0.0.1':
> '0x'}}
> {code}
> and in the logs:
> {code}
> java.lang.AssertionError: null
> at
> org.apache.cassandra.index.sai.plan.Expression.add(Expression.java:171)
> at
> org.apache.cassandra.index.sai.plan.Operation.buildIndexExpressions(Operation.java:136)
> at
> org.apache.cassandra.index.sai.plan.Operation$AndNode.analyze(Operation.java:303)
> at
> org.apache.cassandra.index.sai.plan.Operation$Node.doTreeAnalysis(Operation.java:266)
> at
>
[jira] [Updated] (CASSANDRA-18994) SAI range query does not play together with "IN"
[
https://issues.apache.org/jira/browse/CASSANDRA-18994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-18994:
--
Reviewers: Caleb Rackliffe, Maxwell Guo (was: Caleb Rackliffe, Maxwell
Guo, Stefan Miklosovic)
> SAI range query does not play together with "IN"
>
>
> Key: CASSANDRA-18994
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18994
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/SAI
>Reporter: Stefan Miklosovic
>Assignee: Mike Adamson
>Priority: Normal
> Fix For: 5.0-beta
>
>
> I am using schema from the website's quickstart.
> {code}
> cqlsh> DESCRIBE KEYSPACE cycling ;
> CREATE KEYSPACE cycling WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> CREATE TABLE cycling.cyclist_semi_pro (
> id int PRIMARY KEY,
> affiliation text,
> age int,
> country text,
> firstname text,
> lastname text,
> registration date
> ) WITH additional_write_policy = '99p'
> AND allow_auto_snapshot = true
> AND bloom_filter_fp_chance = 0.01
> AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
> AND cdc = false
> AND comment = ''
> AND compaction = {'class':
> 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy',
> 'max_threshold': '32', 'min_threshold': '4'}
> AND compression = {'chunk_length_in_kb': '16', 'class':
> 'org.apache.cassandra.io.compress.LZ4Compressor'}
> AND memtable = 'default'
> AND crc_check_chance = 1.0
> AND default_time_to_live = 0
> AND extensions = {}
> AND gc_grace_seconds = 864000
> AND incremental_backups = true
> AND max_index_interval = 2048
> AND memtable_flush_period_in_ms = 0
> AND min_index_interval = 128
> AND read_repair = 'BLOCKING'
> AND speculative_retry = '99p';
> CREATE CUSTOM INDEX age_sai_idx ON cycling.cyclist_semi_pro (age) USING
> 'StorageAttachedIndex';
> CREATE CUSTOM INDEX country_sai_idx ON cycling.cyclist_semi_pro (country)
> USING 'StorageAttachedIndex' WITH OPTIONS = {'ascii': 'true',
> 'case_sensitive': 'false', 'normalize': 'true'};
> CREATE CUSTOM INDEX lastname_sai_idx ON cycling.cyclist_semi_pro (lastname)
> USING 'StorageAttachedIndex' WITH OPTIONS = {'ascii': 'true',
> 'case_sensitive': 'false', 'normalize': 'true'};
> CREATE CUSTOM INDEX registration_sai_idx ON cycling.cyclist_semi_pro
> (registration) USING 'StorageAttachedIndex';
> {code}
> Then I do:
> {code}
> cqlsh> SELECT * FROM cycling.cyclist_semi_pro WHERE lastname in ('Cantona',
> 'Boyd');
> InvalidRequest: Error from server: code=2200 [Invalid query] message="Cannot
> execute this query as it might involve data filtering and thus may have
> unpredictable performance. If you want to execute this query despite the
> performance unpredictability, use ALLOW FILTERING"
> cqlsh> SELECT * FROM cycling.cyclist_semi_pro WHERE lastname in ('Cantona',
> 'Boyd') ALLOW FILTERING;
> id | affiliation | age | country | firstname | lastname | registration
> +-+-+-+---+--+--
> 5 | Como Velocità | 24 | ITA | Irene | Cantona | 2012-07-22
> 20 | London Cyclists | 18 | GBR |Leslie | Boyd | 2012-12-15
> {code}
> But check this:
> {code}
> cqlsh> SELECT * FROM cycling.cyclist_semi_pro WHERE registration >
> '2010-01-01' AND registration < '2015-12-31' and lastname in ('Cantona',
> 'Boyd') allow filtering;
> ReadFailure: Error from server: code=1300 [Replica(s) failed to execute read]
> message="Operation failed - received 0 responses and 1 failures: UNKNOWN from
> localhost/127.0.0.1:7000" info={'consistency': 'ONE', 'required_responses':
> 1, 'received_responses': 0, 'failures': 1, 'error_code_map': {'127.0.0.1':
> '0x'}}
> {code}
> and in the logs:
> {code}
> java.lang.AssertionError: null
> at
> org.apache.cassandra.index.sai.plan.Expression.add(Expression.java:171)
> at
> org.apache.cassandra.index.sai.plan.Operation.buildIndexExpressions(Operation.java:136)
> at
> org.apache.cassandra.index.sai.plan.Operation$AndNode.analyze(Operation.java:303)
> at
> org.apache.cassandra.index.sai.plan.Operation$Node.doTreeAnalysis(Operation.java:266)
> at
> org.apache.cassandra.index.sai.plan.Operation$Node.analyzeTree(Operation.java:251)
> at
> org.apache.cassandra.index.sai.plan.Operation.buildIterator(Operation.java:185)
> at
> org.apache.cassandra.index.sai.plan.StorageAttachedIndexSearcher$ResultRetriever.(StorageAttachedIndexSearcher.java:151)
> at
> org.apache.cassandra.index.sai.plan.StorageAttachedIndexSearcher.search(StorageAttachedIndexSearcher.java:107)
> at
>
[jira] [Commented] (CASSANDRA-18994) SAI range query does not play together with "IN"
[
https://issues.apache.org/jira/browse/CASSANDRA-18994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17783628#comment-17783628
]
Stefan Miklosovic commented on CASSANDRA-18994:
---
I will remove myself from the reviewers as I think there are way more
knowledgeable people to fix / review this and my time may be spend some other
urgent things. Thank you for all the effort!
> SAI range query does not play together with "IN"
>
>
> Key: CASSANDRA-18994
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18994
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/SAI
>Reporter: Stefan Miklosovic
>Assignee: Mike Adamson
>Priority: Normal
> Fix For: 5.0-beta
>
>
> I am using schema from the website's quickstart.
> {code}
> cqlsh> DESCRIBE KEYSPACE cycling ;
> CREATE KEYSPACE cycling WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> CREATE TABLE cycling.cyclist_semi_pro (
> id int PRIMARY KEY,
> affiliation text,
> age int,
> country text,
> firstname text,
> lastname text,
> registration date
> ) WITH additional_write_policy = '99p'
> AND allow_auto_snapshot = true
> AND bloom_filter_fp_chance = 0.01
> AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
> AND cdc = false
> AND comment = ''
> AND compaction = {'class':
> 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy',
> 'max_threshold': '32', 'min_threshold': '4'}
> AND compression = {'chunk_length_in_kb': '16', 'class':
> 'org.apache.cassandra.io.compress.LZ4Compressor'}
> AND memtable = 'default'
> AND crc_check_chance = 1.0
> AND default_time_to_live = 0
> AND extensions = {}
> AND gc_grace_seconds = 864000
> AND incremental_backups = true
> AND max_index_interval = 2048
> AND memtable_flush_period_in_ms = 0
> AND min_index_interval = 128
> AND read_repair = 'BLOCKING'
> AND speculative_retry = '99p';
> CREATE CUSTOM INDEX age_sai_idx ON cycling.cyclist_semi_pro (age) USING
> 'StorageAttachedIndex';
> CREATE CUSTOM INDEX country_sai_idx ON cycling.cyclist_semi_pro (country)
> USING 'StorageAttachedIndex' WITH OPTIONS = {'ascii': 'true',
> 'case_sensitive': 'false', 'normalize': 'true'};
> CREATE CUSTOM INDEX lastname_sai_idx ON cycling.cyclist_semi_pro (lastname)
> USING 'StorageAttachedIndex' WITH OPTIONS = {'ascii': 'true',
> 'case_sensitive': 'false', 'normalize': 'true'};
> CREATE CUSTOM INDEX registration_sai_idx ON cycling.cyclist_semi_pro
> (registration) USING 'StorageAttachedIndex';
> {code}
> Then I do:
> {code}
> cqlsh> SELECT * FROM cycling.cyclist_semi_pro WHERE lastname in ('Cantona',
> 'Boyd');
> InvalidRequest: Error from server: code=2200 [Invalid query] message="Cannot
> execute this query as it might involve data filtering and thus may have
> unpredictable performance. If you want to execute this query despite the
> performance unpredictability, use ALLOW FILTERING"
> cqlsh> SELECT * FROM cycling.cyclist_semi_pro WHERE lastname in ('Cantona',
> 'Boyd') ALLOW FILTERING;
> id | affiliation | age | country | firstname | lastname | registration
> +-+-+-+---+--+--
> 5 | Como Velocità | 24 | ITA | Irene | Cantona | 2012-07-22
> 20 | London Cyclists | 18 | GBR |Leslie | Boyd | 2012-12-15
> {code}
> But check this:
> {code}
> cqlsh> SELECT * FROM cycling.cyclist_semi_pro WHERE registration >
> '2010-01-01' AND registration < '2015-12-31' and lastname in ('Cantona',
> 'Boyd') allow filtering;
> ReadFailure: Error from server: code=1300 [Replica(s) failed to execute read]
> message="Operation failed - received 0 responses and 1 failures: UNKNOWN from
> localhost/127.0.0.1:7000" info={'consistency': 'ONE', 'required_responses':
> 1, 'received_responses': 0, 'failures': 1, 'error_code_map': {'127.0.0.1':
> '0x'}}
> {code}
> and in the logs:
> {code}
> java.lang.AssertionError: null
> at
> org.apache.cassandra.index.sai.plan.Expression.add(Expression.java:171)
> at
> org.apache.cassandra.index.sai.plan.Operation.buildIndexExpressions(Operation.java:136)
> at
> org.apache.cassandra.index.sai.plan.Operation$AndNode.analyze(Operation.java:303)
> at
> org.apache.cassandra.index.sai.plan.Operation$Node.doTreeAnalysis(Operation.java:266)
> at
> org.apache.cassandra.index.sai.plan.Operation$Node.analyzeTree(Operation.java:251)
> at
> org.apache.cassandra.index.sai.plan.Operation.buildIterator(Operation.java:185)
> at
> org.apache.cassandra.index.sai.plan.StorageAttachedIndexSearcher$ResultRetriever.(StorageAttachedIndexSearcher.java:151)
> at
>
[jira] [Comment Edited] (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=17783625#comment-17783625
]
Paulo Motta edited comment on CASSANDRA-19001 at 11/7/23 1:35 PM:
--
{quote}I do not see now the security manager warnings on startup, only on
compile.
{quote}
It's possible to reproduce this by running the official cassandra docker image
with:
{noformat}
$ docker run --name test --rm -it cassandra:5.0-alpha2
$ docker logs test | grep "WARNING:" | grep -v "Unknown"
{noformat}
But in fact it doesn't look like it's possible to disable this startup warning
according to [this
code|https://github.com/openjdk/jdk/blob/d22e368cb5dbd6812f1584c47c44b9b754a222af/src/java.base/share/classes/java/lang/System.java#L419].
I will maybe submit a openjdk ticket to allow this to be overriden when the
issue is known and is going to be addressed :)
Perhaps we could log a message before initializing the security manager on
JDK17 for users to ignore the Java ThreadAwareSecurityManager warning since
it's going to be addressed on CASSANDRA-18711 ? Not sure if that's really
needed or we can just ignore it for now :)
bq. 2) SJK cannot run sjk hh if not run with JDK.
It's possible to reproduce the SJK issue with the official 4.1 and 5.0 images,
so indeed this is not a new issue:
{noformat}
$ docker run --rm -it cassandra:latest nodetool sjk jps
$ docker run --rm -it cassandra:5.0-alpha2 nodetool sjk jps
{noformat}
But the "Uknown module" warnings show up on JRE17 even when running non-sjk
commands:
{noformat}
$ docker run --rm -it cassandra:5.0-alpha2 nodetool help
WARNING: Unknown module: jdk.attach specified to --add-exports
WARNING: Unknown module: jdk.compiler specified to --add-exports
WARNING: Unknown module: jdk.compiler specified to --add-opens
usage: nodetool [(-pwf | --password-file )]
[(-p | --port )] [(-h | --host )]
[(-pp | --print-port)] [(-pw | --password )]
[(-u | --username )] []
{noformat}
The warning above also shows up when launching the cassandra process:
{noformat}
$ docker run --name test --rm -it cassandra:5.0-alpha2
$ docker logs test | grep "WARNING: Unknown"
{noformat}
To me the JDK is an optional dependency only to support "nodetool sjk", but not
needed to run standard nodetool commands or cassandra server AFAIU (correct me
if wrong). So we could:
1) Remove the following optional lines from "jvm11-(client|server).options" and
"jvm17-(client|server).options".
{noformat}
--add-exports jdk.attach/sun.tools.attach=ALL-UNNAMED
--add-exports jdk.compiler/com.sun.tools.javac.file=ALL-UNNAMED
--add-opens jdk.compiler/com.sun.tools.javac=ALL-UNNAMED
{noformat}
2) Dynamically add these lines on cassandra-env.sh when a JDK is detected.
3) Print a friendly message when "nodetool sjk" is executed but no JDK is
present.
WDYT?
was (Author: paulo):
{quote}I do not see now the security manager warnings on startup, only on
compile.
{quote}
It's possible to reproduce this by running the official cassandra docker image
with:
{noformat}
$ docker run --name test --rm -it cassandra:5.0-alpha2
$ docker logs test | grep "WARNING:" | grep -v "Unknown"
{noformat}
But in fact it doesn't look like it's possible to disable this startup warning
according to [this
code|https://github.com/openjdk/jdk/blob/d22e368cb5dbd6812f1584c47c44b9b754a222af/src/java.base/share/classes/java/lang/System.java#L419].
I will maybe submit a openjdk ticket to allow this to be overriden when the
issue is known and is going to be addressed :)
Perhaps we could log a message before initializing the security manager on
JDK17 for users to ignore the Java ThreadAwareSecurityManager warning since
it's going to be addressed on CASSANDRA-18711 ? Not sure if that's really
needed or we can just ignore it for now :)
> 2) SJK cannot run sjk hh if not run with JDK.
It's possible to reproduce the SJK issue with the official 4.1 and 5.0 images,
so indeed this is not a new issue:
{noformat}
$ docker run --rm -it cassandra:latest nodetool sjk jps
$ docker run --rm -it cassandra:5.0-alpha2 nodetool sjk jps
{noformat}
But the "Uknown module" warnings show up on JRE17 even when running non-sjk
commands:
{noformat}
$ docker run --rm -it cassandra:5.0-alpha2 nodetool help
WARNING: Unknown module: jdk.attach specified to --add-exports
WARNING: Unknown module: jdk.compiler specified to --add-exports
WARNING: Unknown module: jdk.compiler specified to --add-opens
usage: nodetool [(-pwf | --password-file )]
[(-p | --port )] [(-h | --host )]
[(-pp | --print-port)] [(-pw | --password )]
[(-u | --username )] []
{noformat}
The warning above also shows up when launching the cassandra process:
{noformat}
$ docker run --name test --rm -it cassandra:5.0-alpha2
$ docker logs test | grep "WARNING: Unknown"
{noformat}
To me the JDK is an optional dependency only to support
[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=17783626#comment-17783626
]
Paulo Motta commented on CASSANDRA-19001:
-
FWIW none of this is probably blocker for beta release since these are either
existing or "unfixable" issues, but it would be a nice to have.
> 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
> Issue Type: Bug
> Components: Local/Other
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0-beta
>
>
> During the 5.0 alpha 2 release
> [vote|https://lists.apache.org/thread/lt3x0obr5cpbcydf5490pj6b2q0mz5zr],
> [~paulo] raised the following concerns:
> {code:java}
> Launched a tarball-based 5.0-alpha2 container on top of
> "eclipse-temurin:17-jre-focal" and the server starts up fine, can run
> nodetool and cqlsh.
> I got these seemingly harmless JDK17 warnings during startup and when
> running nodetool (no warnings on JDK11):
> WARNING: Unknown module: jdk.attach specified to --add-exports
> WARNING: Unknown module: jdk.compiler specified to --add-exports
> WARNING: Unknown module: jdk.compiler specified to --add-opens
> WARNING: A terminally deprecated method in java.lang.System has been called
> WARNING: System::setSecurityManager has been called by
> org.apache.cassandra.security.ThreadAwareSecurityManager
> (file:/opt/cassandra/lib/apache-cassandra-5.0-alpha2-SNAPSHOT.jar)
> WARNING: Please consider reporting this to the maintainers of
> org.apache.cassandra.security.ThreadAwareSecurityManager
> WARNING: System::setSecurityManager will be removed in a future release
> Anybody knows if these warnings are legit/expected ? We can create
> follow-up tickets if needed.
> $ java --version
> openjdk 17.0.9 2023-10-17
> OpenJDK Runtime Environment Temurin-17.0.9+9 (build 17.0.9+9)
> OpenJDK 64-Bit Server VM Temurin-17.0.9+9 (build 17.0.9+9, mixed mode,
> sharing)
> {code}
> {code:java}
> Clarification: - When running nodetool only the "Unknown module" warnings
> show up. All warnings show up during startup.{code}
> We need to verify whether this presents a real problem in the features where
> those modules are expected to be used, or if it is a false alarm.
>
--
This message was sent by Atlassian 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=17783625#comment-17783625
]
Paulo Motta commented on CASSANDRA-19001:
-
{quote}I do not see now the security manager warnings on startup, only on
compile.
{quote}
It's possible to reproduce this by running the official cassandra docker image
with:
{noformat}
$ docker run --name test --rm -it cassandra:5.0-alpha2
$ docker logs test | grep "WARNING:" | grep -v "Unknown"
{noformat}
But in fact it doesn't look like it's possible to disable this startup warning
according to [this
code|https://github.com/openjdk/jdk/blob/d22e368cb5dbd6812f1584c47c44b9b754a222af/src/java.base/share/classes/java/lang/System.java#L419].
I will maybe submit a openjdk ticket to allow this to be overriden when the
issue is known and is going to be addressed :)
Perhaps we could log a message before initializing the security manager on
JDK17 for users to ignore the Java ThreadAwareSecurityManager warning since
it's going to be addressed on CASSANDRA-18711 ? Not sure if that's really
needed or we can just ignore it for now :)
> 2) SJK cannot run sjk hh if not run with JDK.
It's possible to reproduce the SJK issue with the official 4.1 and 5.0 images,
so indeed this is not a new issue:
{noformat}
$ docker run --rm -it cassandra:latest nodetool sjk jps
$ docker run --rm -it cassandra:5.0-alpha2 nodetool sjk jps
{noformat}
But the "Uknown module" warnings show up on JRE17 even when running non-sjk
commands:
{noformat}
$ docker run --rm -it cassandra:5.0-alpha2 nodetool help
WARNING: Unknown module: jdk.attach specified to --add-exports
WARNING: Unknown module: jdk.compiler specified to --add-exports
WARNING: Unknown module: jdk.compiler specified to --add-opens
usage: nodetool [(-pwf | --password-file )]
[(-p | --port )] [(-h | --host )]
[(-pp | --print-port)] [(-pw | --password )]
[(-u | --username )] []
{noformat}
The warning above also shows up when launching the cassandra process:
{noformat}
$ docker run --name test --rm -it cassandra:5.0-alpha2
$ docker logs test | grep "WARNING: Unknown"
{noformat}
To me the JDK is an optional dependency only to support "nodetool sjk", but not
needed to run standard nodetool commands or cassandra server AFAIU (correct me
if wrong). So we could:
1) Remove the following optional lines from "jvm11-(client|server).options" and
"jvm17-(client|server).options".
{noformat}
--add-exports jdk.attach/sun.tools.attach=ALL-UNNAMED
--add-exports jdk.compiler/com.sun.tools.javac.file=ALL-UNNAMED
--add-opens jdk.compiler/com.sun.tools.javac=ALL-UNNAMED
{noformat}
2) Dynamically add these lines on cassandra-env.sh when a JDK is detected.
3) Print a friendly message when "nodetool sjk" is executed but no JDK is
present.
WDYT?
> 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
> Issue Type: Bug
> Components: Local/Other
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0-beta
>
>
> During the 5.0 alpha 2 release
> [vote|https://lists.apache.org/thread/lt3x0obr5cpbcydf5490pj6b2q0mz5zr],
> [~paulo] raised the following concerns:
> {code:java}
> Launched a tarball-based 5.0-alpha2 container on top of
> "eclipse-temurin:17-jre-focal" and the server starts up fine, can run
> nodetool and cqlsh.
> I got these seemingly harmless JDK17 warnings during startup and when
> running nodetool (no warnings on JDK11):
> WARNING: Unknown module: jdk.attach specified to --add-exports
> WARNING: Unknown module: jdk.compiler specified to --add-exports
> WARNING: Unknown module: jdk.compiler specified to --add-opens
> WARNING: A terminally deprecated method in java.lang.System has been called
> WARNING: System::setSecurityManager has been called by
> org.apache.cassandra.security.ThreadAwareSecurityManager
> (file:/opt/cassandra/lib/apache-cassandra-5.0-alpha2-SNAPSHOT.jar)
> WARNING: Please consider reporting this to the maintainers of
> org.apache.cassandra.security.ThreadAwareSecurityManager
> WARNING: System::setSecurityManager will be removed in a future release
> Anybody knows if these warnings are legit/expected ? We can create
> follow-up tickets if needed.
> $ java --version
> openjdk 17.0.9 2023-10-17
> OpenJDK Runtime Environment Temurin-17.0.9+9 (build 17.0.9+9)
> OpenJDK 64-Bit Server VM Temurin-17.0.9+9 (build 17.0.9+9, mixed mode,
> sharing)
> {code}
> {code:java}
> Clarification: - When running nodetool only the "Unknown module" warnings
> show up. All warnings show up during
[jira] [Commented] (CASSANDRA-18994) SAI range query does not play together with "IN"
[
https://issues.apache.org/jira/browse/CASSANDRA-18994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17783624#comment-17783624
]
Andres de la Peña commented on CASSANDRA-18994:
---
I understand that unsupported expressions should be *moved* to the post-index
row filter.
At the moment IN expressions are not put in the post-index row filter. Instead,
they are left in the index filter, producing the observed failure when they
cannot be converted into SAI expressions (in
{{{}org.apache.cassandra.index.sai.plan.Expression#add{}}}).
Custom expressions are put into the post-index row filter, but they are also
included in the index filter.
This tiny patch makes sure that unsupported expressions are only present in the
post-index row filter:
||patch||CI||
|[5.0|https://github.com/apache/cassandra/compare/trunk...adelapena:18994-5.0]|[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/3277/workflows/5acefc62-3c9d-4b5e-9f74-b4f5f29998cf]|
I don't know if CASSANDRA-18166 is going to address this.
> SAI range query does not play together with "IN"
>
>
> Key: CASSANDRA-18994
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18994
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/SAI
>Reporter: Stefan Miklosovic
>Assignee: Mike Adamson
>Priority: Normal
> Fix For: 5.0-beta
>
>
> I am using schema from the website's quickstart.
> {code}
> cqlsh> DESCRIBE KEYSPACE cycling ;
> CREATE KEYSPACE cycling WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> CREATE TABLE cycling.cyclist_semi_pro (
> id int PRIMARY KEY,
> affiliation text,
> age int,
> country text,
> firstname text,
> lastname text,
> registration date
> ) WITH additional_write_policy = '99p'
> AND allow_auto_snapshot = true
> AND bloom_filter_fp_chance = 0.01
> AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
> AND cdc = false
> AND comment = ''
> AND compaction = {'class':
> 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy',
> 'max_threshold': '32', 'min_threshold': '4'}
> AND compression = {'chunk_length_in_kb': '16', 'class':
> 'org.apache.cassandra.io.compress.LZ4Compressor'}
> AND memtable = 'default'
> AND crc_check_chance = 1.0
> AND default_time_to_live = 0
> AND extensions = {}
> AND gc_grace_seconds = 864000
> AND incremental_backups = true
> AND max_index_interval = 2048
> AND memtable_flush_period_in_ms = 0
> AND min_index_interval = 128
> AND read_repair = 'BLOCKING'
> AND speculative_retry = '99p';
> CREATE CUSTOM INDEX age_sai_idx ON cycling.cyclist_semi_pro (age) USING
> 'StorageAttachedIndex';
> CREATE CUSTOM INDEX country_sai_idx ON cycling.cyclist_semi_pro (country)
> USING 'StorageAttachedIndex' WITH OPTIONS = {'ascii': 'true',
> 'case_sensitive': 'false', 'normalize': 'true'};
> CREATE CUSTOM INDEX lastname_sai_idx ON cycling.cyclist_semi_pro (lastname)
> USING 'StorageAttachedIndex' WITH OPTIONS = {'ascii': 'true',
> 'case_sensitive': 'false', 'normalize': 'true'};
> CREATE CUSTOM INDEX registration_sai_idx ON cycling.cyclist_semi_pro
> (registration) USING 'StorageAttachedIndex';
> {code}
> Then I do:
> {code}
> cqlsh> SELECT * FROM cycling.cyclist_semi_pro WHERE lastname in ('Cantona',
> 'Boyd');
> InvalidRequest: Error from server: code=2200 [Invalid query] message="Cannot
> execute this query as it might involve data filtering and thus may have
> unpredictable performance. If you want to execute this query despite the
> performance unpredictability, use ALLOW FILTERING"
> cqlsh> SELECT * FROM cycling.cyclist_semi_pro WHERE lastname in ('Cantona',
> 'Boyd') ALLOW FILTERING;
> id | affiliation | age | country | firstname | lastname | registration
> +-+-+-+---+--+--
> 5 | Como Velocità | 24 | ITA | Irene | Cantona | 2012-07-22
> 20 | London Cyclists | 18 | GBR |Leslie | Boyd | 2012-12-15
> {code}
> But check this:
> {code}
> cqlsh> SELECT * FROM cycling.cyclist_semi_pro WHERE registration >
> '2010-01-01' AND registration < '2015-12-31' and lastname in ('Cantona',
> 'Boyd') allow filtering;
> ReadFailure: Error from server: code=1300 [Replica(s) failed to execute read]
> message="Operation failed - received 0 responses and 1 failures: UNKNOWN from
> localhost/127.0.0.1:7000" info={'consistency': 'ONE', 'required_responses':
> 1, 'received_responses': 0, 'failures': 1, 'error_code_map': {'127.0.0.1':
> '0x'}}
> {code}
> and in the logs:
> {code}
> java.lang.AssertionError: null
> at
> org.apache.cassandra.index.sai.plan.Expression.add(Expression.java:171)
>
[jira] [Comment Edited] (CASSANDRA-18932) Harry-found CorruptSSTableException / RT Closer issue when reading entire partition
[
https://issues.apache.org/jira/browse/CASSANDRA-18932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17783620#comment-17783620
]
Alex Petrov edited comment on CASSANDRA-18932 at 11/7/23 1:18 PM:
--
Smallest (so far) harry-generated repro:
{code:java}
@Test
public void corruptedSStableDuringReadTest() throws Throwable
{
try (Cluster cluster = builder().withNodes(1)
.withConfig((cfg) -> {
cfg.set("memtable_heap_space",
"512MiB")
.set("column_index_size",
"1KiB");
})
.start())
{
String pk1 =
"ZinzDdUuABgDknItABgDknItABgDknItLhDJFhdNPpEzbCrpSdhqYCfuFeXzSfHt528523179230134153120";
long pk2 = 1607590537L;
cluster.schemaChange("CREATE KEYSPACE IF NOT EXISTS
distributed_test_keyspace WITH replication = {'class': 'SimpleStrategy',
'replication_factor': 1};");
cluster.schemaChange(" CREATE TABLE IF NOT EXISTS
distributed_test_keyspace.table_0 (pk1 ascii,pk2 bigint,ck1 ascii,ck2 ascii,v1
ascii, PRIMARY KEY ((pk1,pk2), ck1, ck2)) WITH CLUSTERING ORDER BY (ck1
DESC,ck2 DESC);");
cluster.coordinator(1).execute("INSERT INTO
distributed_test_keyspace.table_0 (pk1,pk2,ck1,ck2,v1) VALUES (?, ?, ?, ?, ?)
TIMESTAMP 2796;",
QUORUM, pk1, pk2,
"XhzszszswKvvPril160",
"XhzszszsBXILetSZ244040129141106771024413922120319382156215212185199207812444823206114747416170251137776288",
"PrqcApcjVlLUPnJu17810922624911817178133246422120325130151891112101812515729917023921424472071312417514176882215010117825115533215");
cluster.coordinator(1).execute("INSERT INTO
distributed_test_keyspace.table_0 (pk1,pk2,ck1,ck2) VALUES (?, ?, ?, ?) USING
TIMESTAMP 9673;",
QUORUM, pk1, pk2,
"XhzszszsvezsgWfS171636154115230246180242212216218139135122313202531842495455392072408614387177166104798029248115180250227",
"XhzszszsPMEZrail5620525123714624177220143195554265108125193170145424203102391711193243114123751720220922122616813119189727170246204240262481152314517235365183217118227135119132104");
cluster.coordinator(1).execute("INSERT INTO
distributed_test_keyspace.table_0 (pk1,pk2,ck1,ck2) VALUES (?, ?, ?, ?) USING
TIMESTAMP 2253;",
QUORUM, pk1, pk2,
"XhzszszsukgWaIRt119213342532141149997211120",
"XhzszszsKYwrbwjS4423671233187241841253408287917304019919636221282271552511886262224501472195223445254234164552508615225511022103174183165108145");
cluster.coordinator(1).execute("DELETE FROM
distributed_test_keyspace.table_0 USING TIMESTAMP 713 WHERE pk1 = ? AND pk2 = ?
AND ck1 = ? AND ck2 >= ? AND ck2 < ?;",
QUORUM, pk1, pk2,
"XhzszszsvezsgWfS171636154115230246180242212216218139135122313202531842495455392072408614387177166104798029248115180250227",
"XhzszszsPMEZrail5620525123714624177220143195554265108125193170145424203102391711193243114123751720220922122616813119189727170246204240262481152314517235365183217118227135119132104",
"XhzszszsuAPqXhcW651655711811739125249255921633060");
cluster.get(1).nodetool("flush", "distributed_test_keyspace",
"table_0");
Iterator iter =
cluster.coordinator(1).executeWithPaging("SELECT * FROM
distributed_test_keyspace.tbl65 WHERE pk1 = ? AND pk2 = ?;",
QUORUM, 1, pk1, pk2);
while (iter.hasNext())
iter.next();
}
} {code}
was (Author: ifesdjeen):
Smallest (so far harry-generated repro):
{code:java}
@Test
public void corruptedSStableDuringReadTest() throws Throwable
{
try (Cluster cluster = builder().withNodes(1)
.withConfig((cfg) -> {
cfg.set("memtable_heap_space",
"512MiB")
.set("column_index_size",
"1KiB");
})
.start())
{
String pk1 =
"ZinzDdUuABgDknItABgDknItABgDknItLhDJFhdNPpEzbCrpSdhqYCfuFeXzSfHt528523179230134153120";
long pk2 = 1607590537L;
cluster.schemaChange("CREATE KEYSPACE IF NOT EXISTS
distributed_test_keyspace WITH replication = {'class': 'SimpleStrategy',
'replication_factor': 1};");
cluster.schemaChange(" CREATE TABLE IF NOT EXISTS
distributed_test_keyspace.table_0 (pk1 ascii,pk2 bigint,ck1 ascii,ck2 ascii,v1
ascii, PRIMARY KEY ((pk1,pk2), ck1, ck2)) WITH CLUSTERING ORDER BY (ck1
DESC,ck2 DESC);");
cluster.coordinator(1).execute("INSERT INTO
[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=17783621#comment-17783621
]
Ekaterina Dimitrova commented on CASSANDRA-19001:
-
Thanks,[~paulo] , appreciate it!
> 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
> Issue Type: Bug
> Components: Local/Other
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0-beta
>
>
> During the 5.0 alpha 2 release
> [vote|https://lists.apache.org/thread/lt3x0obr5cpbcydf5490pj6b2q0mz5zr],
> [~paulo] raised the following concerns:
> {code:java}
> Launched a tarball-based 5.0-alpha2 container on top of
> "eclipse-temurin:17-jre-focal" and the server starts up fine, can run
> nodetool and cqlsh.
> I got these seemingly harmless JDK17 warnings during startup and when
> running nodetool (no warnings on JDK11):
> WARNING: Unknown module: jdk.attach specified to --add-exports
> WARNING: Unknown module: jdk.compiler specified to --add-exports
> WARNING: Unknown module: jdk.compiler specified to --add-opens
> WARNING: A terminally deprecated method in java.lang.System has been called
> WARNING: System::setSecurityManager has been called by
> org.apache.cassandra.security.ThreadAwareSecurityManager
> (file:/opt/cassandra/lib/apache-cassandra-5.0-alpha2-SNAPSHOT.jar)
> WARNING: Please consider reporting this to the maintainers of
> org.apache.cassandra.security.ThreadAwareSecurityManager
> WARNING: System::setSecurityManager will be removed in a future release
> Anybody knows if these warnings are legit/expected ? We can create
> follow-up tickets if needed.
> $ java --version
> openjdk 17.0.9 2023-10-17
> OpenJDK Runtime Environment Temurin-17.0.9+9 (build 17.0.9+9)
> OpenJDK 64-Bit Server VM Temurin-17.0.9+9 (build 17.0.9+9, mixed mode,
> sharing)
> {code}
> {code:java}
> Clarification: - When running nodetool only the "Unknown module" warnings
> show up. All warnings show up during startup.{code}
> We need to verify whether this presents a real problem in the features where
> those modules are expected to be used, or if it is a false alarm.
>
--
This message was sent by Atlassian 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-18932) Harry-found CorruptSSTableException / RT Closer issue when reading entire partition
[
https://issues.apache.org/jira/browse/CASSANDRA-18932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17783620#comment-17783620
]
Alex Petrov commented on CASSANDRA-18932:
-
Smallest (so far harry-generated repro):
{code:java}
@Test
public void corruptedSStableDuringReadTest() throws Throwable
{
try (Cluster cluster = builder().withNodes(1)
.withConfig((cfg) -> {
cfg.set("memtable_heap_space",
"512MiB")
.set("column_index_size",
"1KiB");
})
.start())
{
String pk1 =
"ZinzDdUuABgDknItABgDknItABgDknItLhDJFhdNPpEzbCrpSdhqYCfuFeXzSfHt528523179230134153120";
long pk2 = 1607590537L;
cluster.schemaChange("CREATE KEYSPACE IF NOT EXISTS
distributed_test_keyspace WITH replication = {'class': 'SimpleStrategy',
'replication_factor': 1};");
cluster.schemaChange(" CREATE TABLE IF NOT EXISTS
distributed_test_keyspace.table_0 (pk1 ascii,pk2 bigint,ck1 ascii,ck2 ascii,v1
ascii, PRIMARY KEY ((pk1,pk2), ck1, ck2)) WITH CLUSTERING ORDER BY (ck1
DESC,ck2 DESC);");
cluster.coordinator(1).execute("INSERT INTO
distributed_test_keyspace.table_0 (pk1,pk2,ck1,ck2,v1) VALUES (?, ?, ?, ?, ?)
TIMESTAMP 2796;",
QUORUM, pk1, pk2,
"XhzszszswKvvPril160",
"XhzszszsBXILetSZ244040129141106771024413922120319382156215212185199207812444823206114747416170251137776288",
"PrqcApcjVlLUPnJu17810922624911817178133246422120325130151891112101812515729917023921424472071312417514176882215010117825115533215");
cluster.coordinator(1).execute("INSERT INTO
distributed_test_keyspace.table_0 (pk1,pk2,ck1,ck2) VALUES (?, ?, ?, ?) USING
TIMESTAMP 9673;",
QUORUM, pk1, pk2,
"XhzszszsvezsgWfS171636154115230246180242212216218139135122313202531842495455392072408614387177166104798029248115180250227",
"XhzszszsPMEZrail5620525123714624177220143195554265108125193170145424203102391711193243114123751720220922122616813119189727170246204240262481152314517235365183217118227135119132104");
cluster.coordinator(1).execute("INSERT INTO
distributed_test_keyspace.table_0 (pk1,pk2,ck1,ck2) VALUES (?, ?, ?, ?) USING
TIMESTAMP 2253;",
QUORUM, pk1, pk2,
"XhzszszsukgWaIRt119213342532141149997211120",
"XhzszszsKYwrbwjS4423671233187241841253408287917304019919636221282271552511886262224501472195223445254234164552508615225511022103174183165108145");
cluster.coordinator(1).execute("DELETE FROM
distributed_test_keyspace.table_0 USING TIMESTAMP 713 WHERE pk1 = ? AND pk2 = ?
AND ck1 = ? AND ck2 >= ? AND ck2 < ?;",
QUORUM, pk1, pk2,
"XhzszszsvezsgWfS171636154115230246180242212216218139135122313202531842495455392072408614387177166104798029248115180250227",
"XhzszszsPMEZrail5620525123714624177220143195554265108125193170145424203102391711193243114123751720220922122616813119189727170246204240262481152314517235365183217118227135119132104",
"XhzszszsuAPqXhcW651655711811739125249255921633060");
cluster.get(1).nodetool("flush", "distributed_test_keyspace",
"table_0");
Iterator iter =
cluster.coordinator(1).executeWithPaging("SELECT * FROM
distributed_test_keyspace.tbl65 WHERE pk1 = ? AND pk2 = ?;",
QUORUM, 1, pk1, pk2);
while (iter.hasNext())
iter.next();
}
} {code}
> Harry-found CorruptSSTableException / RT Closer issue when reading entire
> partition
> ---
>
> Key: CASSANDRA-18932
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18932
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
>Reporter: Alex Petrov
>Assignee: Maxim Muzafarov
>Priority: Normal
> Fix For: 5.0-beta, 5.0.x, 5.x
>
> Attachments: node1_.zip, operation.log.zip, screenshot-1.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> While testing some new machinery for Harry, I have encountered a new RT
> closer / SSTable Corruption issue. I have grounds to believe this was
> introduced during the last year.
> Issue seems to happen because of intricate interleaving of flushes with
> writes and deletes.
> {code:java}
> ERROR [ReadStage-2] 2023-10-16 18:47:06,696 JVMStabilityInspector.java:76 -
> Exception in thread Thread[ReadStage-2,5,SharedPool]
> org.apache.cassandra.io.sstable.CorruptSSTableException: Corrupted:
>
[jira] [Comment Edited] (CASSANDRA-19002) Create / update tests to ensure commit logs and hints for all versions in MS are ingestible in 5.0
[ https://issues.apache.org/jira/browse/CASSANDRA-19002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17783608#comment-17783608 ] Stefan Miklosovic edited comment on CASSANDRA-19002 at 11/7/23 12:43 PM: - The patch will consist of these parts: in 3.0, 3.11, 4.0, 4.1, 5.0 and trunk, there will be "HintsMaker" class added which is used for hints generation. Its behavior is logically very similar to what CommitLogUpgradeTestMaker is currently doing. Hence we will have a way how to generate hint files and commit logs programmatically. Then, in 5.0 and trunk, there will be tests added into CommitLogUpgradeTest which is already there but it covers only commit logs replay for Cassandra 3.4. 3.0.13 for 3.0, 3.0.29 for 3.0.14, 4.0.11 for 4.0 Also, in 5.0 and trunk, there will be HintsUpgradeTest added which will verify the deserialisation of hints generated in the latest 3.0 release as well as these in the latest 4.0 release (4.0.11 at the moment). There are 3 versions of hint files at the moment, 1, 2, and 3. 1 is used up to 4.0 excluded, 2 is used up to 5.0 excluded, 3 is used from 5.0 up. Hence, it does not make sense to verify that Cassandra 5.0 can read its own hint files, we will go just with version 1 and version 2 of hint files for 5.0 and trunk branches. was (Author: smiklosovic): The patch will consist of these parts: in 3.0, 3.11, 4.0, 4.1, 5.0 and trunk, there will be "HintsMaker" class added which is used for hints generation. Its behavior is logically very similar to what CommitLogUpgradeTestMaker is currently doing. Hence we will have a way how to generate hint files and commit logs programmatically. Then, in 5.0 and trunk, there will be tests added into CommitLogUpgradeTest which is already there but it covers only commit logs replay for Cassandra 3.4. Also, in 5.0 and trunk, there will be HintsUpgradeTest added which will verify the deserialisation of hints generated in the latest 3.0 release as well as these in the latest 4.0 release (4.0.11 at the moment). There are 3 versions of hint files at the moment, 1, 2, and 3. 1 is used up to 4.0 excluded, 2 is used up to 5.0 excluded, 3 is used from 5.0 up. Hence, it does not make sense to verify that Cassandra 5.0 can read its own hint files, we will go just with version 1 and version 2 of hint files for 5.0 and trunk branches. > Create / update tests to ensure commit logs and hints for all versions in MS > are ingestible in 5.0 > -- > > Key: CASSANDRA-19002 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19002 > Project: Cassandra > Issue Type: Task > Components: Test/unit >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 5.0-beta, 5.x > > Time Spent: 20m > Remaining Estimate: 0h > > This is follow up of CASSANDRA-18314 -- This message was sent by Atlassian 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-19002) Create / update tests to ensure commit logs and hints for all versions in MS are ingestible in 5.0
[ https://issues.apache.org/jira/browse/CASSANDRA-19002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17783608#comment-17783608 ] Stefan Miklosovic commented on CASSANDRA-19002: --- The patch will consist of these parts: in 3.0, 3.11, 4.0, 4.1, 5.0 and trunk, there will be "HintsMaker" class added which is used for hints generation. Its behavior is logically very similar to what CommitLogUpgradeTestMaker is currently doing. Hence we will have a way how to generate hint files and commit logs programmatically. Then, in 5.0 and trunk, there will be tests added into CommitLogUpgradeTest which is already there but it covers only commit logs replay for Cassandra 3.4. Also, in 5.0 and trunk, there will be HintsUpgradeTest added which will verify the deserialisation of hints generated in the latest 3.0 release as well as these in the latest 4.0 release (4.0.11 at the moment). There are 3 versions of hint files at the moment, 1, 2, and 3. 1 is used up to 4.0 excluded, 2 is used up to 5.0 excluded, 3 is used from 5.0 up. Hence, it does not make sense to verify that Cassandra 5.0 can read its own hint files, we will go just with version 1 and version 2 of hint files for 5.0 and trunk branches. > Create / update tests to ensure commit logs and hints for all versions in MS > are ingestible in 5.0 > -- > > Key: CASSANDRA-19002 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19002 > Project: Cassandra > Issue Type: Task > Components: Test/unit >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 5.0-beta, 5.x > > Time Spent: 20m > Remaining Estimate: 0h > > This is follow up of CASSANDRA-18314 -- This message was sent by Atlassian 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-18945) Unified Compaction Strategy is creating too many sstables
[
https://issues.apache.org/jira/browse/CASSANDRA-18945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17783517#comment-17783517
]
Stefan Miklosovic edited comment on CASSANDRA-18945 at 11/7/23 12:31 PM:
-
So ... this is interesting. It fails the multiplexer of
j17_jvm_dtests_vnode_repeat as well as the individual test in
j17_jvm_dtests_vnode
What is interesting is that it does not fail j17_jvm_dtests_repeat (without
vnode).
java17_separate_tests which runs j17_jvm_dtests_vnode does not fail it either.
I am trying to run j17_jvm_dtests_vnode_repeat for java17_separate_tests if it
indeed fails there too.
This is the PR against trunk.
This is the branch (2)
(1)
https://app.circleci.com/pipelines/github/instaclustr/cassandra/3443/workflows/97bfb70b-146a-4da8-afaf-7f5909b0492d
(2) https://github.com/instaclustr/cassandra/commits/CASSANDRA-18945-trunk
EDIT: Yes, j17_jvm_dtests_vnode_repeat on j17 separate tests fails multiplexer
too.
That test is flaky and has to be reworked.
was (Author: smiklosovic):
So ... this is interesting. It fails the multiplexer of
j17_jvm_dtests_vnode_repeat as well as the individual test in
j17_jvm_dtests_vnode
What is interesting is that it does not fail j17_jvm_dtests_repeat (without
vnode).
java17_separate_tests which runs j17_jvm_dtests_vnode does not fail it either.
I am trying to run j17_jvm_dtests_vnode_repeat for java17_separate_tests if it
indeed fails there too.
This is the PR against trunk.
This is the branch (2)
(1)
https://app.circleci.com/pipelines/github/instaclustr/cassandra/3443/workflows/97bfb70b-146a-4da8-afaf-7f5909b0492d
(2) https://github.com/instaclustr/cassandra/commits/CASSANDRA-18945-trunk
> Unified Compaction Strategy is creating too many sstables
> -
>
> Key: CASSANDRA-18945
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18945
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Compaction
>Reporter: Branimir Lambov
>Assignee: Ethan Brown
>Priority: Normal
> Fix For: 5.0-beta
>
> Attachments: file_ucs_shenandoah.html, file_ucs_shenandoah_3.html,
> file_ucs_shenandoah_off_heap_memtable.html,
> file_ucs_shenandoah_on_heap_memtable_2.html,
> file_ucs_shenandoah_on_heap_memtable_3.html, key-value-oss.html
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> The unified compaction strategy currently aims to create sstables with close
> to the same size, defaulting to 1 GiB. Unfortunately tests show that
> Cassandra starts to have performance problems when the number of sstables
> grows to the order of a thousand, and in particular that even 1 TiB of data
> with the default configuration is creating too many sstables for efficient
> processing. This matters even more for SAI, where the number of sstables in
> the system can have a proportional effect on the complexity of operations.
> It is quite easy to create a configuration option that allows sstables to
> take some part of the data growth by adding a multiplier to [the shard count
> calculation|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/compaction/UnifiedCompactionStrategy.md#sharding]
> formula, replacing
> {{2 ^ round(log2(d / (t * b))) * b}}
> with
> {{2 ^ round((1 - 휆) * log2(d / (t * b))) * b}},
> where 휆 is a parameter whose value is between 0 and 1.
> With this, a 휆 of 0.5 would mean that shard count and sstable size grow in
> parallel at the square root of the data size growth. 0 would result in no
> growth, and 1 in always using the same number of shards.
> It may also be valuable to introduce a threshold for engaging the base shard
> count to avoid splitting lowest-level sstables into fragments that are too
> small.
> Once both of these are in place, we can set defaults that better suit all
> node densities, including 10 TiB and beyond, for example:
> - target size of 1 GiB
> - 휆 of 1/3
> - base shard count of 4
> - minimum size 100 MiB
--
This message was sent by Atlassian 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-18611) java-driver donation
[ https://issues.apache.org/jira/browse/CASSANDRA-18611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-18611: --- Component/s: Client/java-driver (was: Messaging/Client) > java-driver donation > > > Key: CASSANDRA-18611 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18611 > Project: Cassandra > Issue Type: Task > Components: Client/java-driver >Reporter: Michael Semb Wever >Priority: Normal > > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-8%3A+Datastax+Drivers+Donation > IP Clearance: > https://incubator.apache.org/ip-clearance/cassandra-java-driver.html -- This message was sent by Atlassian 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 (c34b41fc3 -> e2af07208)
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 c34b41fc3 generate docs for a69b82d6
add c22fdf621 Add Cassandra Meetup Organizer Handbook and Events Approval
Checklist pages
new e2af07208 generate docs for c22fdf62
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 (c34b41fc3)
\
N -- N -- N refs/heads/asf-staging (e2af07208)
You should already have received notification emails for all of the O
revisions, and so the following emails describe only the N revisions
from the common base, B.
Any revisions marked "omit" are not gone; other references still
refer to them. Any revisions marked "discard" are gone forever.
The 1 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails. The revisions
listed as "add" were already present in the repository and have only
been added to this reference.
Summary of changes:
content/_/events.html | 2 +-
.../approval-checklist.html} | 131 +++---
.../organizer-handbook.html} | 464 ++---
content/search-index.js| 2 +-
.../ROOT/pages/events/approval-checklist.adoc | 53 +++
.../ROOT/pages/events/organizer-handbook.adoc | 106 +
site-ui/build/ui-bundle.zip| Bin 4881412 -> 4881543
bytes
site-ui/src/layouts/events.hbs | 2 +-
8 files changed, 362 insertions(+), 398 deletions(-)
copy content/_/{development/gettingstarted.html =>
events/approval-checklist.html} (76%)
copy content/_/{development/how_to_commit.html =>
events/organizer-handbook.html} (52%)
create mode 100644
site-content/source/modules/ROOT/pages/events/approval-checklist.adoc
create mode 100644
site-content/source/modules/ROOT/pages/events/organizer-handbook.adoc
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-18993) Harry-found silent data loss issue
[ https://issues.apache.org/jira/browse/CASSANDRA-18993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacek Lewandowski reassigned CASSANDRA-18993: - Assignee: Jacek Lewandowski > Harry-found silent data loss issue > -- > > Key: CASSANDRA-18993 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18993 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Core >Reporter: Alex Petrov >Assignee: Jacek Lewandowski >Priority: Normal > Fix For: 4.1.x, 5.0-beta, 5.x > > > Harry has discovered a silent data loss bug in trunk, but it goes all the way > back to appx 4.1. > Some rows are not visble after flush. Compared Harry repro running a memtable > instead of a regular Harry model, and it still reproduces (in other words, it > is almost certainly not a Harry issue). > Simple schema, and only one flush is required for repro, so not an unlikely > bug. Max partition size is 1k rows, so not an unlikely setup here, either. No > concurrency involved; reproduces stably. Good chance this is related to the > fact the schema has DESC clusterings. > I am working on posting a Harry branch that stably reproduces 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-18899) WEBSITE - Add Meetup Organizer Handbook and Events Approval Checklist pages
[ https://issues.apache.org/jira/browse/CASSANDRA-18899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-18899: --- Status: Ready to Commit (was: Review In Progress) > WEBSITE - Add Meetup Organizer Handbook and Events Approval Checklist pages > --- > > Key: CASSANDRA-18899 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18899 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Diogenese Topper >Priority: Normal > Attachments: > raw.githack.com_nonstopdtop_cassandra-website_CASSANDRA-18899_generated_content___events.html.png, > > raw.githack.com_nonstopdtop_cassandra-website_CASSANDRA-18899_generated_content___events_approval-checklist.html.png, > > raw.githack.com_nonstopdtop_cassandra-website_CASSANDRA-18899_generated_content___events_organizer-handbook.html.png, > > raw.githack.com_nonstopdtop_cassandra-website_meetup-and-events_generated_content___events_approval-checklist.html.png > > > This ticket is to capture the work associated with adding the Meetup > Organizer Handbook and Events Approval Checklist pages to the website. -- This message was sent by Atlassian 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-18899) WEBSITE - Add Meetup Organizer Handbook and Events Approval Checklist pages
[ https://issues.apache.org/jira/browse/CASSANDRA-18899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-18899: --- Fix Version/s: NA Source Control Link: https://github.com/apache/cassandra-website/commit/c22fdf621b7e1ea7e5c6b2d76e7de5d1e8cb023b Resolution: Fixed Status: Resolved (was: Ready to Commit) Committed as https://github.com/apache/cassandra-website/commit/c22fdf621b7e1ea7e5c6b2d76e7de5d1e8cb023b > WEBSITE - Add Meetup Organizer Handbook and Events Approval Checklist pages > --- > > Key: CASSANDRA-18899 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18899 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Diogenese Topper >Priority: Normal > Fix For: NA > > Attachments: > raw.githack.com_nonstopdtop_cassandra-website_CASSANDRA-18899_generated_content___events.html.png, > > raw.githack.com_nonstopdtop_cassandra-website_CASSANDRA-18899_generated_content___events_approval-checklist.html.png, > > raw.githack.com_nonstopdtop_cassandra-website_CASSANDRA-18899_generated_content___events_organizer-handbook.html.png, > > raw.githack.com_nonstopdtop_cassandra-website_meetup-and-events_generated_content___events_approval-checklist.html.png > > > This ticket is to capture the work associated with adding the Meetup > Organizer Handbook and Events Approval Checklist pages to the website. -- This message was sent by Atlassian 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 trunk updated: Add Cassandra Meetup Organizer Handbook and Events Approval Checklist pages
This is an automated email from the ASF dual-hosted git repository.
mck pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra-website.git
The following commit(s) were added to refs/heads/trunk by this push:
new c22fdf621 Add Cassandra Meetup Organizer Handbook and Events Approval
Checklist pages
c22fdf621 is described below
commit c22fdf621b7e1ea7e5c6b2d76e7de5d1e8cb023b
Author: Diogenese Topper <83248625+nonstopd...@users.noreply.github.com>
AuthorDate: Mon Oct 30 16:35:06 2023 -0700
Add Cassandra Meetup Organizer Handbook and Events Approval Checklist pages
patch by Diogenese Topper; reviewed by Mick Semb Wever for CASSANDRA-18899
---
.../ROOT/pages/events/approval-checklist.adoc | 53 +++
.../ROOT/pages/events/organizer-handbook.adoc | 106 +
site-ui/src/layouts/events.hbs | 2 +-
3 files changed, 160 insertions(+), 1 deletion(-)
diff --git
a/site-content/source/modules/ROOT/pages/events/approval-checklist.adoc
b/site-content/source/modules/ROOT/pages/events/approval-checklist.adoc
new file mode 100644
index 0..b798be9ba
--- /dev/null
+++ b/site-content/source/modules/ROOT/pages/events/approval-checklist.adoc
@@ -0,0 +1,53 @@
+= Events Approval Checklist
+:page-layout: basic
+:page-role: event-approval-checklist
+:description: Checklist for getting your Apache Cassandra® event approved by
the PMC
+
+All Apache Cassandra® events must be approved by the Cassandra PMC. To obtain
approval, make sure you have familiarized yourself with the
https://apache.org/foundation/marks/events.html[Third-Party Event Branding
Policy^] and the https://apache.org/foundation/marks/guide[Apache Product Name
Usage Guide^], and provided all the details in the checklist below to the PMC
via email at mailto:priv...@cassandra.apache.org[priv...@cassandra.apache.org^].
+
+_The Apache Cassandra PMC reserves the right to withdraw event approval under
reasonable circumstances._
+
+**Format & content**
+
+* Provide details on the format of the event (number of tracks, length of
talks, types of talks, etc.)
+* Outline the agenda
+* Include representatives from the
https://cassandra.apache.org/_/community.html#meet-the-community[PMC] on your
selection team
+* Provide details on how you will be selecting speakers
+
+**Trademark Compliance**
+
+* Highlight how Apache and third-party products are being covered in the
content - an event about an Apache product must include some sessions and
lessons that can apply to the core download without needing third-party products
+* Include and provide details of the event's anti-harassment policy - this
must be identical to the
https://apache.org/foundation/policies/anti-harassment.html[ASF anti-harassment
policy^] or an approved alternative.
+* Feature prominent attributions of all Apache marks and products used
+* Link the text “Apache Software Foundation” to http://www.apache.org
+* The first use of Apache Cassandra must use the full product name and be
followed by the ® symbol. The same applies to any usage of the product name in
page titles or email subjects.
+* Include a prominent description of the appropriate Apache product
+* Review and comply with the
https://apache.org/foundation/marks/events.html[Third-Party Event Branding
Policy^]
+* Review and comply with the https://apache.org/foundation/marks/guide[Apache
Product Name Usage Guide^]
+* Do not include any Apache or Apache product branding directly in your event
branding
+
+**Email template**
+
+You can use this as a template for writing an email to the PMC for event
approval:
+
+—
+
+I would like to kindly request the PMC's approval for my upcoming
{In-Person|Online} event.
+
+My event, {EVENT NAME}, is set to take place on {DATE}. It will be focused on
Apache Cassandra and will take the following format:
+
+{Briefly explain the event format - include things like the number of tracks,
length of the talks, types of talks, and whether the event will be online or
in-person}
+
+The event {Landing/Registration} page is visible at the following URL: {EVENT
URL}
+
+Here is an outline of the agenda that we are expecting to follow:
+
+{Provide as much detail about the agenda as you have at this stage - make sure
to highlight how you will be covering Apache products in your content}
+
+We will be selecting speakers in the following manner:
+
+{Provide details of your CFP and any processes you plan on implementing for
speaker selection, indicating who will be involved in selecting speakers}
+
+We will abide by all Apache trademark and branding guidelines and will include
the ASF anti-harassment policy in our event materials.
+
+—
\ No newline at end of file
diff --git
a/site-content/source/modules/ROOT/pages/events/organizer-handbook.adoc
b/site-content/source/modules/ROOT/pages/events/organizer-handbook.adoc
new file mode 100644
index 0..daabeb9d7
--- /dev/null
+++
[jira] [Updated] (CASSANDRA-18166) Improve the code model around IndexContext
[ https://issues.apache.org/jira/browse/CASSANDRA-18166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Adamson updated CASSANDRA-18166: - Change Category: Operability Complexity: Normal Status: Open (was: Triage Needed) > Improve the code model around IndexContext > -- > > Key: CASSANDRA-18166 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18166 > Project: Cassandra > Issue Type: Improvement > Components: Feature/SAI >Reporter: Mike Adamson >Assignee: Mike Adamson >Priority: Normal > Labels: SAI > > We currently have a situation where we need to create an IndexContext that is > for a non-indexed column and therefore is never going to be used for indexing > or searching. This results in the IndexContext having to check for this at > points in the code with assertions. The reason for this that, even when the > column is non-indexed, we need to have information about the column for the > purpose of post-filtering. > It would make sense to split out the column / index information needed for > filtering from the indexing / searching requirements such that we could avoid > unnecessary assertions in the code. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18731) Add declarative root CI structure
[
https://issues.apache.org/jira/browse/CASSANDRA-18731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-18731:
---
Reviewers: Michael Semb Wever
> Add declarative root CI structure
> -
>
> Key: CASSANDRA-18731
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18731
> Project: Cassandra
> Issue Type: Improvement
> Components: CI
>Reporter: Josh McKenzie
>Assignee: Josh McKenzie
>Priority: Normal
> Fix For: 5.x
>
>
> Currently we have a somewhat declarative structure in .circleci, however
> there's still quite a bit that's baked in (resource limitations, parallelism,
> which suites qualify for which pipelines (pre-commit vs. post-commit vs.
> ???), etc). Further, while CASSANDRA-18133 brings the build scripts in-tree,
> all these parameters (pipelines, env vars, job definitions, resource
> constraints) are all still scattered throughout the shell scripts and/or
> reliant on the {{JenkinsFile}} to determine what suites comprise what
> pipelines.
> This ticket aims to decouple the definition of pipelines and jobs for CI from
> the implementations themselves. The goal here is to define, establish, and
> test both the base config and some helper methods to provide _other_
> configurations (circle, ASF CI, etc) the tools they need to programmatically
> inherit base CI config from a purely declarative structure.
> Follow-up tickets will involve rewriting the in-tree build scripts and
> JenkinsFile generation to rely on this structure, as well as integrating the
> config parsing unit tests into our CI.
--
This message was sent by Atlassian 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-site updated (304f80c58 -> fb2f2a15c)
This is an automated email from the ASF dual-hosted git repository. mck pushed a change to branch asf-site in repository https://gitbox.apache.org/repos/asf/cassandra-website.git discard 304f80c58 ninja-fix if versioned docs are not found in latest, try stable discard 5765d975c generate docs for 92a3b80c add 3d6c1852d ninja-fix if versioned docs are not found in latest, try stable add a69b82d6b Update cassandra-summit-banner-1000x250.png with latest image details new fb2f2a15c generate docs for a69b82d6 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 (304f80c58) \ N -- N -- N refs/heads/asf-site (fb2f2a15c) 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: .../events/cassandra-summit-banner-1000x250.png| Bin 65651 -> 246826 bytes .../events/cassandra-summit-banner-1000x250.png| Bin 65651 -> 246826 bytes site-ui/build/ui-bundle.zip| Bin 4881412 -> 4881412 bytes 3 files changed, 0 insertions(+), 0 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18314) Lift MessagingService.minimum_version to 40
[ https://issues.apache.org/jira/browse/CASSANDRA-18314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17783529#comment-17783529 ] Michael Semb Wever edited comment on CASSANDRA-18314 at 11/7/23 8:21 AM: - bq. There is one bug so far I found, that is, we removed "too much" from HintDescriptor and this needs to go back (1). Thanks [~smiklosovic]. Works for me to commit all as part of 19002. was (Author: michaelsembwever): bq There is one bug so far I found, that is, we removed "too much" from HintDescriptor and this needs to go back (1). Thanks [~smiklosovic]. Works for me to commit all as part of 19002. > Lift MessagingService.minimum_version to 40 > --- > > Key: CASSANDRA-18314 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18314 > Project: Cassandra > Issue Type: Task > Components: Messaging/Internode >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: Normal > Fix For: 5.0, 5.0-alpha1 > > Time Spent: 15h 20m > Remaining Estimate: 0h > > MessagingService's VERSION_30 and VERSION_3014 don't have to be supported in > Cassandra 5.0 anymore. > (Cassandra 5.0 currently is still using VERSION_40) > Patch: > https://github.com/apache/cassandra/compare/trunk...thelastpickle:cassandra:mck/18314/trunk > Raises the question whether backward compatibility to the previous major is > defined by the Cassandra version or by the internal component version > (MessagingService). -- This message was sent by Atlassian 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-18314) Lift MessagingService.minimum_version to 40
[ https://issues.apache.org/jira/browse/CASSANDRA-18314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17783529#comment-17783529 ] Michael Semb Wever commented on CASSANDRA-18314: bq There is one bug so far I found, that is, we removed "too much" from HintDescriptor and this needs to go back (1). Thanks [~smiklosovic]. Works for me to commit all as part of 19002. > Lift MessagingService.minimum_version to 40 > --- > > Key: CASSANDRA-18314 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18314 > Project: Cassandra > Issue Type: Task > Components: Messaging/Internode >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: Normal > Fix For: 5.0, 5.0-alpha1 > > Time Spent: 15h 20m > Remaining Estimate: 0h > > MessagingService's VERSION_30 and VERSION_3014 don't have to be supported in > Cassandra 5.0 anymore. > (Cassandra 5.0 currently is still using VERSION_40) > Patch: > https://github.com/apache/cassandra/compare/trunk...thelastpickle:cassandra:mck/18314/trunk > Raises the question whether backward compatibility to the previous major is > defined by the Cassandra version or by the internal component version > (MessagingService). -- This message was sent by Atlassian 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-19002) Create / update tests to ensure commit logs and hints for all versions in MS are ingestible in 5.0
[ https://issues.apache.org/jira/browse/CASSANDRA-19002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-19002: --- Fix Version/s: 5.0-beta > Create / update tests to ensure commit logs and hints for all versions in MS > are ingestible in 5.0 > -- > > Key: CASSANDRA-19002 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19002 > Project: Cassandra > Issue Type: Task > Components: Test/unit >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 5.0-beta, 5.x > > Time Spent: 20m > Remaining Estimate: 0h > > This is follow up of CASSANDRA-18314 -- This message was sent by Atlassian 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-19002) Create / update tests to ensure commit logs and hints for all versions in MS are ingestible in 5.0
[ https://issues.apache.org/jira/browse/CASSANDRA-19002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-19002: --- Reviewers: Michael Semb Wever > Create / update tests to ensure commit logs and hints for all versions in MS > are ingestible in 5.0 > -- > > Key: CASSANDRA-19002 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19002 > Project: Cassandra > Issue Type: Task > Components: Test/unit >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 5.0-beta, 5.x > > Time Spent: 20m > Remaining Estimate: 0h > > This is follow up of CASSANDRA-18314 -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
