[jira] [Commented] (CASSANDRA-17445) Library airlift/airline has been deprecated
[
https://issues.apache.org/jira/browse/CASSANDRA-17445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17869462#comment-17869462
]
Caleb Rackliffe commented on CASSANDRA-17445:
-
I'm still looking through the patch/PR and making comments, but a word on
delivery...
I think what we should deliver as a first artifact here (i.e. literally commit
to trunk) is a single commit w/ a minimal viable airline -> pico replacement
(ex. directly use {{NodeProbe}} in the new commands). That obviously should go
along w/ parity testing for old/new help output and verification that Python
and in-JVM dtest usage of nodetool still works, etc.
Where did we land on the dev list around testing existing command output?
> Library airlift/airline has been deprecated
> ---
>
> Key: CASSANDRA-17445
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17445
> Project: Cassandra
> Issue Type: Task
> Components: Dependencies
>Reporter: Tibor Repasi
>Assignee: Maxim Muzafarov
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> The [airlift/airline|https://github.com/airlift/airline] library has been
> deprecated and is not maintained since [8 Jun
> 2021|https://github.com/airlift/airline/commit/ae3d7e103bdc140969bde944d4ba09345d663a61].
> It is used in many tools and some tests of Cassandra which should be
> reviewed.
> Tools using that library:
> * org.apache.cassandra.tools.JMXTool
> * org.apache.cassandra.tools.NodeTool
> * org.apache.cassandra.stress.Compaction
> * org.apache.cassandra.fqltool.FullQueryLogTool
> Tests using it:
> * org.apache.cassandra.simulator.SimulationRunner
> Alternatives (as suggested in the depreciation notice):
> * [Airline 2|https://rvesse.github.io/airline/]
> * [picocli|https://picocli.info]
--
This message was sent by Atlassian Jira
(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-19766) Optionally disable cqlsh HISTORY command via env variable
[
https://issues.apache.org/jira/browse/CASSANDRA-19766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe reassigned CASSANDRA-19766:
---
Assignee: (was: Caleb Rackliffe)
> Optionally disable cqlsh HISTORY command via env variable
> -
>
> Key: CASSANDRA-19766
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19766
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/cqlsh
>Reporter: Caleb Rackliffe
>Priority: Normal
> Fix For: 5.0.x, 5.x
>
>
> There may be cases where we’d like to disable the saving and display of the
> history of {{cqlsh}} commands executed. This should be fairly straightforward
> to do via an environment variable.
--
This message was sent by Atlassian Jira
(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-18839) Catch SSLHandshakeExceptions exceptions
[
https://issues.apache.org/jira/browse/CASSANDRA-18839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17869450#comment-17869450
]
Caleb Rackliffe commented on CASSANDRA-18839:
-
Is this ready to commit?
> Catch SSLHandshakeExceptions exceptions
> ---
>
> Key: CASSANDRA-18839
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18839
> Project: Cassandra
> Issue Type: Improvement
> Components: Messaging/Client
>Reporter: Brad Schoening
>Assignee: James Hu
>Priority: Low
> Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x
>
> Time Spent: 4h
> Remaining Estimate: 0h
>
> When SSL connection errors occur, they tend to flood the log with stack
> traces and lack the identity of the remote client IP. Instead,
> PreV5Handlers.decode() could catch SSLHandshakeException and provide a brief,
> more informative WARN level message instead of the verbose and mostly
> unhelpful stack trace.
> I.e.,
> {code:java}
> [WARN ] [epollEventLoopGroup-5-5] cluster_id=3 ip_address=10.0.0.1
> PreV5Handlers.java:261 - SSLHandshakeException in client networking with peer
> 10.0.0.10:9042 error:10d7:SSL
> routines:OPENSSL_internal:SSL_HANDSHAKE_FAILURE {code}
> instead of the current ones which flood the logs:
> {code:java}
> 2023-09-12 00:00:25,368 [WARN ] [epollEventLoopGroup-5-5] cluster_id=3
> ip_address=10.0.0.1 PreV5Handlers.java:261 - Unknown exception in client
> networking
> io.netty.handler.codec.DecoderException: javax.net.ssl.SSLHandshakeException:
> error:10d7:SSL routines:OPENSSL_internal:SSL_HANDSHAKE_FAILURE
> at
> io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:478)
> at
> io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:276)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
> at
> io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919)
> at
> io.netty.channel.epoll.AbstractEpollStreamChannel$EpollStreamUnsafe.epollInReady(AbstractEpollStreamChannel.java:795)
> at
> io.netty.channel.epoll.EpollEventLoop.processReady(EpollEventLoop.java:480)
> at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:378)
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
> at
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: javax.net.ssl.SSLHandshakeException: error:10d7:SSL
> routines:OPENSSL_internal:SSL_HANDSHAKE_FAILURE
> at
> io.netty.handler.ssl.ReferenceCountedOpenSslEngine.shutdownWithError(ReferenceCountedOpenSslEngine.java:1031)
> at
> io.netty.handler.ssl.ReferenceCountedOpenSslEngine.sslReadErrorResult(ReferenceCountedOpenSslEngine.java:1321)
> at
> io.netty.handler.ssl.ReferenceCountedOpenSslEngine.unwrap(ReferenceCountedOpenSslEngine.java:1270)
> at
> io.netty.handler.ssl.ReferenceCountedOpenSslEngine.unwrap(ReferenceCountedOpenSslEngine.java:1346)
> at
> io.netty.handler.ssl.ReferenceCountedOpenSslEngine.unwrap(ReferenceCountedOpenSslEngine.java:1389)
> at
> io.netty.handler.ssl.SslHandler$SslEngineType$1.unwrap(SslHandler.java:206)
> at io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1387)
> at
> io.netty.handler.ssl.SslHandler.decodeNonJdkCompatible(SslHandler.java:1294)
> at io.netty.handler.ssl.SslHandler.decode(SslHandler.java:1331)
> at
> io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:508)
> at
> io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:447)
> ... 15 common frames omitted {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19794) NPE on Directory access during Memtable flush fails ShortPaxosSimulationTest
[
https://issues.apache.org/jira/browse/CASSANDRA-19794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17869426#comment-17869426
]
Caleb Rackliffe commented on CASSANDRA-19794:
-
CC [~marcuse]
> NPE on Directory access during Memtable flush fails ShortPaxosSimulationTest
>
>
> Key: CASSANDRA-19794
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19794
> Project: Cassandra
> Issue Type: Bug
> Components: Test/burn, Transactional Cluster Metadata
>Reporter: Caleb Rackliffe
>Assignee: Alex Petrov
>Priority: Normal
> Fix For: 5.x
>
>
> Run {{ShortPaxosSimulationTest}} w/ the following arguments on trunk:
> {noformat}
> PaxosSimulationRunner.main(new String[] { "run", "-n", "3..6", "-t", "1000",
> "-c", "2", "--cluster-action-limit", "2", "-s", "30", "--seed",
> "0xe0247e19a75e3bba" });
> {noformat}
> You should see a failure, starting with...
> {noformat}
> [junit-timeout] WARN [OptionalTasks:1] node5 2024-07-22 15:46:00,210
> LegacyStateListener.java:158 - Token -6148914691236517205 changing ownership
> from /127.0.0.1:7012 to /127.0.0.6:7012
> [junit-timeout] WARN [OptionalTasks:1] node6 2024-07-22 15:46:00,259
> SystemKeyspace.java:1287 - Using stored Gossip Generation 1577894856 as it is
> greater than current system time 1577894855. See CASSANDRA-3654 if you
> experience problems
> [junit-timeout] WARN [OptionalTasks:1] node6 2024-07-22 15:46:00,277
> LegacyStateListener.java:158 - Token -6148914691236517205 changing ownership
> from /127.0.0.1:7012 to /127.0.0.6:7012
> [junit-timeout] ERROR [isolatedExecutor:3] node6 2024-07-22 15:46:00,469
> ReconfigureCMS.java:184 - Could not finish adding the node to the Cluster
> Metadata Service
> [junit-timeout] java.lang.IllegalStateException: Can not commit
> transformation: "SERVER_ERROR"(class java.lang.NullPointerException).
> [junit-timeout] at
> org.apache.cassandra.tcm.ClusterMetadataService.lambda$commit$6(ClusterMetadataService.java:491)
> [junit-timeout] at
> org.apache.cassandra.tcm.ClusterMetadataService.commit(ClusterMetadataService.java:535)
> [junit-timeout] at
> org.apache.cassandra.tcm.ClusterMetadataService.commit(ClusterMetadataService.java:488)
> [junit-timeout] at
> org.apache.cassandra.tcm.sequences.ReconfigureCMS.executeNext(ReconfigureCMS.java:179)
> [junit-timeout] at
> org.apache.cassandra.tcm.sequences.InProgressSequences.resume(InProgressSequences.java:200)
> [junit-timeout] at
> org.apache.cassandra.tcm.sequences.InProgressSequences.finishInProgressSequences(InProgressSequences.java:72)
> [junit-timeout] at
> org.apache.cassandra.tcm.ClusterMetadataService.reconfigureCMS(ClusterMetadataService.java:372)
> [junit-timeout] at
> org.apache.cassandra.tcm.ClusterMetadataService.ensureCMSPlacement(ClusterMetadataService.java:379)
> [junit-timeout] at
> org.apache.cassandra.tcm.sequences.BootstrapAndReplace.executeNext(BootstrapAndReplace.java:274)
> [junit-timeout] at
> org.apache.cassandra.simulator.cluster.OnClusterReplace$ExecuteNextStep.lambda$new$f5e64c00$1(OnClusterReplace.java:162)
> [junit-timeout] at
> org.apache.cassandra.distributed.api.IInvokableInstance.unsafeRunOnThisThread(IInvokableInstance.java:85)
> [junit-timeout] at
> org.apache.cassandra.simulator.systems.SimulatedActionTask.lambda$asSafeRunnable$0(SimulatedActionTask.java:83)
> [junit-timeout] at
> org.apache.cassandra.simulator.systems.SimulatedActionTask$1.run(SimulatedActionTask.java:93)
> [junit-timeout] at
> org.apache.cassandra.simulator.systems.InterceptingExecutor$InterceptingPooledExecutor$WaitingThread.lambda$new$1(InterceptingExecutor.java:318)
> [junit-timeout] at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> [junit-timeout] at java.base/java.lang.Thread.run(Thread.java:829)
> {noformat}
> ...and underneath that...
> {noformat}
> [junit-timeout] Thread[ScheduledTasks:1,5,node3]
> [junit-timeout] java.lang.NullPointerException
> [junit-timeout] at
> org.apache.cassandra.utils.btree.AbstractBTreeMap.get(AbstractBTreeMap.java:92)
> [junit-timeout] at
> org.apache.cassandra.tcm.membership.Directory.endpoint(Directory.java:312)
> [junit-timeout] at
> org.apache.cassandra.tcm.transformations.cms.AdvanceCMSReconfiguration.executeRemove(AdvanceCMSReconfiguration.java:242)
> [junit-timeout] at
> org.apache.cassandra.tcm.transformations.cms.AdvanceCMSReconfiguration.execute(AdvanceCMSReconfiguration.java:123)
> [junit-timeout] at
> org.apache.cassandra.tcm.sequences.ReconfigureCMS.applyTo(ReconfigureCMS.java:149)
> [junit-timeout] at
>
[jira] [Commented] (CASSANDRA-19794) NPE on Directory access during Memtable flush fails ShortPaxosSimulationTest
[
https://issues.apache.org/jira/browse/CASSANDRA-19794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17869425#comment-17869425
]
Caleb Rackliffe commented on CASSANDRA-19794:
-
+1
Had a quick offline conversation w/ Alex, and the only changes to the PR will
be adding some guardrails to {{PrepareReplace}} and {{PrepareLeave}} to make
sure addresses are removed from the CMS first, so there isn't a mismatch
between the directory and {{fullCMSEndpoints}} before they actually run.
> NPE on Directory access during Memtable flush fails ShortPaxosSimulationTest
>
>
> Key: CASSANDRA-19794
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19794
> Project: Cassandra
> Issue Type: Bug
> Components: Test/burn, Transactional Cluster Metadata
>Reporter: Caleb Rackliffe
>Assignee: Alex Petrov
>Priority: Normal
> Fix For: 5.x
>
>
> Run {{ShortPaxosSimulationTest}} w/ the following arguments on trunk:
> {noformat}
> PaxosSimulationRunner.main(new String[] { "run", "-n", "3..6", "-t", "1000",
> "-c", "2", "--cluster-action-limit", "2", "-s", "30", "--seed",
> "0xe0247e19a75e3bba" });
> {noformat}
> You should see a failure, starting with...
> {noformat}
> [junit-timeout] WARN [OptionalTasks:1] node5 2024-07-22 15:46:00,210
> LegacyStateListener.java:158 - Token -6148914691236517205 changing ownership
> from /127.0.0.1:7012 to /127.0.0.6:7012
> [junit-timeout] WARN [OptionalTasks:1] node6 2024-07-22 15:46:00,259
> SystemKeyspace.java:1287 - Using stored Gossip Generation 1577894856 as it is
> greater than current system time 1577894855. See CASSANDRA-3654 if you
> experience problems
> [junit-timeout] WARN [OptionalTasks:1] node6 2024-07-22 15:46:00,277
> LegacyStateListener.java:158 - Token -6148914691236517205 changing ownership
> from /127.0.0.1:7012 to /127.0.0.6:7012
> [junit-timeout] ERROR [isolatedExecutor:3] node6 2024-07-22 15:46:00,469
> ReconfigureCMS.java:184 - Could not finish adding the node to the Cluster
> Metadata Service
> [junit-timeout] java.lang.IllegalStateException: Can not commit
> transformation: "SERVER_ERROR"(class java.lang.NullPointerException).
> [junit-timeout] at
> org.apache.cassandra.tcm.ClusterMetadataService.lambda$commit$6(ClusterMetadataService.java:491)
> [junit-timeout] at
> org.apache.cassandra.tcm.ClusterMetadataService.commit(ClusterMetadataService.java:535)
> [junit-timeout] at
> org.apache.cassandra.tcm.ClusterMetadataService.commit(ClusterMetadataService.java:488)
> [junit-timeout] at
> org.apache.cassandra.tcm.sequences.ReconfigureCMS.executeNext(ReconfigureCMS.java:179)
> [junit-timeout] at
> org.apache.cassandra.tcm.sequences.InProgressSequences.resume(InProgressSequences.java:200)
> [junit-timeout] at
> org.apache.cassandra.tcm.sequences.InProgressSequences.finishInProgressSequences(InProgressSequences.java:72)
> [junit-timeout] at
> org.apache.cassandra.tcm.ClusterMetadataService.reconfigureCMS(ClusterMetadataService.java:372)
> [junit-timeout] at
> org.apache.cassandra.tcm.ClusterMetadataService.ensureCMSPlacement(ClusterMetadataService.java:379)
> [junit-timeout] at
> org.apache.cassandra.tcm.sequences.BootstrapAndReplace.executeNext(BootstrapAndReplace.java:274)
> [junit-timeout] at
> org.apache.cassandra.simulator.cluster.OnClusterReplace$ExecuteNextStep.lambda$new$f5e64c00$1(OnClusterReplace.java:162)
> [junit-timeout] at
> org.apache.cassandra.distributed.api.IInvokableInstance.unsafeRunOnThisThread(IInvokableInstance.java:85)
> [junit-timeout] at
> org.apache.cassandra.simulator.systems.SimulatedActionTask.lambda$asSafeRunnable$0(SimulatedActionTask.java:83)
> [junit-timeout] at
> org.apache.cassandra.simulator.systems.SimulatedActionTask$1.run(SimulatedActionTask.java:93)
> [junit-timeout] at
> org.apache.cassandra.simulator.systems.InterceptingExecutor$InterceptingPooledExecutor$WaitingThread.lambda$new$1(InterceptingExecutor.java:318)
> [junit-timeout] at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> [junit-timeout] at java.base/java.lang.Thread.run(Thread.java:829)
> {noformat}
> ...and underneath that...
> {noformat}
> [junit-timeout] Thread[ScheduledTasks:1,5,node3]
> [junit-timeout] java.lang.NullPointerException
> [junit-timeout] at
> org.apache.cassandra.utils.btree.AbstractBTreeMap.get(AbstractBTreeMap.java:92)
> [junit-timeout] at
> org.apache.cassandra.tcm.membership.Directory.endpoint(Directory.java:312)
> [junit-timeout] at
> org.apache.cassandra.tcm.transformations.cms.AdvanceCMSReconfiguration.executeRemove(AdvanceCMSReconfiguration.java:242)
> [junit-timeout] at
>
[jira] [Updated] (CASSANDRA-19688) SAI support for BETWEEN operator
[ https://issues.apache.org/jira/browse/CASSANDRA-19688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Rackliffe updated CASSANDRA-19688: Status: Review In Progress (was: Patch Available) > SAI support for BETWEEN operator > > > Key: CASSANDRA-19688 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19688 > Project: Cassandra > Issue Type: New Feature > Components: CQL/Syntax, Feature/SAI >Reporter: Caleb Rackliffe >Assignee: Arun Ganesh >Priority: Normal > Fix For: 5.x > > Time Spent: 20m > Remaining Estimate: 0h > > The new CQL BETWEEN operator should map pretty neatly to SAI’s internal RANGE > operator for numeric indexes. There’s no reason we shouldn’t support 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-19794) NPE on Directory access during Memtable flush fails ShortPaxosSimulationTest
[
https://issues.apache.org/jira/browse/CASSANDRA-19794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-19794:
Reviewers: Caleb Rackliffe, Caleb Rackliffe
Caleb Rackliffe, Caleb Rackliffe (was: Caleb Rackliffe)
Status: Review In Progress (was: Patch Available)
> NPE on Directory access during Memtable flush fails ShortPaxosSimulationTest
>
>
> Key: CASSANDRA-19794
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19794
> Project: Cassandra
> Issue Type: Bug
> Components: Test/burn, Transactional Cluster Metadata
>Reporter: Caleb Rackliffe
>Assignee: Alex Petrov
>Priority: Normal
> Fix For: 5.x
>
>
> Run {{ShortPaxosSimulationTest}} w/ the following arguments on trunk:
> {noformat}
> PaxosSimulationRunner.main(new String[] { "run", "-n", "3..6", "-t", "1000",
> "-c", "2", "--cluster-action-limit", "2", "-s", "30", "--seed",
> "0xe0247e19a75e3bba" });
> {noformat}
> You should see a failure, starting with...
> {noformat}
> [junit-timeout] WARN [OptionalTasks:1] node5 2024-07-22 15:46:00,210
> LegacyStateListener.java:158 - Token -6148914691236517205 changing ownership
> from /127.0.0.1:7012 to /127.0.0.6:7012
> [junit-timeout] WARN [OptionalTasks:1] node6 2024-07-22 15:46:00,259
> SystemKeyspace.java:1287 - Using stored Gossip Generation 1577894856 as it is
> greater than current system time 1577894855. See CASSANDRA-3654 if you
> experience problems
> [junit-timeout] WARN [OptionalTasks:1] node6 2024-07-22 15:46:00,277
> LegacyStateListener.java:158 - Token -6148914691236517205 changing ownership
> from /127.0.0.1:7012 to /127.0.0.6:7012
> [junit-timeout] ERROR [isolatedExecutor:3] node6 2024-07-22 15:46:00,469
> ReconfigureCMS.java:184 - Could not finish adding the node to the Cluster
> Metadata Service
> [junit-timeout] java.lang.IllegalStateException: Can not commit
> transformation: "SERVER_ERROR"(class java.lang.NullPointerException).
> [junit-timeout] at
> org.apache.cassandra.tcm.ClusterMetadataService.lambda$commit$6(ClusterMetadataService.java:491)
> [junit-timeout] at
> org.apache.cassandra.tcm.ClusterMetadataService.commit(ClusterMetadataService.java:535)
> [junit-timeout] at
> org.apache.cassandra.tcm.ClusterMetadataService.commit(ClusterMetadataService.java:488)
> [junit-timeout] at
> org.apache.cassandra.tcm.sequences.ReconfigureCMS.executeNext(ReconfigureCMS.java:179)
> [junit-timeout] at
> org.apache.cassandra.tcm.sequences.InProgressSequences.resume(InProgressSequences.java:200)
> [junit-timeout] at
> org.apache.cassandra.tcm.sequences.InProgressSequences.finishInProgressSequences(InProgressSequences.java:72)
> [junit-timeout] at
> org.apache.cassandra.tcm.ClusterMetadataService.reconfigureCMS(ClusterMetadataService.java:372)
> [junit-timeout] at
> org.apache.cassandra.tcm.ClusterMetadataService.ensureCMSPlacement(ClusterMetadataService.java:379)
> [junit-timeout] at
> org.apache.cassandra.tcm.sequences.BootstrapAndReplace.executeNext(BootstrapAndReplace.java:274)
> [junit-timeout] at
> org.apache.cassandra.simulator.cluster.OnClusterReplace$ExecuteNextStep.lambda$new$f5e64c00$1(OnClusterReplace.java:162)
> [junit-timeout] at
> org.apache.cassandra.distributed.api.IInvokableInstance.unsafeRunOnThisThread(IInvokableInstance.java:85)
> [junit-timeout] at
> org.apache.cassandra.simulator.systems.SimulatedActionTask.lambda$asSafeRunnable$0(SimulatedActionTask.java:83)
> [junit-timeout] at
> org.apache.cassandra.simulator.systems.SimulatedActionTask$1.run(SimulatedActionTask.java:93)
> [junit-timeout] at
> org.apache.cassandra.simulator.systems.InterceptingExecutor$InterceptingPooledExecutor$WaitingThread.lambda$new$1(InterceptingExecutor.java:318)
> [junit-timeout] at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> [junit-timeout] at java.base/java.lang.Thread.run(Thread.java:829)
> {noformat}
> ...and underneath that...
> {noformat}
> [junit-timeout] Thread[ScheduledTasks:1,5,node3]
> [junit-timeout] java.lang.NullPointerException
> [junit-timeout] at
> org.apache.cassandra.utils.btree.AbstractBTreeMap.get(AbstractBTreeMap.java:92)
> [junit-timeout] at
> org.apache.cassandra.tcm.membership.Directory.endpoint(Directory.java:312)
> [junit-timeout] at
> org.apache.cassandra.tcm.transformations.cms.AdvanceCMSReconfiguration.executeRemove(AdvanceCMSReconfiguration.java:242)
> [junit-timeout] at
> org.apache.cassandra.tcm.transformations.cms.AdvanceCMSReconfiguration.execute(AdvanceCMSReconfiguration.java:123)
> [junit-timeout] at
>
[jira] [Updated] (CASSANDRA-19400) IndexStatusManager needs to prioritize SUCCESS over UNKNOWN states to maximize availability
[
https://issues.apache.org/jira/browse/CASSANDRA-19400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-19400:
Fix Version/s: 5.0.1
(was: 5.0.x)
Since Version: 5.0-alpha1
Source Control Link:
https://github.com/apache/cassandra/commit/273975ef26e5de1a10a98c0df364cb67fa7830e3
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
> IndexStatusManager needs to prioritize SUCCESS over UNKNOWN states to
> maximize availability
> ---
>
> Key: CASSANDRA-19400
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19400
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/SAI
>Reporter: Caleb Rackliffe
>Assignee: Arun Ganesh
>Priority: Low
> Fix For: 5.0.1, 5.x
>
> Attachments: ci_summary.html, ci_summary.json
>
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> {{IndexStatusManager}} is responsible for knowing what SAI indexes are
> queryable across the ring, endpoint by endpoint. There are two statuses that
> SAI treats as queryable, but it should not treat them equally.
> {{BUILD_SUCCEEDED}} means the index is definitely available and should be
> able to serve queries without issue. {{UNKNOWN}} indicates that the status of
> the index hasn’t propagated yet to this coordinator. It may be just fine, or
> it may not be. If it isn’t a query will not return incorrect results, but it
> will fail. If there are enough {{BUILD_SUCCEEDED}} replicas, we should ignore
> {{UNKNOWN}} replicas and maximize availability. If the UNKNOWN replica is
> going to become {{BUILD_SUCCEEDED}} shortly, it will happily start taking
> requests at that point and spread the load. If not, we’ll avoid futile
> attempts to query it too early.
--
This message was sent by Atlassian Jira
(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-19400) IndexStatusManager needs to prioritize SUCCESS over UNKNOWN states to maximize availability
[
https://issues.apache.org/jira/browse/CASSANDRA-19400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17868448#comment-17868448
]
Caleb Rackliffe edited comment on CASSANDRA-19400 at 7/24/24 8:28 PM:
--
Just waiting for updated CI runs. Once those look good, I'll start the process
of committing...
EDIT: There are some unrelated problems, but overall CI looks good.
was (Author: maedhroz):
Just waiting for updated CI runs. Once those look good, I'll start the process
of committing...
> IndexStatusManager needs to prioritize SUCCESS over UNKNOWN states to
> maximize availability
> ---
>
> Key: CASSANDRA-19400
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19400
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/SAI
>Reporter: Caleb Rackliffe
>Assignee: Arun Ganesh
>Priority: Low
> Fix For: 5.0.x, 5.x
>
> Attachments: ci_summary.html, ci_summary.json
>
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> {{IndexStatusManager}} is responsible for knowing what SAI indexes are
> queryable across the ring, endpoint by endpoint. There are two statuses that
> SAI treats as queryable, but it should not treat them equally.
> {{BUILD_SUCCEEDED}} means the index is definitely available and should be
> able to serve queries without issue. {{UNKNOWN}} indicates that the status of
> the index hasn’t propagated yet to this coordinator. It may be just fine, or
> it may not be. If it isn’t a query will not return incorrect results, but it
> will fail. If there are enough {{BUILD_SUCCEEDED}} replicas, we should ignore
> {{UNKNOWN}} replicas and maximize availability. If the UNKNOWN replica is
> going to become {{BUILD_SUCCEEDED}} shortly, it will happily start taking
> requests at that point and spread the load. If not, we’ll avoid futile
> attempts to query it too early.
--
This message was sent by Atlassian Jira
(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-19400) IndexStatusManager needs to prioritize SUCCESS over UNKNOWN states to maximize availability
[
https://issues.apache.org/jira/browse/CASSANDRA-19400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-19400:
Attachment: ci_summary.json
> IndexStatusManager needs to prioritize SUCCESS over UNKNOWN states to
> maximize availability
> ---
>
> Key: CASSANDRA-19400
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19400
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/SAI
>Reporter: Caleb Rackliffe
>Assignee: Arun Ganesh
>Priority: Low
> Fix For: 5.0.x, 5.x
>
> Attachments: ci_summary.html, ci_summary.json
>
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> {{IndexStatusManager}} is responsible for knowing what SAI indexes are
> queryable across the ring, endpoint by endpoint. There are two statuses that
> SAI treats as queryable, but it should not treat them equally.
> {{BUILD_SUCCEEDED}} means the index is definitely available and should be
> able to serve queries without issue. {{UNKNOWN}} indicates that the status of
> the index hasn’t propagated yet to this coordinator. It may be just fine, or
> it may not be. If it isn’t a query will not return incorrect results, but it
> will fail. If there are enough {{BUILD_SUCCEEDED}} replicas, we should ignore
> {{UNKNOWN}} replicas and maximize availability. If the UNKNOWN replica is
> going to become {{BUILD_SUCCEEDED}} shortly, it will happily start taking
> requests at that point and spread the load. If not, we’ll avoid futile
> attempts to query it too early.
--
This message was sent by Atlassian Jira
(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-19400) IndexStatusManager needs to prioritize SUCCESS over UNKNOWN states to maximize availability
[
https://issues.apache.org/jira/browse/CASSANDRA-19400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-19400:
Attachment: ci_summary.html
> IndexStatusManager needs to prioritize SUCCESS over UNKNOWN states to
> maximize availability
> ---
>
> Key: CASSANDRA-19400
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19400
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/SAI
>Reporter: Caleb Rackliffe
>Assignee: Arun Ganesh
>Priority: Low
> Fix For: 5.0.x, 5.x
>
> Attachments: ci_summary.html
>
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> {{IndexStatusManager}} is responsible for knowing what SAI indexes are
> queryable across the ring, endpoint by endpoint. There are two statuses that
> SAI treats as queryable, but it should not treat them equally.
> {{BUILD_SUCCEEDED}} means the index is definitely available and should be
> able to serve queries without issue. {{UNKNOWN}} indicates that the status of
> the index hasn’t propagated yet to this coordinator. It may be just fine, or
> it may not be. If it isn’t a query will not return incorrect results, but it
> will fail. If there are enough {{BUILD_SUCCEEDED}} replicas, we should ignore
> {{UNKNOWN}} replicas and maximize availability. If the UNKNOWN replica is
> going to become {{BUILD_SUCCEEDED}} shortly, it will happily start taking
> requests at that point and spread the load. If not, we’ll avoid futile
> attempts to query it too early.
--
This message was sent by Atlassian Jira
(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-19400) IndexStatusManager needs to prioritize SUCCESS over UNKNOWN states to maximize availability
[
https://issues.apache.org/jira/browse/CASSANDRA-19400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-19400:
Status: Ready to Commit (was: Review In Progress)
Just waiting for updated CI runs. Once those look good, I'll start the process
of committing...
> IndexStatusManager needs to prioritize SUCCESS over UNKNOWN states to
> maximize availability
> ---
>
> Key: CASSANDRA-19400
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19400
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/SAI
>Reporter: Caleb Rackliffe
>Assignee: Arun Ganesh
>Priority: Low
> Fix For: 5.0.x, 5.x
>
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> {{IndexStatusManager}} is responsible for knowing what SAI indexes are
> queryable across the ring, endpoint by endpoint. There are two statuses that
> SAI treats as queryable, but it should not treat them equally.
> {{BUILD_SUCCEEDED}} means the index is definitely available and should be
> able to serve queries without issue. {{UNKNOWN}} indicates that the status of
> the index hasn’t propagated yet to this coordinator. It may be just fine, or
> it may not be. If it isn’t a query will not return incorrect results, but it
> will fail. If there are enough {{BUILD_SUCCEEDED}} replicas, we should ignore
> {{UNKNOWN}} replicas and maximize availability. If the UNKNOWN replica is
> going to become {{BUILD_SUCCEEDED}} shortly, it will happily start taking
> requests at that point and spread the load. If not, we’ll avoid futile
> attempts to query it too early.
--
This message was sent by Atlassian Jira
(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-19794) NPE on Directory access during Memtable flush fails ShortPaxosSimulationTest
[
https://issues.apache.org/jira/browse/CASSANDRA-19794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17868414#comment-17868414
]
Caleb Rackliffe edited comment on CASSANDRA-19794 at 7/24/24 4:10 PM:
--
{noformat}
"--seed", "0xe0247e19a75e3bba" {noformat}
(Sorry, it was probably cut off in the description above due to being the last
arg.)
was (Author: maedhroz):
{noformat}
"--seed", "0xe0247e19a75e3bba" {noformat}
> NPE on Directory access during Memtable flush fails ShortPaxosSimulationTest
>
>
> Key: CASSANDRA-19794
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19794
> Project: Cassandra
> Issue Type: Bug
> Components: Test/burn, Transactional Cluster Metadata
>Reporter: Caleb Rackliffe
>Assignee: Marcus Eriksson
>Priority: Normal
> Fix For: 5.x
>
>
> Run {{ShortPaxosSimulationTest}} w/ the following arguments on trunk:
> {noformat}
> PaxosSimulationRunner.main(new String[] { "run", "-n", "3..6", "-t", "1000",
> "-c", "2", "--cluster-action-limit", "2", "-s", "30", "--seed",
> "0xe0247e19a75e3bba" });
> {noformat}
> You should see a failure, starting with...
> {noformat}
> [junit-timeout] WARN [OptionalTasks:1] node5 2024-07-22 15:46:00,210
> LegacyStateListener.java:158 - Token -6148914691236517205 changing ownership
> from /127.0.0.1:7012 to /127.0.0.6:7012
> [junit-timeout] WARN [OptionalTasks:1] node6 2024-07-22 15:46:00,259
> SystemKeyspace.java:1287 - Using stored Gossip Generation 1577894856 as it is
> greater than current system time 1577894855. See CASSANDRA-3654 if you
> experience problems
> [junit-timeout] WARN [OptionalTasks:1] node6 2024-07-22 15:46:00,277
> LegacyStateListener.java:158 - Token -6148914691236517205 changing ownership
> from /127.0.0.1:7012 to /127.0.0.6:7012
> [junit-timeout] ERROR [isolatedExecutor:3] node6 2024-07-22 15:46:00,469
> ReconfigureCMS.java:184 - Could not finish adding the node to the Cluster
> Metadata Service
> [junit-timeout] java.lang.IllegalStateException: Can not commit
> transformation: "SERVER_ERROR"(class java.lang.NullPointerException).
> [junit-timeout] at
> org.apache.cassandra.tcm.ClusterMetadataService.lambda$commit$6(ClusterMetadataService.java:491)
> [junit-timeout] at
> org.apache.cassandra.tcm.ClusterMetadataService.commit(ClusterMetadataService.java:535)
> [junit-timeout] at
> org.apache.cassandra.tcm.ClusterMetadataService.commit(ClusterMetadataService.java:488)
> [junit-timeout] at
> org.apache.cassandra.tcm.sequences.ReconfigureCMS.executeNext(ReconfigureCMS.java:179)
> [junit-timeout] at
> org.apache.cassandra.tcm.sequences.InProgressSequences.resume(InProgressSequences.java:200)
> [junit-timeout] at
> org.apache.cassandra.tcm.sequences.InProgressSequences.finishInProgressSequences(InProgressSequences.java:72)
> [junit-timeout] at
> org.apache.cassandra.tcm.ClusterMetadataService.reconfigureCMS(ClusterMetadataService.java:372)
> [junit-timeout] at
> org.apache.cassandra.tcm.ClusterMetadataService.ensureCMSPlacement(ClusterMetadataService.java:379)
> [junit-timeout] at
> org.apache.cassandra.tcm.sequences.BootstrapAndReplace.executeNext(BootstrapAndReplace.java:274)
> [junit-timeout] at
> org.apache.cassandra.simulator.cluster.OnClusterReplace$ExecuteNextStep.lambda$new$f5e64c00$1(OnClusterReplace.java:162)
> [junit-timeout] at
> org.apache.cassandra.distributed.api.IInvokableInstance.unsafeRunOnThisThread(IInvokableInstance.java:85)
> [junit-timeout] at
> org.apache.cassandra.simulator.systems.SimulatedActionTask.lambda$asSafeRunnable$0(SimulatedActionTask.java:83)
> [junit-timeout] at
> org.apache.cassandra.simulator.systems.SimulatedActionTask$1.run(SimulatedActionTask.java:93)
> [junit-timeout] at
> org.apache.cassandra.simulator.systems.InterceptingExecutor$InterceptingPooledExecutor$WaitingThread.lambda$new$1(InterceptingExecutor.java:318)
> [junit-timeout] at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> [junit-timeout] at java.base/java.lang.Thread.run(Thread.java:829)
> {noformat}
> ...and underneath that...
> {noformat}
> [junit-timeout] Thread[ScheduledTasks:1,5,node3]
> [junit-timeout] java.lang.NullPointerException
> [junit-timeout] at
> org.apache.cassandra.utils.btree.AbstractBTreeMap.get(AbstractBTreeMap.java:92)
> [junit-timeout] at
> org.apache.cassandra.tcm.membership.Directory.endpoint(Directory.java:312)
> [junit-timeout] at
> org.apache.cassandra.tcm.transformations.cms.AdvanceCMSReconfiguration.executeRemove(AdvanceCMSReconfiguration.java:242)
> [junit-timeout] at
>
[jira] [Comment Edited] (CASSANDRA-19794) NPE on Directory access during Memtable flush fails ShortPaxosSimulationTest
[
https://issues.apache.org/jira/browse/CASSANDRA-19794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17868414#comment-17868414
]
Caleb Rackliffe edited comment on CASSANDRA-19794 at 7/24/24 4:10 PM:
--
{noformat}
"--seed", "0xe0247e19a75e3bba" {noformat}
(Sorry, it was probably cut off in the description above due to being the last
arg and needing scrolling to the right.)
was (Author: maedhroz):
{noformat}
"--seed", "0xe0247e19a75e3bba" {noformat}
(Sorry, it was probably cut off in the description above due to being the last
arg.)
> NPE on Directory access during Memtable flush fails ShortPaxosSimulationTest
>
>
> Key: CASSANDRA-19794
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19794
> Project: Cassandra
> Issue Type: Bug
> Components: Test/burn, Transactional Cluster Metadata
>Reporter: Caleb Rackliffe
>Assignee: Marcus Eriksson
>Priority: Normal
> Fix For: 5.x
>
>
> Run {{ShortPaxosSimulationTest}} w/ the following arguments on trunk:
> {noformat}
> PaxosSimulationRunner.main(new String[] { "run", "-n", "3..6", "-t", "1000",
> "-c", "2", "--cluster-action-limit", "2", "-s", "30", "--seed",
> "0xe0247e19a75e3bba" });
> {noformat}
> You should see a failure, starting with...
> {noformat}
> [junit-timeout] WARN [OptionalTasks:1] node5 2024-07-22 15:46:00,210
> LegacyStateListener.java:158 - Token -6148914691236517205 changing ownership
> from /127.0.0.1:7012 to /127.0.0.6:7012
> [junit-timeout] WARN [OptionalTasks:1] node6 2024-07-22 15:46:00,259
> SystemKeyspace.java:1287 - Using stored Gossip Generation 1577894856 as it is
> greater than current system time 1577894855. See CASSANDRA-3654 if you
> experience problems
> [junit-timeout] WARN [OptionalTasks:1] node6 2024-07-22 15:46:00,277
> LegacyStateListener.java:158 - Token -6148914691236517205 changing ownership
> from /127.0.0.1:7012 to /127.0.0.6:7012
> [junit-timeout] ERROR [isolatedExecutor:3] node6 2024-07-22 15:46:00,469
> ReconfigureCMS.java:184 - Could not finish adding the node to the Cluster
> Metadata Service
> [junit-timeout] java.lang.IllegalStateException: Can not commit
> transformation: "SERVER_ERROR"(class java.lang.NullPointerException).
> [junit-timeout] at
> org.apache.cassandra.tcm.ClusterMetadataService.lambda$commit$6(ClusterMetadataService.java:491)
> [junit-timeout] at
> org.apache.cassandra.tcm.ClusterMetadataService.commit(ClusterMetadataService.java:535)
> [junit-timeout] at
> org.apache.cassandra.tcm.ClusterMetadataService.commit(ClusterMetadataService.java:488)
> [junit-timeout] at
> org.apache.cassandra.tcm.sequences.ReconfigureCMS.executeNext(ReconfigureCMS.java:179)
> [junit-timeout] at
> org.apache.cassandra.tcm.sequences.InProgressSequences.resume(InProgressSequences.java:200)
> [junit-timeout] at
> org.apache.cassandra.tcm.sequences.InProgressSequences.finishInProgressSequences(InProgressSequences.java:72)
> [junit-timeout] at
> org.apache.cassandra.tcm.ClusterMetadataService.reconfigureCMS(ClusterMetadataService.java:372)
> [junit-timeout] at
> org.apache.cassandra.tcm.ClusterMetadataService.ensureCMSPlacement(ClusterMetadataService.java:379)
> [junit-timeout] at
> org.apache.cassandra.tcm.sequences.BootstrapAndReplace.executeNext(BootstrapAndReplace.java:274)
> [junit-timeout] at
> org.apache.cassandra.simulator.cluster.OnClusterReplace$ExecuteNextStep.lambda$new$f5e64c00$1(OnClusterReplace.java:162)
> [junit-timeout] at
> org.apache.cassandra.distributed.api.IInvokableInstance.unsafeRunOnThisThread(IInvokableInstance.java:85)
> [junit-timeout] at
> org.apache.cassandra.simulator.systems.SimulatedActionTask.lambda$asSafeRunnable$0(SimulatedActionTask.java:83)
> [junit-timeout] at
> org.apache.cassandra.simulator.systems.SimulatedActionTask$1.run(SimulatedActionTask.java:93)
> [junit-timeout] at
> org.apache.cassandra.simulator.systems.InterceptingExecutor$InterceptingPooledExecutor$WaitingThread.lambda$new$1(InterceptingExecutor.java:318)
> [junit-timeout] at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> [junit-timeout] at java.base/java.lang.Thread.run(Thread.java:829)
> {noformat}
> ...and underneath that...
> {noformat}
> [junit-timeout] Thread[ScheduledTasks:1,5,node3]
> [junit-timeout] java.lang.NullPointerException
> [junit-timeout] at
> org.apache.cassandra.utils.btree.AbstractBTreeMap.get(AbstractBTreeMap.java:92)
> [junit-timeout] at
> org.apache.cassandra.tcm.membership.Directory.endpoint(Directory.java:312)
> [junit-timeout] at
>
[jira] [Commented] (CASSANDRA-19794) NPE on Directory access during Memtable flush fails ShortPaxosSimulationTest
[
https://issues.apache.org/jira/browse/CASSANDRA-19794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17868414#comment-17868414
]
Caleb Rackliffe commented on CASSANDRA-19794:
-
{noformat}
"--seed", "0xe0247e19a75e3bba" {noformat}
> NPE on Directory access during Memtable flush fails ShortPaxosSimulationTest
>
>
> Key: CASSANDRA-19794
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19794
> Project: Cassandra
> Issue Type: Bug
> Components: Test/burn, Transactional Cluster Metadata
>Reporter: Caleb Rackliffe
>Assignee: Marcus Eriksson
>Priority: Normal
> Fix For: 5.x
>
>
> Run {{ShortPaxosSimulationTest}} w/ the following arguments on trunk:
> {noformat}
> PaxosSimulationRunner.main(new String[] { "run", "-n", "3..6", "-t", "1000",
> "-c", "2", "--cluster-action-limit", "2", "-s", "30", "--seed",
> "0xe0247e19a75e3bba" });
> {noformat}
> You should see a failure, starting with...
> {noformat}
> [junit-timeout] WARN [OptionalTasks:1] node5 2024-07-22 15:46:00,210
> LegacyStateListener.java:158 - Token -6148914691236517205 changing ownership
> from /127.0.0.1:7012 to /127.0.0.6:7012
> [junit-timeout] WARN [OptionalTasks:1] node6 2024-07-22 15:46:00,259
> SystemKeyspace.java:1287 - Using stored Gossip Generation 1577894856 as it is
> greater than current system time 1577894855. See CASSANDRA-3654 if you
> experience problems
> [junit-timeout] WARN [OptionalTasks:1] node6 2024-07-22 15:46:00,277
> LegacyStateListener.java:158 - Token -6148914691236517205 changing ownership
> from /127.0.0.1:7012 to /127.0.0.6:7012
> [junit-timeout] ERROR [isolatedExecutor:3] node6 2024-07-22 15:46:00,469
> ReconfigureCMS.java:184 - Could not finish adding the node to the Cluster
> Metadata Service
> [junit-timeout] java.lang.IllegalStateException: Can not commit
> transformation: "SERVER_ERROR"(class java.lang.NullPointerException).
> [junit-timeout] at
> org.apache.cassandra.tcm.ClusterMetadataService.lambda$commit$6(ClusterMetadataService.java:491)
> [junit-timeout] at
> org.apache.cassandra.tcm.ClusterMetadataService.commit(ClusterMetadataService.java:535)
> [junit-timeout] at
> org.apache.cassandra.tcm.ClusterMetadataService.commit(ClusterMetadataService.java:488)
> [junit-timeout] at
> org.apache.cassandra.tcm.sequences.ReconfigureCMS.executeNext(ReconfigureCMS.java:179)
> [junit-timeout] at
> org.apache.cassandra.tcm.sequences.InProgressSequences.resume(InProgressSequences.java:200)
> [junit-timeout] at
> org.apache.cassandra.tcm.sequences.InProgressSequences.finishInProgressSequences(InProgressSequences.java:72)
> [junit-timeout] at
> org.apache.cassandra.tcm.ClusterMetadataService.reconfigureCMS(ClusterMetadataService.java:372)
> [junit-timeout] at
> org.apache.cassandra.tcm.ClusterMetadataService.ensureCMSPlacement(ClusterMetadataService.java:379)
> [junit-timeout] at
> org.apache.cassandra.tcm.sequences.BootstrapAndReplace.executeNext(BootstrapAndReplace.java:274)
> [junit-timeout] at
> org.apache.cassandra.simulator.cluster.OnClusterReplace$ExecuteNextStep.lambda$new$f5e64c00$1(OnClusterReplace.java:162)
> [junit-timeout] at
> org.apache.cassandra.distributed.api.IInvokableInstance.unsafeRunOnThisThread(IInvokableInstance.java:85)
> [junit-timeout] at
> org.apache.cassandra.simulator.systems.SimulatedActionTask.lambda$asSafeRunnable$0(SimulatedActionTask.java:83)
> [junit-timeout] at
> org.apache.cassandra.simulator.systems.SimulatedActionTask$1.run(SimulatedActionTask.java:93)
> [junit-timeout] at
> org.apache.cassandra.simulator.systems.InterceptingExecutor$InterceptingPooledExecutor$WaitingThread.lambda$new$1(InterceptingExecutor.java:318)
> [junit-timeout] at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> [junit-timeout] at java.base/java.lang.Thread.run(Thread.java:829)
> {noformat}
> ...and underneath that...
> {noformat}
> [junit-timeout] Thread[ScheduledTasks:1,5,node3]
> [junit-timeout] java.lang.NullPointerException
> [junit-timeout] at
> org.apache.cassandra.utils.btree.AbstractBTreeMap.get(AbstractBTreeMap.java:92)
> [junit-timeout] at
> org.apache.cassandra.tcm.membership.Directory.endpoint(Directory.java:312)
> [junit-timeout] at
> org.apache.cassandra.tcm.transformations.cms.AdvanceCMSReconfiguration.executeRemove(AdvanceCMSReconfiguration.java:242)
> [junit-timeout] at
> org.apache.cassandra.tcm.transformations.cms.AdvanceCMSReconfiguration.execute(AdvanceCMSReconfiguration.java:123)
> [junit-timeout] at
> org.apache.cassandra.tcm.sequences.ReconfigureCMS.applyTo(ReconfigureCMS.java:149)
> [junit-timeout] at
>
[jira] [Updated] (CASSANDRA-19400) IndexStatusManager needs to prioritize SUCCESS over UNKNOWN states to maximize availability
[
https://issues.apache.org/jira/browse/CASSANDRA-19400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-19400:
Status: Review In Progress (was: Needs Committer)
> IndexStatusManager needs to prioritize SUCCESS over UNKNOWN states to
> maximize availability
> ---
>
> Key: CASSANDRA-19400
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19400
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/SAI
>Reporter: Caleb Rackliffe
>Assignee: Arun Ganesh
>Priority: Low
> Fix For: 5.0.x, 5.x
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> {{IndexStatusManager}} is responsible for knowing what SAI indexes are
> queryable across the ring, endpoint by endpoint. There are two statuses that
> SAI treats as queryable, but it should not treat them equally.
> {{BUILD_SUCCEEDED}} means the index is definitely available and should be
> able to serve queries without issue. {{UNKNOWN}} indicates that the status of
> the index hasn’t propagated yet to this coordinator. It may be just fine, or
> it may not be. If it isn’t a query will not return incorrect results, but it
> will fail. If there are enough {{BUILD_SUCCEEDED}} replicas, we should ignore
> {{UNKNOWN}} replicas and maximize availability. If the UNKNOWN replica is
> going to become {{BUILD_SUCCEEDED}} shortly, it will happily start taking
> requests at that point and spread the load. If not, we’ll avoid futile
> attempts to query it too early.
--
This message was sent by Atlassian Jira
(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-19400) IndexStatusManager needs to prioritize SUCCESS over UNKNOWN states to maximize availability
[
https://issues.apache.org/jira/browse/CASSANDRA-19400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-19400:
Reviewers: Caleb Rackliffe, Zhao Yang (was: Caleb Rackliffe)
> IndexStatusManager needs to prioritize SUCCESS over UNKNOWN states to
> maximize availability
> ---
>
> Key: CASSANDRA-19400
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19400
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/SAI
>Reporter: Caleb Rackliffe
>Assignee: Arun Ganesh
>Priority: Low
> Fix For: 5.0.x, 5.x
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> {{IndexStatusManager}} is responsible for knowing what SAI indexes are
> queryable across the ring, endpoint by endpoint. There are two statuses that
> SAI treats as queryable, but it should not treat them equally.
> {{BUILD_SUCCEEDED}} means the index is definitely available and should be
> able to serve queries without issue. {{UNKNOWN}} indicates that the status of
> the index hasn’t propagated yet to this coordinator. It may be just fine, or
> it may not be. If it isn’t a query will not return incorrect results, but it
> will fail. If there are enough {{BUILD_SUCCEEDED}} replicas, we should ignore
> {{UNKNOWN}} replicas and maximize availability. If the UNKNOWN replica is
> going to become {{BUILD_SUCCEEDED}} shortly, it will happily start taking
> requests at that point and spread the load. If not, we’ll avoid futile
> attempts to query it too early.
--
This message was sent by Atlassian Jira
(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-19794) NPE on Directory access during Memtable flush fails ShortPaxosSimulationTest
[
https://issues.apache.org/jira/browse/CASSANDRA-19794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-19794:
Summary: NPE on Directory access during Memtable flush fails
ShortPaxosSimulationTest (was: AccordSimpleFastPathTest)
> NPE on Directory access during Memtable flush fails ShortPaxosSimulationTest
>
>
> Key: CASSANDRA-19794
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19794
> Project: Cassandra
> Issue Type: Bug
> Components: Test/burn, Transactional Cluster Metadata
>Reporter: Caleb Rackliffe
>Assignee: Marcus Eriksson
>Priority: Normal
> Fix For: 5.x
>
>
> Run {{ShortPaxosSimulationTest}} w/ the following arguments on trunk:
> {noformat}
> PaxosSimulationRunner.main(new String[] { "run", "-n", "3..6", "-t", "1000",
> "-c", "2", "--cluster-action-limit", "2", "-s", "30", "--seed",
> "0xe0247e19a75e3bba" });
> {noformat}
> You should see a failure, starting with...
> {noformat}
> [junit-timeout] WARN [OptionalTasks:1] node5 2024-07-22 15:46:00,210
> LegacyStateListener.java:158 - Token -6148914691236517205 changing ownership
> from /127.0.0.1:7012 to /127.0.0.6:7012
> [junit-timeout] WARN [OptionalTasks:1] node6 2024-07-22 15:46:00,259
> SystemKeyspace.java:1287 - Using stored Gossip Generation 1577894856 as it is
> greater than current system time 1577894855. See CASSANDRA-3654 if you
> experience problems
> [junit-timeout] WARN [OptionalTasks:1] node6 2024-07-22 15:46:00,277
> LegacyStateListener.java:158 - Token -6148914691236517205 changing ownership
> from /127.0.0.1:7012 to /127.0.0.6:7012
> [junit-timeout] ERROR [isolatedExecutor:3] node6 2024-07-22 15:46:00,469
> ReconfigureCMS.java:184 - Could not finish adding the node to the Cluster
> Metadata Service
> [junit-timeout] java.lang.IllegalStateException: Can not commit
> transformation: "SERVER_ERROR"(class java.lang.NullPointerException).
> [junit-timeout] at
> org.apache.cassandra.tcm.ClusterMetadataService.lambda$commit$6(ClusterMetadataService.java:491)
> [junit-timeout] at
> org.apache.cassandra.tcm.ClusterMetadataService.commit(ClusterMetadataService.java:535)
> [junit-timeout] at
> org.apache.cassandra.tcm.ClusterMetadataService.commit(ClusterMetadataService.java:488)
> [junit-timeout] at
> org.apache.cassandra.tcm.sequences.ReconfigureCMS.executeNext(ReconfigureCMS.java:179)
> [junit-timeout] at
> org.apache.cassandra.tcm.sequences.InProgressSequences.resume(InProgressSequences.java:200)
> [junit-timeout] at
> org.apache.cassandra.tcm.sequences.InProgressSequences.finishInProgressSequences(InProgressSequences.java:72)
> [junit-timeout] at
> org.apache.cassandra.tcm.ClusterMetadataService.reconfigureCMS(ClusterMetadataService.java:372)
> [junit-timeout] at
> org.apache.cassandra.tcm.ClusterMetadataService.ensureCMSPlacement(ClusterMetadataService.java:379)
> [junit-timeout] at
> org.apache.cassandra.tcm.sequences.BootstrapAndReplace.executeNext(BootstrapAndReplace.java:274)
> [junit-timeout] at
> org.apache.cassandra.simulator.cluster.OnClusterReplace$ExecuteNextStep.lambda$new$f5e64c00$1(OnClusterReplace.java:162)
> [junit-timeout] at
> org.apache.cassandra.distributed.api.IInvokableInstance.unsafeRunOnThisThread(IInvokableInstance.java:85)
> [junit-timeout] at
> org.apache.cassandra.simulator.systems.SimulatedActionTask.lambda$asSafeRunnable$0(SimulatedActionTask.java:83)
> [junit-timeout] at
> org.apache.cassandra.simulator.systems.SimulatedActionTask$1.run(SimulatedActionTask.java:93)
> [junit-timeout] at
> org.apache.cassandra.simulator.systems.InterceptingExecutor$InterceptingPooledExecutor$WaitingThread.lambda$new$1(InterceptingExecutor.java:318)
> [junit-timeout] at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> [junit-timeout] at java.base/java.lang.Thread.run(Thread.java:829)
> {noformat}
> ...and underneath that...
> {noformat}
> [junit-timeout] Thread[ScheduledTasks:1,5,node3]
> [junit-timeout] java.lang.NullPointerException
> [junit-timeout] at
> org.apache.cassandra.utils.btree.AbstractBTreeMap.get(AbstractBTreeMap.java:92)
> [junit-timeout] at
> org.apache.cassandra.tcm.membership.Directory.endpoint(Directory.java:312)
> [junit-timeout] at
> org.apache.cassandra.tcm.transformations.cms.AdvanceCMSReconfiguration.executeRemove(AdvanceCMSReconfiguration.java:242)
> [junit-timeout] at
> org.apache.cassandra.tcm.transformations.cms.AdvanceCMSReconfiguration.execute(AdvanceCMSReconfiguration.java:123)
> [junit-timeout] at
> org.apache.cassandra.tcm.sequences.ReconfigureCMS.applyTo(ReconfigureCMS.java:149)
>
[jira] [Updated] (CASSANDRA-19794) AccordSimpleFastPathTest
[
https://issues.apache.org/jira/browse/CASSANDRA-19794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-19794:
Bug Category: Parent values: Correctness(12982)Level 1 values: API /
Semantic Implementation(12988)
Complexity: Normal
Discovered By: Fuzz Test
Fix Version/s: 5.x
Severity: Normal
Status: Open (was: Triage Needed)
CC [~samt] [~ifesdjeen]
> AccordSimpleFastPathTest
>
>
> Key: CASSANDRA-19794
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19794
> Project: Cassandra
> Issue Type: Bug
> Components: Test/burn, Transactional Cluster Metadata
>Reporter: Caleb Rackliffe
>Assignee: Marcus Eriksson
>Priority: Normal
> Fix For: 5.x
>
>
> Run {{ShortPaxosSimulationTest}} w/ the following arguments on trunk:
> {noformat}
> PaxosSimulationRunner.main(new String[] { "run", "-n", "3..6", "-t", "1000",
> "-c", "2", "--cluster-action-limit", "2", "-s", "30", "--seed",
> "0xe0247e19a75e3bba" });
> {noformat}
> You should see a failure, starting with...
> {noformat}
> [junit-timeout] WARN [OptionalTasks:1] node5 2024-07-22 15:46:00,210
> LegacyStateListener.java:158 - Token -6148914691236517205 changing ownership
> from /127.0.0.1:7012 to /127.0.0.6:7012
> [junit-timeout] WARN [OptionalTasks:1] node6 2024-07-22 15:46:00,259
> SystemKeyspace.java:1287 - Using stored Gossip Generation 1577894856 as it is
> greater than current system time 1577894855. See CASSANDRA-3654 if you
> experience problems
> [junit-timeout] WARN [OptionalTasks:1] node6 2024-07-22 15:46:00,277
> LegacyStateListener.java:158 - Token -6148914691236517205 changing ownership
> from /127.0.0.1:7012 to /127.0.0.6:7012
> [junit-timeout] ERROR [isolatedExecutor:3] node6 2024-07-22 15:46:00,469
> ReconfigureCMS.java:184 - Could not finish adding the node to the Cluster
> Metadata Service
> [junit-timeout] java.lang.IllegalStateException: Can not commit
> transformation: "SERVER_ERROR"(class java.lang.NullPointerException).
> [junit-timeout] at
> org.apache.cassandra.tcm.ClusterMetadataService.lambda$commit$6(ClusterMetadataService.java:491)
> [junit-timeout] at
> org.apache.cassandra.tcm.ClusterMetadataService.commit(ClusterMetadataService.java:535)
> [junit-timeout] at
> org.apache.cassandra.tcm.ClusterMetadataService.commit(ClusterMetadataService.java:488)
> [junit-timeout] at
> org.apache.cassandra.tcm.sequences.ReconfigureCMS.executeNext(ReconfigureCMS.java:179)
> [junit-timeout] at
> org.apache.cassandra.tcm.sequences.InProgressSequences.resume(InProgressSequences.java:200)
> [junit-timeout] at
> org.apache.cassandra.tcm.sequences.InProgressSequences.finishInProgressSequences(InProgressSequences.java:72)
> [junit-timeout] at
> org.apache.cassandra.tcm.ClusterMetadataService.reconfigureCMS(ClusterMetadataService.java:372)
> [junit-timeout] at
> org.apache.cassandra.tcm.ClusterMetadataService.ensureCMSPlacement(ClusterMetadataService.java:379)
> [junit-timeout] at
> org.apache.cassandra.tcm.sequences.BootstrapAndReplace.executeNext(BootstrapAndReplace.java:274)
> [junit-timeout] at
> org.apache.cassandra.simulator.cluster.OnClusterReplace$ExecuteNextStep.lambda$new$f5e64c00$1(OnClusterReplace.java:162)
> [junit-timeout] at
> org.apache.cassandra.distributed.api.IInvokableInstance.unsafeRunOnThisThread(IInvokableInstance.java:85)
> [junit-timeout] at
> org.apache.cassandra.simulator.systems.SimulatedActionTask.lambda$asSafeRunnable$0(SimulatedActionTask.java:83)
> [junit-timeout] at
> org.apache.cassandra.simulator.systems.SimulatedActionTask$1.run(SimulatedActionTask.java:93)
> [junit-timeout] at
> org.apache.cassandra.simulator.systems.InterceptingExecutor$InterceptingPooledExecutor$WaitingThread.lambda$new$1(InterceptingExecutor.java:318)
> [junit-timeout] at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> [junit-timeout] at java.base/java.lang.Thread.run(Thread.java:829)
> {noformat}
> ...and underneath that...
> {noformat}
> [junit-timeout] Thread[ScheduledTasks:1,5,node3]
> [junit-timeout] java.lang.NullPointerException
> [junit-timeout] at
> org.apache.cassandra.utils.btree.AbstractBTreeMap.get(AbstractBTreeMap.java:92)
> [junit-timeout] at
> org.apache.cassandra.tcm.membership.Directory.endpoint(Directory.java:312)
> [junit-timeout] at
> org.apache.cassandra.tcm.transformations.cms.AdvanceCMSReconfiguration.executeRemove(AdvanceCMSReconfiguration.java:242)
> [junit-timeout] at
> org.apache.cassandra.tcm.transformations.cms.AdvanceCMSReconfiguration.execute(AdvanceCMSReconfiguration.java:123)
> [junit-timeout] at
>
[jira] [Created] (CASSANDRA-19794) AccordSimpleFastPathTest
Caleb Rackliffe created CASSANDRA-19794:
---
Summary: AccordSimpleFastPathTest
Key: CASSANDRA-19794
URL: https://issues.apache.org/jira/browse/CASSANDRA-19794
Project: Cassandra
Issue Type: Bug
Components: Test/burn, Transactional Cluster Metadata
Reporter: Caleb Rackliffe
Assignee: Marcus Eriksson
Run {{ShortPaxosSimulationTest}} w/ the following arguments on trunk:
{noformat}
PaxosSimulationRunner.main(new String[] { "run", "-n", "3..6", "-t", "1000",
"-c", "2", "--cluster-action-limit", "2", "-s", "30", "--seed",
"0xe0247e19a75e3bba" });
{noformat}
You should see a failure, starting with...
{noformat}
[junit-timeout] WARN [OptionalTasks:1] node5 2024-07-22 15:46:00,210
LegacyStateListener.java:158 - Token -6148914691236517205 changing ownership
from /127.0.0.1:7012 to /127.0.0.6:7012
[junit-timeout] WARN [OptionalTasks:1] node6 2024-07-22 15:46:00,259
SystemKeyspace.java:1287 - Using stored Gossip Generation 1577894856 as it is
greater than current system time 1577894855. See CASSANDRA-3654 if you
experience problems
[junit-timeout] WARN [OptionalTasks:1] node6 2024-07-22 15:46:00,277
LegacyStateListener.java:158 - Token -6148914691236517205 changing ownership
from /127.0.0.1:7012 to /127.0.0.6:7012
[junit-timeout] ERROR [isolatedExecutor:3] node6 2024-07-22 15:46:00,469
ReconfigureCMS.java:184 - Could not finish adding the node to the Cluster
Metadata Service
[junit-timeout] java.lang.IllegalStateException: Can not commit transformation:
"SERVER_ERROR"(class java.lang.NullPointerException).
[junit-timeout] at
org.apache.cassandra.tcm.ClusterMetadataService.lambda$commit$6(ClusterMetadataService.java:491)
[junit-timeout] at
org.apache.cassandra.tcm.ClusterMetadataService.commit(ClusterMetadataService.java:535)
[junit-timeout] at
org.apache.cassandra.tcm.ClusterMetadataService.commit(ClusterMetadataService.java:488)
[junit-timeout] at
org.apache.cassandra.tcm.sequences.ReconfigureCMS.executeNext(ReconfigureCMS.java:179)
[junit-timeout] at
org.apache.cassandra.tcm.sequences.InProgressSequences.resume(InProgressSequences.java:200)
[junit-timeout] at
org.apache.cassandra.tcm.sequences.InProgressSequences.finishInProgressSequences(InProgressSequences.java:72)
[junit-timeout] at
org.apache.cassandra.tcm.ClusterMetadataService.reconfigureCMS(ClusterMetadataService.java:372)
[junit-timeout] at
org.apache.cassandra.tcm.ClusterMetadataService.ensureCMSPlacement(ClusterMetadataService.java:379)
[junit-timeout] at
org.apache.cassandra.tcm.sequences.BootstrapAndReplace.executeNext(BootstrapAndReplace.java:274)
[junit-timeout] at
org.apache.cassandra.simulator.cluster.OnClusterReplace$ExecuteNextStep.lambda$new$f5e64c00$1(OnClusterReplace.java:162)
[junit-timeout] at
org.apache.cassandra.distributed.api.IInvokableInstance.unsafeRunOnThisThread(IInvokableInstance.java:85)
[junit-timeout] at
org.apache.cassandra.simulator.systems.SimulatedActionTask.lambda$asSafeRunnable$0(SimulatedActionTask.java:83)
[junit-timeout] at
org.apache.cassandra.simulator.systems.SimulatedActionTask$1.run(SimulatedActionTask.java:93)
[junit-timeout] at
org.apache.cassandra.simulator.systems.InterceptingExecutor$InterceptingPooledExecutor$WaitingThread.lambda$new$1(InterceptingExecutor.java:318)
[junit-timeout] at
io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
[junit-timeout] at java.base/java.lang.Thread.run(Thread.java:829)
{noformat}
...and underneath that...
{noformat}
[junit-timeout] Thread[ScheduledTasks:1,5,node3]
[junit-timeout] java.lang.NullPointerException
[junit-timeout] at
org.apache.cassandra.utils.btree.AbstractBTreeMap.get(AbstractBTreeMap.java:92)
[junit-timeout] at
org.apache.cassandra.tcm.membership.Directory.endpoint(Directory.java:312)
[junit-timeout] at
org.apache.cassandra.tcm.transformations.cms.AdvanceCMSReconfiguration.executeRemove(AdvanceCMSReconfiguration.java:242)
[junit-timeout] at
org.apache.cassandra.tcm.transformations.cms.AdvanceCMSReconfiguration.execute(AdvanceCMSReconfiguration.java:123)
[junit-timeout] at
org.apache.cassandra.tcm.sequences.ReconfigureCMS.applyTo(ReconfigureCMS.java:149)
[junit-timeout] at
org.apache.cassandra.tcm.ClusterMetadata.writePlacementAllSettled(ClusterMetadata.java:275)
[junit-timeout] at
org.apache.cassandra.db.DiskBoundaryManager.getLocalRanges(DiskBoundaryManager.java:158)
[junit-timeout] at
org.apache.cassandra.db.DiskBoundaryManager.getDiskBoundaryValue(DiskBoundaryManager.java:121)
[junit-timeout] at
org.apache.cassandra.db.DiskBoundaryManager.getDiskBoundaries(DiskBoundaryManager.java:65)
[junit-timeout] at
[jira] [Updated] (CASSANDRA-19688) SAI support for BETWEEN operator
[ https://issues.apache.org/jira/browse/CASSANDRA-19688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Rackliffe updated CASSANDRA-19688: Reviewers: Caleb Rackliffe > SAI support for BETWEEN operator > > > Key: CASSANDRA-19688 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19688 > Project: Cassandra > Issue Type: New Feature > Components: CQL/Syntax, Feature/SAI >Reporter: Caleb Rackliffe >Assignee: Arun Ganesh >Priority: Normal > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > The new CQL BETWEEN operator should map pretty neatly to SAI’s internal RANGE > operator for numeric indexes. There’s no reason we shouldn’t support 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-19688) SAI support for BETWEEN operator
[ https://issues.apache.org/jira/browse/CASSANDRA-19688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Rackliffe updated CASSANDRA-19688: Test and Documentation Plan: expanding CQL test coverage for BETWEEN Status: Patch Available (was: In Progress) > SAI support for BETWEEN operator > > > Key: CASSANDRA-19688 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19688 > Project: Cassandra > Issue Type: New Feature > Components: CQL/Syntax, Feature/SAI >Reporter: Caleb Rackliffe >Assignee: Arun Ganesh >Priority: Normal > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > The new CQL BETWEEN operator should map pretty neatly to SAI’s internal RANGE > operator for numeric indexes. There’s no reason we shouldn’t support 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-19400) IndexStatusManager needs to prioritize SUCCESS over UNKNOWN states to maximize availability
[
https://issues.apache.org/jira/browse/CASSANDRA-19400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-19400:
Attachment: (was: ci_summary.html)
> IndexStatusManager needs to prioritize SUCCESS over UNKNOWN states to
> maximize availability
> ---
>
> Key: CASSANDRA-19400
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19400
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/SAI
>Reporter: Caleb Rackliffe
>Assignee: Arun Ganesh
>Priority: Low
> Fix For: 5.0.x, 5.x
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> {{IndexStatusManager}} is responsible for knowing what SAI indexes are
> queryable across the ring, endpoint by endpoint. There are two statuses that
> SAI treats as queryable, but it should not treat them equally.
> {{BUILD_SUCCEEDED}} means the index is definitely available and should be
> able to serve queries without issue. {{UNKNOWN}} indicates that the status of
> the index hasn’t propagated yet to this coordinator. It may be just fine, or
> it may not be. If it isn’t a query will not return incorrect results, but it
> will fail. If there are enough {{BUILD_SUCCEEDED}} replicas, we should ignore
> {{UNKNOWN}} replicas and maximize availability. If the UNKNOWN replica is
> going to become {{BUILD_SUCCEEDED}} shortly, it will happily start taking
> requests at that point and spread the load. If not, we’ll avoid futile
> attempts to query it too early.
--
This message was sent by Atlassian Jira
(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-19400) IndexStatusManager needs to prioritize SUCCESS over UNKNOWN states to maximize availability
[
https://issues.apache.org/jira/browse/CASSANDRA-19400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-19400:
Attachment: (was: ci_summary-1.html)
> IndexStatusManager needs to prioritize SUCCESS over UNKNOWN states to
> maximize availability
> ---
>
> Key: CASSANDRA-19400
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19400
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/SAI
>Reporter: Caleb Rackliffe
>Assignee: Arun Ganesh
>Priority: Low
> Fix For: 5.0.x, 5.x
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> {{IndexStatusManager}} is responsible for knowing what SAI indexes are
> queryable across the ring, endpoint by endpoint. There are two statuses that
> SAI treats as queryable, but it should not treat them equally.
> {{BUILD_SUCCEEDED}} means the index is definitely available and should be
> able to serve queries without issue. {{UNKNOWN}} indicates that the status of
> the index hasn’t propagated yet to this coordinator. It may be just fine, or
> it may not be. If it isn’t a query will not return incorrect results, but it
> will fail. If there are enough {{BUILD_SUCCEEDED}} replicas, we should ignore
> {{UNKNOWN}} replicas and maximize availability. If the UNKNOWN replica is
> going to become {{BUILD_SUCCEEDED}} shortly, it will happily start taking
> requests at that point and spread the load. If not, we’ll avoid futile
> attempts to query it too early.
--
This message was sent by Atlassian Jira
(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-19400) IndexStatusManager needs to prioritize SUCCESS over UNKNOWN states to maximize availability
[
https://issues.apache.org/jira/browse/CASSANDRA-19400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-19400:
Reviewers: Caleb Rackliffe, Caleb Rackliffe (was: Caleb Rackliffe)
Caleb Rackliffe, Caleb Rackliffe (was: Caleb Rackliffe)
Status: Review In Progress (was: Patch Available)
> IndexStatusManager needs to prioritize SUCCESS over UNKNOWN states to
> maximize availability
> ---
>
> Key: CASSANDRA-19400
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19400
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/SAI
>Reporter: Caleb Rackliffe
>Assignee: Arun Ganesh
>Priority: Low
> Fix For: 5.0.x, 5.x
>
> Attachments: ci_summary-1.html, ci_summary.html
>
> Time Spent: 2h
> Remaining Estimate: 0h
>
> {{IndexStatusManager}} is responsible for knowing what SAI indexes are
> queryable across the ring, endpoint by endpoint. There are two statuses that
> SAI treats as queryable, but it should not treat them equally.
> {{BUILD_SUCCEEDED}} means the index is definitely available and should be
> able to serve queries without issue. {{UNKNOWN}} indicates that the status of
> the index hasn’t propagated yet to this coordinator. It may be just fine, or
> it may not be. If it isn’t a query will not return incorrect results, but it
> will fail. If there are enough {{BUILD_SUCCEEDED}} replicas, we should ignore
> {{UNKNOWN}} replicas and maximize availability. If the UNKNOWN replica is
> going to become {{BUILD_SUCCEEDED}} shortly, it will happily start taking
> requests at that point and spread the load. If not, we’ll avoid futile
> attempts to query it too early.
--
This message was sent by Atlassian Jira
(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-19400) IndexStatusManager needs to prioritize SUCCESS over UNKNOWN states to maximize availability
[
https://issues.apache.org/jira/browse/CASSANDRA-19400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-19400:
Status: Needs Committer (was: Review In Progress)
> IndexStatusManager needs to prioritize SUCCESS over UNKNOWN states to
> maximize availability
> ---
>
> Key: CASSANDRA-19400
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19400
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/SAI
>Reporter: Caleb Rackliffe
>Assignee: Arun Ganesh
>Priority: Low
> Fix For: 5.0.x, 5.x
>
> Attachments: ci_summary-1.html, ci_summary.html
>
> Time Spent: 2h
> Remaining Estimate: 0h
>
> {{IndexStatusManager}} is responsible for knowing what SAI indexes are
> queryable across the ring, endpoint by endpoint. There are two statuses that
> SAI treats as queryable, but it should not treat them equally.
> {{BUILD_SUCCEEDED}} means the index is definitely available and should be
> able to serve queries without issue. {{UNKNOWN}} indicates that the status of
> the index hasn’t propagated yet to this coordinator. It may be just fine, or
> it may not be. If it isn’t a query will not return incorrect results, but it
> will fail. If there are enough {{BUILD_SUCCEEDED}} replicas, we should ignore
> {{UNKNOWN}} replicas and maximize availability. If the UNKNOWN replica is
> going to become {{BUILD_SUCCEEDED}} shortly, it will happily start taking
> requests at that point and spread the load. If not, we’ll avoid futile
> attempts to query it too early.
--
This message was sent by Atlassian Jira
(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-19400) IndexStatusManager needs to prioritize SUCCESS over UNKNOWN states to maximize availability
[
https://issues.apache.org/jira/browse/CASSANDRA-19400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17866554#comment-17866554
]
Caleb Rackliffe commented on CASSANDRA-19400:
-
For the second reviewer, note that the attached CI results do include a failure
in
{{secondary_indexes_test.py::TestSecondaryIndexes::test_failing_manual_rebuild_index}},
but that's been addressed by making sure the legacy 2i is queryable on
{{Status.FULL_REBUILD_STARTED}}. (Only SAI becomes non-queryable on full
rebuild.)
> IndexStatusManager needs to prioritize SUCCESS over UNKNOWN states to
> maximize availability
> ---
>
> Key: CASSANDRA-19400
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19400
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/SAI
>Reporter: Caleb Rackliffe
>Assignee: Arun Ganesh
>Priority: Low
> Fix For: 5.0.x, 5.x
>
> Attachments: ci_summary-1.html, ci_summary.html
>
> Time Spent: 2h
> Remaining Estimate: 0h
>
> {{IndexStatusManager}} is responsible for knowing what SAI indexes are
> queryable across the ring, endpoint by endpoint. There are two statuses that
> SAI treats as queryable, but it should not treat them equally.
> {{BUILD_SUCCEEDED}} means the index is definitely available and should be
> able to serve queries without issue. {{UNKNOWN}} indicates that the status of
> the index hasn’t propagated yet to this coordinator. It may be just fine, or
> it may not be. If it isn’t a query will not return incorrect results, but it
> will fail. If there are enough {{BUILD_SUCCEEDED}} replicas, we should ignore
> {{UNKNOWN}} replicas and maximize availability. If the UNKNOWN replica is
> going to become {{BUILD_SUCCEEDED}} shortly, it will happily start taking
> requests at that point and spread the load. If not, we’ll avoid futile
> attempts to query it too early.
--
This message was sent by Atlassian Jira
(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-19400) IndexStatusManager needs to prioritize SUCCESS over UNKNOWN states to maximize availability
[
https://issues.apache.org/jira/browse/CASSANDRA-19400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-19400:
Attachment: ci_summary-1.html
> IndexStatusManager needs to prioritize SUCCESS over UNKNOWN states to
> maximize availability
> ---
>
> Key: CASSANDRA-19400
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19400
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/SAI
>Reporter: Caleb Rackliffe
>Assignee: Arun Ganesh
>Priority: Low
> Fix For: 5.0.x, 5.x
>
> Attachments: ci_summary-1.html, ci_summary.html
>
> Time Spent: 2h
> Remaining Estimate: 0h
>
> {{IndexStatusManager}} is responsible for knowing what SAI indexes are
> queryable across the ring, endpoint by endpoint. There are two statuses that
> SAI treats as queryable, but it should not treat them equally.
> {{BUILD_SUCCEEDED}} means the index is definitely available and should be
> able to serve queries without issue. {{UNKNOWN}} indicates that the status of
> the index hasn’t propagated yet to this coordinator. It may be just fine, or
> it may not be. If it isn’t a query will not return incorrect results, but it
> will fail. If there are enough {{BUILD_SUCCEEDED}} replicas, we should ignore
> {{UNKNOWN}} replicas and maximize availability. If the UNKNOWN replica is
> going to become {{BUILD_SUCCEEDED}} shortly, it will happily start taking
> requests at that point and spread the load. If not, we’ll avoid futile
> attempts to query it too early.
--
This message was sent by Atlassian Jira
(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-19400) IndexStatusManager needs to prioritize SUCCESS over UNKNOWN states to maximize availability
[
https://issues.apache.org/jira/browse/CASSANDRA-19400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-19400:
Attachment: ci_summary.html
> IndexStatusManager needs to prioritize SUCCESS over UNKNOWN states to
> maximize availability
> ---
>
> Key: CASSANDRA-19400
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19400
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/SAI
>Reporter: Caleb Rackliffe
>Assignee: Arun Ganesh
>Priority: Low
> Fix For: 5.0.x, 5.x
>
> Attachments: ci_summary-1.html, ci_summary.html
>
> Time Spent: 2h
> Remaining Estimate: 0h
>
> {{IndexStatusManager}} is responsible for knowing what SAI indexes are
> queryable across the ring, endpoint by endpoint. There are two statuses that
> SAI treats as queryable, but it should not treat them equally.
> {{BUILD_SUCCEEDED}} means the index is definitely available and should be
> able to serve queries without issue. {{UNKNOWN}} indicates that the status of
> the index hasn’t propagated yet to this coordinator. It may be just fine, or
> it may not be. If it isn’t a query will not return incorrect results, but it
> will fail. If there are enough {{BUILD_SUCCEEDED}} replicas, we should ignore
> {{UNKNOWN}} replicas and maximize availability. If the UNKNOWN replica is
> going to become {{BUILD_SUCCEEDED}} shortly, it will happily start taking
> requests at that point and spread the load. If not, we’ll avoid futile
> attempts to query it too early.
--
This message was sent by Atlassian Jira
(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-19400) IndexStatusManager needs to prioritize SUCCESS over UNKNOWN states to maximize availability
[
https://issues.apache.org/jira/browse/CASSANDRA-19400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17866538#comment-17866538
]
Caleb Rackliffe commented on CASSANDRA-19400:
-
+1
> IndexStatusManager needs to prioritize SUCCESS over UNKNOWN states to
> maximize availability
> ---
>
> Key: CASSANDRA-19400
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19400
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/SAI
>Reporter: Caleb Rackliffe
>Assignee: Arun Ganesh
>Priority: Low
> Fix For: 5.0.x, 5.x
>
> Time Spent: 2h
> Remaining Estimate: 0h
>
> {{IndexStatusManager}} is responsible for knowing what SAI indexes are
> queryable across the ring, endpoint by endpoint. There are two statuses that
> SAI treats as queryable, but it should not treat them equally.
> {{BUILD_SUCCEEDED}} means the index is definitely available and should be
> able to serve queries without issue. {{UNKNOWN}} indicates that the status of
> the index hasn’t propagated yet to this coordinator. It may be just fine, or
> it may not be. If it isn’t a query will not return incorrect results, but it
> will fail. If there are enough {{BUILD_SUCCEEDED}} replicas, we should ignore
> {{UNKNOWN}} replicas and maximize availability. If the UNKNOWN replica is
> going to become {{BUILD_SUCCEEDED}} shortly, it will happily start taking
> requests at that point and spread the load. If not, we’ll avoid futile
> attempts to query it too early.
--
This message was sent by Atlassian Jira
(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-19766) Optionally disable cqlsh HISTORY command via env variable
[
https://issues.apache.org/jira/browse/CASSANDRA-19766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17865521#comment-17865521
]
Caleb Rackliffe edited comment on CASSANDRA-19766 at 7/12/24 3:19 PM:
--
It's probably a good enough hack for most people (see my previous
comment/realization). I'll close this at some point...
was (Author: maedhroz):
It's probably a good enough hack for most people (see my previous
comment/realization)
> Optionally disable cqlsh HISTORY command via env variable
> -
>
> Key: CASSANDRA-19766
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19766
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/cqlsh
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 5.0.x, 5.x
>
>
> There may be cases where we’d like to disable the saving and display of the
> history of {{cqlsh}} commands executed. This should be fairly straightforward
> to do via an environment variable.
--
This message was sent by Atlassian Jira
(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-19766) Optionally disable cqlsh HISTORY command via env variable
[
https://issues.apache.org/jira/browse/CASSANDRA-19766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17865521#comment-17865521
]
Caleb Rackliffe commented on CASSANDRA-19766:
-
It's probably a good enough hack for most people (see my previous
comment/realization)
> Optionally disable cqlsh HISTORY command via env variable
> -
>
> Key: CASSANDRA-19766
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19766
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/cqlsh
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 5.0.x, 5.x
>
>
> There may be cases where we’d like to disable the saving and display of the
> history of {{cqlsh}} commands executed. This should be fairly straightforward
> to do via an environment variable.
--
This message was sent by Atlassian Jira
(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-19759) CEP-15 (Accord): When starting a transaction in a table where Accord is not enabled, should fail fast rather than fail with lack of ranges
[
https://issues.apache.org/jira/browse/CASSANDRA-19759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17865241#comment-17865241
]
Caleb Rackliffe commented on CASSANDRA-19759:
-
+1 (left minor nit in PR)
> CEP-15 (Accord): When starting a transaction in a table where Accord is not
> enabled, should fail fast rather than fail with lack of ranges
> --
>
> Key: CASSANDRA-19759
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19759
> Project: Cassandra
> Issue Type: Bug
> Components: Accord
>Reporter: David Capwell
>Assignee: Youki Shiraishi
>Priority: Normal
> Fix For: NA
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Reported in Slack:
> https://the-asf.slack.com/archives/C0459N9R5C6/p1712831271287869
> The “accord_demo.txt” has the following
> {code}
> ccm create accord-cql-poc -n 3
> ccm start
> bin/cqlsh -e "create keyspace ks with replication={'class':'SimpleStrategy',
> 'replication_factor':3};"
> bin/cqlsh -e "create table ks.tbl1 (k int primary key, v int);"
> bin/cqlsh -e "create table ks.tbl2 (k int primary key, v int);"
> bin/nodetool -h ::::::7f00:0001 -p 7100
> createepochunsafe
> bin/nodetool -h ::::::7f00:0001 -p 7200
> createepochunsafe
> bin/nodetool -h ::::::7f00:0001 -p 7300
> createepochunsafe
> BEGIN TRANSACTION
> LET row1 = (SELECT * FROM ks.tbl1 WHERE k = 1);
> SELECT row1.v;
> IF row1 IS NULL THEN
> INSERT INTO ks.tbl1 (k, v) VALUES (1, 2);
> END IF
> COMMIT TRANSACTION;
> {code}
> If you run that it fails in an unclear way
> {code}
> cqlsh> BEGIN TRANSACTION
>... LET row1 = (SELECT * FROM ks.tbl1 WHERE k = 1);
>... SELECT row1.v;
>... IF row1 IS NULL THEN
>... INSERT INTO ks.tbl1 (k, v) VALUES (1, 2);
>... END IF
>... COMMIT TRANSACTION;
> NoHostAvailable: ('Unable to complete the operation against any hosts',
> {: error] message="java.lang.IllegalStateException: Unable to select a HomeKey
> as the topology does not have any ranges for epoch 17">})
> {code}
> The issue is that the table was not marked as an Accord table; aka missing
> {code}
> WITH transactional_mode='full'
> {code}
> The demo should be updated to show this, but the error message should also be
> improved. We validate that the table exists but now that the metadata is
> required we should also enforce this in CQL validation
--
This message was sent by Atlassian Jira
(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-19759) CEP-15 (Accord): When starting a transaction in a table where Accord is not enabled, should fail fast rather than fail with lack of ranges
[
https://issues.apache.org/jira/browse/CASSANDRA-19759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17865240#comment-17865240
]
Caleb Rackliffe commented on CASSANDRA-19759:
-
I've had a TODO for a while in CASSANDRA-18107 to get rid of or integrate
\{{accord_demo.txt}} into some larger thing like
\{{o.a.c.index.sai.README.md}}. Minor changes to keep it valid for now are fine.
> CEP-15 (Accord): When starting a transaction in a table where Accord is not
> enabled, should fail fast rather than fail with lack of ranges
> --
>
> Key: CASSANDRA-19759
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19759
> Project: Cassandra
> Issue Type: Bug
> Components: Accord
>Reporter: David Capwell
>Assignee: Youki Shiraishi
>Priority: Normal
> Fix For: NA
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Reported in Slack:
> https://the-asf.slack.com/archives/C0459N9R5C6/p1712831271287869
> The “accord_demo.txt” has the following
> {code}
> ccm create accord-cql-poc -n 3
> ccm start
> bin/cqlsh -e "create keyspace ks with replication={'class':'SimpleStrategy',
> 'replication_factor':3};"
> bin/cqlsh -e "create table ks.tbl1 (k int primary key, v int);"
> bin/cqlsh -e "create table ks.tbl2 (k int primary key, v int);"
> bin/nodetool -h ::::::7f00:0001 -p 7100
> createepochunsafe
> bin/nodetool -h ::::::7f00:0001 -p 7200
> createepochunsafe
> bin/nodetool -h ::::::7f00:0001 -p 7300
> createepochunsafe
> BEGIN TRANSACTION
> LET row1 = (SELECT * FROM ks.tbl1 WHERE k = 1);
> SELECT row1.v;
> IF row1 IS NULL THEN
> INSERT INTO ks.tbl1 (k, v) VALUES (1, 2);
> END IF
> COMMIT TRANSACTION;
> {code}
> If you run that it fails in an unclear way
> {code}
> cqlsh> BEGIN TRANSACTION
>... LET row1 = (SELECT * FROM ks.tbl1 WHERE k = 1);
>... SELECT row1.v;
>... IF row1 IS NULL THEN
>... INSERT INTO ks.tbl1 (k, v) VALUES (1, 2);
>... END IF
>... COMMIT TRANSACTION;
> NoHostAvailable: ('Unable to complete the operation against any hosts',
> {: error] message="java.lang.IllegalStateException: Unable to select a HomeKey
> as the topology does not have any ranges for epoch 17">})
> {code}
> The issue is that the table was not marked as an Accord table; aka missing
> {code}
> WITH transactional_mode='full'
> {code}
> The demo should be updated to show this, but the error message should also be
> improved. We validate that the table exists but now that the metadata is
> required we should also enforce this in CQL validation
--
This message was sent by Atlassian Jira
(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-19759) CEP-15 (Accord): When starting a transaction in a table where Accord is not enabled, should fail fast rather than fail with lack of ranges
[
https://issues.apache.org/jira/browse/CASSANDRA-19759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-19759:
Test and Documentation Plan: new coverage in
[TransactionStatementTest|https://github.com/apache/cassandra/pull/3413#diff-0c7a4cee812613339e7ba3d22a20c7c05af4011a1ac6183b11a62758549e6b67]
Status: Patch Available (was: In Progress)
> CEP-15 (Accord): When starting a transaction in a table where Accord is not
> enabled, should fail fast rather than fail with lack of ranges
> --
>
> Key: CASSANDRA-19759
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19759
> Project: Cassandra
> Issue Type: Bug
> Components: Accord
>Reporter: David Capwell
>Assignee: Youki Shiraishi
>Priority: Normal
> Fix For: NA
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Reported in Slack:
> https://the-asf.slack.com/archives/C0459N9R5C6/p1712831271287869
> The “accord_demo.txt” has the following
> {code}
> ccm create accord-cql-poc -n 3
> ccm start
> bin/cqlsh -e "create keyspace ks with replication={'class':'SimpleStrategy',
> 'replication_factor':3};"
> bin/cqlsh -e "create table ks.tbl1 (k int primary key, v int);"
> bin/cqlsh -e "create table ks.tbl2 (k int primary key, v int);"
> bin/nodetool -h ::::::7f00:0001 -p 7100
> createepochunsafe
> bin/nodetool -h ::::::7f00:0001 -p 7200
> createepochunsafe
> bin/nodetool -h ::::::7f00:0001 -p 7300
> createepochunsafe
> BEGIN TRANSACTION
> LET row1 = (SELECT * FROM ks.tbl1 WHERE k = 1);
> SELECT row1.v;
> IF row1 IS NULL THEN
> INSERT INTO ks.tbl1 (k, v) VALUES (1, 2);
> END IF
> COMMIT TRANSACTION;
> {code}
> If you run that it fails in an unclear way
> {code}
> cqlsh> BEGIN TRANSACTION
>... LET row1 = (SELECT * FROM ks.tbl1 WHERE k = 1);
>... SELECT row1.v;
>... IF row1 IS NULL THEN
>... INSERT INTO ks.tbl1 (k, v) VALUES (1, 2);
>... END IF
>... COMMIT TRANSACTION;
> NoHostAvailable: ('Unable to complete the operation against any hosts',
> {: error] message="java.lang.IllegalStateException: Unable to select a HomeKey
> as the topology does not have any ranges for epoch 17">})
> {code}
> The issue is that the table was not marked as an Accord table; aka missing
> {code}
> WITH transactional_mode='full'
> {code}
> The demo should be updated to show this, but the error message should also be
> improved. We validate that the table exists but now that the metadata is
> required we should also enforce this in CQL validation
--
This message was sent by Atlassian Jira
(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-19759) CEP-15 (Accord): When starting a transaction in a table where Accord is not enabled, should fail fast rather than fail with lack of ranges
[
https://issues.apache.org/jira/browse/CASSANDRA-19759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-19759:
Reviewers: Caleb Rackliffe, David Capwell, Caleb Rackliffe
Caleb Rackliffe, David Capwell, Caleb Rackliffe (was: Caleb
Rackliffe, David Capwell)
Status: Review In Progress (was: Patch Available)
> CEP-15 (Accord): When starting a transaction in a table where Accord is not
> enabled, should fail fast rather than fail with lack of ranges
> --
>
> Key: CASSANDRA-19759
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19759
> Project: Cassandra
> Issue Type: Bug
> Components: Accord
>Reporter: David Capwell
>Assignee: Youki Shiraishi
>Priority: Normal
> Fix For: NA
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Reported in Slack:
> https://the-asf.slack.com/archives/C0459N9R5C6/p1712831271287869
> The “accord_demo.txt” has the following
> {code}
> ccm create accord-cql-poc -n 3
> ccm start
> bin/cqlsh -e "create keyspace ks with replication={'class':'SimpleStrategy',
> 'replication_factor':3};"
> bin/cqlsh -e "create table ks.tbl1 (k int primary key, v int);"
> bin/cqlsh -e "create table ks.tbl2 (k int primary key, v int);"
> bin/nodetool -h ::::::7f00:0001 -p 7100
> createepochunsafe
> bin/nodetool -h ::::::7f00:0001 -p 7200
> createepochunsafe
> bin/nodetool -h ::::::7f00:0001 -p 7300
> createepochunsafe
> BEGIN TRANSACTION
> LET row1 = (SELECT * FROM ks.tbl1 WHERE k = 1);
> SELECT row1.v;
> IF row1 IS NULL THEN
> INSERT INTO ks.tbl1 (k, v) VALUES (1, 2);
> END IF
> COMMIT TRANSACTION;
> {code}
> If you run that it fails in an unclear way
> {code}
> cqlsh> BEGIN TRANSACTION
>... LET row1 = (SELECT * FROM ks.tbl1 WHERE k = 1);
>... SELECT row1.v;
>... IF row1 IS NULL THEN
>... INSERT INTO ks.tbl1 (k, v) VALUES (1, 2);
>... END IF
>... COMMIT TRANSACTION;
> NoHostAvailable: ('Unable to complete the operation against any hosts',
> {: error] message="java.lang.IllegalStateException: Unable to select a HomeKey
> as the topology does not have any ranges for epoch 17">})
> {code}
> The issue is that the table was not marked as an Accord table; aka missing
> {code}
> WITH transactional_mode='full'
> {code}
> The demo should be updated to show this, but the error message should also be
> improved. We validate that the table exists but now that the metadata is
> required we should also enforce this in CQL validation
--
This message was sent by Atlassian Jira
(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-19764) Corruption can occur while a field is being added to UDT clustering key
[
https://issues.apache.org/jira/browse/CASSANDRA-19764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17865223#comment-17865223
]
Caleb Rackliffe commented on CASSANDRA-19764:
-
bq. I'm not sure the test is actually getting diverging schemas with
cluster.coordinator(1).execute("alter type " + KEYSPACE + ".a add bar text",
ConsistencyLevel.QUORUM)
CC [~samt]
> Corruption can occur while a field is being added to UDT clustering key
> ---
>
> Key: CASSANDRA-19764
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19764
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/UDT
>Reporter: Branimir Lambov
>Priority: Normal
>
> CASSANDRA-15938 made some improvements in how unknown components in UDTs are
> treated. Unfortunately this can cause corruption as soon as more than one
> value is inserted for a partition.
> The problem can be easily shown by modifying the
> {{FrozenUDTTest.testDivergentSchema}} test to insert two entries in the wrong
> order:
> {code:java}
> cluster.coordinator(1).execute("insert into " + KEYSPACE + ".x (id, ck, i)
> VALUES (?, " + json(1, 2) + ", ? )", ConsistencyLevel.ALL,
> 1, 2);
> cluster.coordinator(1).execute("insert into " + KEYSPACE + ".x (id, ck, i)
> VALUES (?, " + json(1, 1) + ", ? )", ConsistencyLevel.ALL,
> 1, 1);
> {code}
> after which we can get corrupted sstable state, shown as a
> {code:java}
> java.lang.AssertionError: Lower bound [SSTABLE_LOWER_BOUND(1) ]is bigger than
> first returned value [Row: ck=1 | i=2]
> {code}
> exception, or results like {{[[1],[2],[2],[1]]}} or {{[[2],[1],[2]]}} for
> {{select i from x WHERE id = 1}} depending on which node we use as
> coordinator.
> Because we don't know the type of new fields and cannot properly order
> entries, we need to outright reject UDT keys that are not compatible with a
> replica's schema.
--
This message was sent by Atlassian Jira
(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-19766) Optionally disable cqlsh HISTORY command via env variable
[
https://issues.apache.org/jira/browse/CASSANDRA-19766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17865185#comment-17865185
]
Caleb Rackliffe commented on CASSANDRA-19766:
-
Before someone else chimes in, I guess we can sort of do this by just setting
{{CQL_HISTORY}} to {{/dev/null}}
> Optionally disable cqlsh HISTORY command via env variable
> -
>
> Key: CASSANDRA-19766
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19766
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/cqlsh
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 5.0.x, 5.x
>
>
> There may be cases where we’d like to disable the saving and display of the
> history of {{cqlsh}} commands executed. This should be fairly straightforward
> to do via an environment variable.
--
This message was sent by Atlassian Jira
(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-19766) Optionally disable cqlsh HISTORY command via env variable
[
https://issues.apache.org/jira/browse/CASSANDRA-19766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-19766:
Change Category: Operability
Complexity: Low Hanging Fruit
Fix Version/s: 5.0.x
5.x
Status: Open (was: Triage Needed)
> Optionally disable cqlsh HISTORY command via env variable
> -
>
> Key: CASSANDRA-19766
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19766
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/cqlsh
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 5.0.x, 5.x
>
>
> There may be cases where we’d like to disable the saving and display of the
> history of {{cqlsh}} commands executed. This should be fairly straightforward
> to do via an environment variable.
--
This message was sent by Atlassian Jira
(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-19766) Optionally disable cqlsh HISTORY command via env variable
Caleb Rackliffe created CASSANDRA-19766:
---
Summary: Optionally disable cqlsh HISTORY command via env variable
Key: CASSANDRA-19766
URL: https://issues.apache.org/jira/browse/CASSANDRA-19766
Project: Cassandra
Issue Type: Improvement
Components: Tool/cqlsh
Reporter: Caleb Rackliffe
Assignee: Caleb Rackliffe
There may be cases where we’d like to disable the saving and display of the
history of {{cqlsh}} commands executed. This should be fairly straightforward
to do via an environment variable.
--
This message was sent by Atlassian Jira
(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-19764) Corruption can occur while a field is being added to UDT clustering key
[
https://issues.apache.org/jira/browse/CASSANDRA-19764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17865170#comment-17865170
]
Caleb Rackliffe commented on CASSANDRA-19764:
-
So to be clear, this should reproduce on {{trunk}} as...
{noformat}
@Test
public void testDivergentSchemas() throws Throwable
{
try (Cluster cluster = init(Cluster.create(2)))
{
cluster.schemaChange("create type " + KEYSPACE + ".a (foo text)");
cluster.schemaChange("create table " + KEYSPACE + ".x (id int, ck
frozen, i int, primary key (id, ck))");
cluster.filters().verbs(Verb.TCM_REPLICATION.id).drop().on();
cluster.coordinator(1).execute("alter type " + KEYSPACE + ".a add bar
text", ConsistencyLevel.QUORUM);
cluster.coordinator(1).execute("insert into " + KEYSPACE + ".x (id, ck,
i) VALUES (?, " + json(1, 2) + ", ? )", ConsistencyLevel.ALL, 1, 2);
cluster.coordinator(1).execute("insert into " + KEYSPACE + ".x (id, ck,
i) VALUES (?, " + json(1, 1) + ", ? )", ConsistencyLevel.ALL, 1, 1);
cluster.get(2).flush(KEYSPACE);
Object[][] res1 = cluster.coordinator(1).execute("select i from " +
KEYSPACE + ".x WHERE id = 1", ConsistencyLevel.ALL);
Object[][] res2 = cluster.coordinator(2).execute("select i from " +
KEYSPACE + ".x WHERE id = 1", ConsistencyLevel.ALL);
assertArrayEquals(res1, res2);
}
}
{noformat}
Not able to get a failure, but perhaps I'm missing something. Either way, it
seems like a bad idea to allow altering UDTs once they are part of a primary
key...
> Corruption can occur while a field is being added to UDT clustering key
> ---
>
> Key: CASSANDRA-19764
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19764
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/UDT
>Reporter: Branimir Lambov
>Priority: Normal
>
> CASSANDRA-15938 made some improvements in how unknown components in UDTs are
> treated. Unfortunately this can cause corruption as soon as more than one
> value is inserted for a partition.
> The problem can be easily shown by modifying the
> {{FrozenUDTTest.testDivergentSchema}} test to insert two entries in the wrong
> order:
> {code:java}
> cluster.coordinator(1).execute("insert into " + KEYSPACE + ".x (id, ck, i)
> VALUES (?, " + json(1, 2) + ", ? )", ConsistencyLevel.ALL,
> 1, 2);
> cluster.coordinator(1).execute("insert into " + KEYSPACE + ".x (id, ck, i)
> VALUES (?, " + json(1, 1) + ", ? )", ConsistencyLevel.ALL,
> 1, 1);
> {code}
> after which we can get corrupted sstable state, shown as a
> {code:java}
> java.lang.AssertionError: Lower bound [SSTABLE_LOWER_BOUND(1) ]is bigger than
> first returned value [Row: ck=1 | i=2]
> {code}
> exception, or results like {{[[1],[2],[2],[1]]}} or {{[[2],[1],[2]]}} for
> {{select i from x WHERE id = 1}} depending on which node we use as
> coordinator.
> Because we don't know the type of new fields and cannot properly order
> entries, we need to outright reject UDT keys that are not compatible with a
> replica's schema.
--
This message was sent by Atlassian Jira
(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-19321) Accord: Command to mark replicas as “stale" for decommission
[ https://issues.apache.org/jira/browse/CASSANDRA-19321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Rackliffe updated CASSANDRA-19321: Fix Version/s: NA (was: 5.x) > Accord: Command to mark replicas as “stale" for decommission > > > Key: CASSANDRA-19321 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19321 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: Benedict Elliott Smith >Assignee: Caleb Rackliffe >Priority: High > Fix For: NA > > > So that other replicas may continue to cleanup their state, we must have an > operator command for marking replicas as stale so that the remaining replicas > do not wait for them to coordinate their durability status. -- This message was sent by Atlassian Jira (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-19321) Accord: Command to mark replicas as “stale" for decommission
[ https://issues.apache.org/jira/browse/CASSANDRA-19321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Rackliffe updated CASSANDRA-19321: Fix Version/s: (was: NA) > Accord: Command to mark replicas as “stale" for decommission > > > Key: CASSANDRA-19321 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19321 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: Benedict Elliott Smith >Assignee: Caleb Rackliffe >Priority: High > > So that other replicas may continue to cleanup their state, we must have an > operator command for marking replicas as stale so that the remaining replicas > do not wait for them to coordinate their durability status. -- This message was sent by Atlassian Jira (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-19321) Accord: Command to mark replicas as “stale" for decommission
[ https://issues.apache.org/jira/browse/CASSANDRA-19321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Rackliffe updated CASSANDRA-19321: Change Category: Operability Complexity: Normal Fix Version/s: 5.x Priority: High (was: Normal) Status: Open (was: Triage Needed) > Accord: Command to mark replicas as “stale" for decommission > > > Key: CASSANDRA-19321 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19321 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: Benedict Elliott Smith >Assignee: Caleb Rackliffe >Priority: High > Fix For: 5.x > > > So that other replicas may continue to cleanup their state, we must have an > operator command for marking replicas as stale so that the remaining replicas > do not wait for them to coordinate their durability status. -- This message was sent by Atlassian Jira (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-19321) Accord: Command to mark replicas as “stale" for decommission
[
https://issues.apache.org/jira/browse/CASSANDRA-19321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17860654#comment-17860654
]
Caleb Rackliffe edited comment on CASSANDRA-19321 at 7/8/24 4:05 PM:
-
Implementation Notes (draft)
- {{ClusterMetadata}} contains a set of CMS node IDs for replicas that should
be considered stale
-- This could initially sit alongside {{AccordFastPath}}
- nodetool command group for Accord, similar to {{CMSAdmin}}
-- {{nodetool accord mark_stale }} feeds hostname to the server, where
it's mapped to a CMS node ID
-- {{ClusterMetadata}} is updated, i.e. a transformation committed that
resembles {{ReconfigureAccordFastPath}}, but adds replica to the stale set and
produces the new metadata.
-- Care probably needs to be taken to ensure we don't mark too many nodes stale
and therefore stop guaranteeing quorums.
-
{{CoordinateDurabilityScheduling#coordinateShardDurableAfterExclusiveSyncPoint()}},
via {{CoordinateShardDurable#coordinate()}}, uses updated {{Topology}} to
exclude stale replicas from the set we need to wait for. (However, we always
need to wait for at least a quorum. Should this even be possible if we don't
allow marking too many stale?)
-- {{AccordTopology}} and related classes may need additional logic to
synthesize Accord {{Topology}} instances from {{ClusterMetadata}}.
was (Author: maedhroz):
Implementation Notes (draft)
- {{ClusterMetadata}} contains a set of CMS node IDs for replicas that should
be considered stale
-- This could initially sit alongside {{AccordFastPath}}
- nodetool command group for Accord, similar to {{CMSAdmin}}
-- {{nodetool accord mark_stale }} feeds hostname to the server, where
it's mapped to a CMS node ID
-- {{ClusterMetadata}} is updated, i.e. a transformation committed that
resembles {{ReconfigureAccordFastPath}}, but adds replica to the stale set and
produces the new metadata.
-
{{CoordinateDurabilityScheduling#coordinateShardDurableAfterExclusiveSyncPoint()}},
via {{CoordinateShardDurable#coordinate()}}, uses updated {{Topology}} to
exclude stale replicas from the set we need to wait for.
-- {{AccordTopology}} and related classes may need additional logic to
synthesize Accord {{Topology}} instances from {{ClusterMetadata}}.
> Accord: Command to mark replicas as “stale" for decommission
>
>
> Key: CASSANDRA-19321
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19321
> Project: Cassandra
> Issue Type: Improvement
> Components: Accord
>Reporter: Benedict Elliott Smith
>Assignee: Caleb Rackliffe
>Priority: Normal
>
> So that other replicas may continue to cleanup their state, we must have an
> operator command for marking replicas as stale so that the remaining replicas
> do not wait for them to coordinate their durability status.
--
This message was sent by Atlassian Jira
(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-17445) Library airlift/airline has been deprecated
[ https://issues.apache.org/jira/browse/CASSANDRA-17445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Rackliffe updated CASSANDRA-17445: Reviewers: Caleb Rackliffe > Library airlift/airline has been deprecated > --- > > Key: CASSANDRA-17445 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17445 > Project: Cassandra > Issue Type: Task > Components: Dependencies >Reporter: Tibor Repasi >Assignee: Maxim Muzafarov >Priority: Normal > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > The [airlift/airline|https://github.com/airlift/airline] library has been > deprecated and is not maintained since [8 Jun > 2021|https://github.com/airlift/airline/commit/ae3d7e103bdc140969bde944d4ba09345d663a61]. > It is used in many tools and some tests of Cassandra which should be > reviewed. > Tools using that library: > * org.apache.cassandra.tools.JMXTool > * org.apache.cassandra.tools.NodeTool > * org.apache.cassandra.stress.Compaction > * org.apache.cassandra.fqltool.FullQueryLogTool > Tests using it: > * org.apache.cassandra.simulator.SimulationRunner > Alternatives (as suggested in the depreciation notice): > * [Airline 2|https://rvesse.github.io/airline/] > * [picocli|https://picocli.info] -- This message was sent by Atlassian Jira (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-19704) UnsupportedOperationException is thrown when no space for LCS
[
https://issues.apache.org/jira/browse/CASSANDRA-19704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-19704:
Fix Version/s: 4.0.14
4.1.6
5.0
5.1
(was: 5.x)
(was: 4.0.x)
(was: 4.1.x)
(was: 5.0.x)
Since Version: 4.0
Source Control Link:
https://github.com/apache/cassandra/commit/d54646e40957ffc18f651753941fac3068b79f8e
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Committed as
https://github.com/apache/cassandra/commit/d54646e40957ffc18f651753941fac3068b79f8e
> UnsupportedOperationException is thrown when no space for LCS
> -
>
> Key: CASSANDRA-19704
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19704
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Compaction/LCS
>Reporter: Zhao Yang
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.0.14, 4.1.6, 5.0, 5.1
>
> Attachments: ci_summary-1.html, ci_summary-2.html, ci_summary-3.html,
> ci_summary.html
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In {{CompactionTask#buildCompactionCandidatesForAvailableDiskSpace}} with
> LCS, if node has limited disk space and can't remove any sstable from L0 or
> L1 in {{{}LeveledCompactionTask#reduceScopeForLimitedSpace{}}},
> {{LeveledCompactionTask#partialCompactionsAcceptable}} will throw
> {{UnsupportedOperationException}}.
> We should handle {{LeveledCompactionTask#partialCompactionsAcceptable}} more
> gracefully with {{return level <= 1}} or simply {{true}} since
> {{reduceScopeForLimitedSpace}} only removes sstable from L0 or L1.
> Related https://issues.apache.org/jira/browse/CASSANDRA-17272
--
This message was sent by Atlassian Jira
(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-19400) IndexStatusManager needs to prioritize SUCCESS over UNKNOWN states to maximize availability
[
https://issues.apache.org/jira/browse/CASSANDRA-19400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17862516#comment-17862516
]
Caleb Rackliffe commented on CASSANDRA-19400:
-
[~arkn98] Hi there! Just checking in on this. Let me know if you need any
further help or to reassign...
> IndexStatusManager needs to prioritize SUCCESS over UNKNOWN states to
> maximize availability
> ---
>
> Key: CASSANDRA-19400
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19400
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/SAI
>Reporter: Caleb Rackliffe
>Assignee: Arun Ganesh
>Priority: Low
> Fix For: 5.0.x, 5.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> {{IndexStatusManager}} is responsible for knowing what SAI indexes are
> queryable across the ring, endpoint by endpoint. There are two statuses that
> SAI treats as queryable, but it should not treat them equally.
> {{BUILD_SUCCEEDED}} means the index is definitely available and should be
> able to serve queries without issue. {{UNKNOWN}} indicates that the status of
> the index hasn’t propagated yet to this coordinator. It may be just fine, or
> it may not be. If it isn’t a query will not return incorrect results, but it
> will fail. If there are enough {{BUILD_SUCCEEDED}} replicas, we should ignore
> {{UNKNOWN}} replicas and maximize availability. If the UNKNOWN replica is
> going to become {{BUILD_SUCCEEDED}} shortly, it will happily start taking
> requests at that point and spread the load. If not, we’ll avoid futile
> attempts to query it too early.
--
This message was sent by Atlassian Jira
(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-19704) UnsupportedOperationException is thrown when no space for LCS
[
https://issues.apache.org/jira/browse/CASSANDRA-19704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-19704:
Status: Ready to Commit (was: Review In Progress)
[~jasonstack] Partly because I'm going to be out until next Monday, I'm going
to just move forward to commit the {{level == 0}} version of the fix. We may
miss an opportunity to compact some expired SSTables, but that can be improved
later.
> UnsupportedOperationException is thrown when no space for LCS
> -
>
> Key: CASSANDRA-19704
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19704
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Compaction/LCS
>Reporter: Zhao Yang
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x
>
> Attachments: ci_summary-1.html, ci_summary-2.html, ci_summary-3.html,
> ci_summary.html
>
>
> In {{CompactionTask#buildCompactionCandidatesForAvailableDiskSpace}} with
> LCS, if node has limited disk space and can't remove any sstable from L0 or
> L1 in {{{}LeveledCompactionTask#reduceScopeForLimitedSpace{}}},
> {{LeveledCompactionTask#partialCompactionsAcceptable}} will throw
> {{UnsupportedOperationException}}.
> We should handle {{LeveledCompactionTask#partialCompactionsAcceptable}} more
> gracefully with {{return level <= 1}} or simply {{true}} since
> {{reduceScopeForLimitedSpace}} only removes sstable from L0 or L1.
> Related https://issues.apache.org/jira/browse/CASSANDRA-17272
--
This message was sent by Atlassian Jira
(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-19704) UnsupportedOperationException is thrown when no space for LCS
[
https://issues.apache.org/jira/browse/CASSANDRA-19704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-19704:
Reviewers: Marcus Eriksson, Zhao Yang (was: Zhao Yang)
> UnsupportedOperationException is thrown when no space for LCS
> -
>
> Key: CASSANDRA-19704
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19704
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Compaction/LCS
>Reporter: Zhao Yang
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x
>
> Attachments: ci_summary-1.html, ci_summary-2.html, ci_summary-3.html,
> ci_summary.html
>
>
> In {{CompactionTask#buildCompactionCandidatesForAvailableDiskSpace}} with
> LCS, if node has limited disk space and can't remove any sstable from L0 or
> L1 in {{{}LeveledCompactionTask#reduceScopeForLimitedSpace{}}},
> {{LeveledCompactionTask#partialCompactionsAcceptable}} will throw
> {{UnsupportedOperationException}}.
> We should handle {{LeveledCompactionTask#partialCompactionsAcceptable}} more
> gracefully with {{return level <= 1}} or simply {{true}} since
> {{reduceScopeForLimitedSpace}} only removes sstable from L0 or L1.
> Related https://issues.apache.org/jira/browse/CASSANDRA-17272
--
This message was sent by Atlassian Jira
(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-19604) Add support for BETWEEN operator
[
https://issues.apache.org/jira/browse/CASSANDRA-19604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17861270#comment-17861270
]
Caleb Rackliffe commented on CASSANDRA-19604:
-
Was taking a look at this. Is this bit unused in the grammar? (i.e. in
{{Parser.g}})
{noformat}
betweenLiterals returns [Terms.Raw literals]
@init { List list = new ArrayList<>(); }
@after { $literals = Terms.Raw.of(list); }
: t1=tupleLiteral { list.add(t1); } K_AND t2=tupleLiteral { list.add(t2); }
;
{noformat}
> Add support for BETWEEN operator
>
>
> Key: CASSANDRA-19604
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19604
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Benjamin Lerer
>Assignee: Simon Chess
>Priority: Normal
> Fix For: 5.1
>
> Time Spent: 3h 20m
> Remaining Estimate: 0h
>
> CQL support the {{>=}} and {{<=}} but does not support yet the {{BETWEEN}}
> operator. After CASSANDRA-19341 adding new operators should be much simpler
> and safer than it use to be.
> For the scope of this ticket {{BETWEEN}} support should be added for
> {{WHERE}} clauses of {{SELECT}} and {{DELETE}} queries (for single column and
> multi-column restrictions). NOT BETWEEN should be added and should be
> supported everywhere BETWEEN is.
> +Additional information for newcomers:+
> Parts that will need to be modified:
> * {{Lexer.g}} and {{Parser.g}} to add support for the new keyword and syntax
> * The {{Operator.class}} to add the new {{BETWEEN}} operator
> * Unit tests in {{SelectSingleColumnRelationTest}} and
> {{SelectMultiColumnRelationTest}} classes for the different types of columns
> (partition key, clustering, static and regular).
> * CQLSH auto completion in {{cql3handling.py}} and test for it in
> {{test_cqlsh_completion.py}}
> * Update the documentation
> Of course this is just an overview and some other parts might have to be
> changed as well.
--
This message was sent by Atlassian Jira
(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-19321) Accord: Command to mark replicas as “stale" for decommission
[
https://issues.apache.org/jira/browse/CASSANDRA-19321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17860873#comment-17860873
]
Caleb Rackliffe edited comment on CASSANDRA-19321 at 6/28/24 5:14 PM:
--
bq. the node will be offline for some time
Fair. From a UX perspective, I guess there are a couple options:
{{nodetool accord mark_stale }}, {{nodetool accord mark_active }}
This might be the simplest, but if there are other states, that might get
unwieldy.
{{nodetool accord set_durability_status [stale|active]}}
One command, specific, would accommodate other statuses...this might be my
pick. WDYT?
CC [~aweisberg] [~dcapwell]
was (Author: maedhroz):
bq. the node will be offline for some time
Fair. From a UX perspective, I guess there are a couple options:
{{nodetool accord mark_stale }}, {{nodetool accord mark_active }}
This might be the simplest, but if there are other states, that might get
unwieldy.
{{nodetool accord set_durability_status [stale|active]}}
One command, would accommodate other statuses...this might be my pick. WDYT?
CC [~aweisberg] [~dcapwell]
> Accord: Command to mark replicas as “stale" for decommission
>
>
> Key: CASSANDRA-19321
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19321
> Project: Cassandra
> Issue Type: Improvement
> Components: Accord
>Reporter: Benedict Elliott Smith
>Assignee: Caleb Rackliffe
>Priority: Normal
>
> So that other replicas may continue to cleanup their state, we must have an
> operator command for marking replicas as stale so that the remaining replicas
> do not wait for them to coordinate their durability status.
--
This message was sent by Atlassian Jira
(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-19321) Accord: Command to mark replicas as “stale" for decommission
[
https://issues.apache.org/jira/browse/CASSANDRA-19321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17860873#comment-17860873
]
Caleb Rackliffe commented on CASSANDRA-19321:
-
bq. the node will be offline for some time
Fair. From a UX perspective, I guess there are a couple options:
{{nodetool accord mark_stale }}, {{nodetool accord mark_active }}
This might be the simplest, but if there are other states, that might get
unwieldy.
{{nodetool accord set_durability_status [stale|active]}}
One command, would accommodate other statuses...this might be my pick. WDYT?
CC [~aweisberg] [~dcapwell]
> Accord: Command to mark replicas as “stale" for decommission
>
>
> Key: CASSANDRA-19321
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19321
> Project: Cassandra
> Issue Type: Improvement
> Components: Accord
>Reporter: Benedict Elliott Smith
>Assignee: Caleb Rackliffe
>Priority: Normal
>
> So that other replicas may continue to cleanup their state, we must have an
> operator command for marking replicas as stale so that the remaining replicas
> do not wait for them to coordinate their durability status.
--
This message was sent by Atlassian Jira
(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-19321) Accord: Command to mark replicas as “stale" for decommission
[
https://issues.apache.org/jira/browse/CASSANDRA-19321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17860654#comment-17860654
]
Caleb Rackliffe commented on CASSANDRA-19321:
-
Implementation Notes (draft)
- {{ClusterMetadata}} contains a set of CMS node IDs for replicas that should
be considered stale
-- This could initially sit alongside {{AccordFastPath}}
- nodetool command group for Accord, similar to {{CMSAdmin}}
-- {{nodetool accord mark_stale }} feeds hostname to the server, where
it's mapped to a CMS node ID
-- {{ClusterMetadata}} is updated, i.e. a transformation committed that
resembles {{ReconfigureAccordFastPath}}, but adds replica to the stale set and
produces the new metadata.
-
{{CoordinateDurabilityScheduling#coordinateShardDurableAfterExclusiveSyncPoint()}},
via {{CoordinateShardDurable#coordinate()}}, uses updated {{Topology}} to
exclude stale replicas from the set we need to wait for.
-- {{AccordTopology}} and related classes may need additional logic to
synthesize Accord {{Topology}} instances from {{ClusterMetadata}}.
> Accord: Command to mark replicas as “stale" for decommission
>
>
> Key: CASSANDRA-19321
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19321
> Project: Cassandra
> Issue Type: Improvement
> Components: Accord
>Reporter: Benedict Elliott Smith
>Assignee: Caleb Rackliffe
>Priority: Normal
>
> So that other replicas may continue to cleanup their state, we must have an
> operator command for marking replicas as stale so that the remaining replicas
> do not wait for them to coordinate their durability status.
--
This message was sent by Atlassian Jira
(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-18107) CEP-15: Multi-Partition Transaction CQL Support (Alpha -> v1)
[
https://issues.apache.org/jira/browse/CASSANDRA-18107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17860261#comment-17860261
]
Caleb Rackliffe commented on CASSANDRA-18107:
-
[~ifesdjeen] I might be able to roll selecting entire partitions into this
issue. (I've made a note above under "Features" for now.)
> CEP-15: Multi-Partition Transaction CQL Support (Alpha -> v1)
> -
>
> Key: CASSANDRA-18107
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18107
> Project: Cassandra
> Issue Type: New Feature
> Components: Accord, CQL/Semantics, CQL/Syntax
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 5.x
>
>
> With CASSANDRA-17719 complete, basic/alpha CQL support for Accord is now
> available in the
> [cep-15-accord|https://github.com/apache/cassandra/commits/cep-15-accord]
> branch. There are, however, a number of features and enhancements that we
> would still like to add before we make it available to users. Here is a
> summary of those items, broadly categorized:
> h3. *High Priority*
> *Error Messages and UX*
> - Fix the element/field names in result metadata to match the user query
> - Better error messages
> -- Append/subtracting to/from frozen list
> -- attempts to use reference in WHERE clause
> -- LET using a reserved word
> *Testing*
> - Figure out the original intent of placeholder tests in
> {{AccordIntegrationTest}} (ex. {{{}acceptInvalidationTest(){}}})
> *Features*
> - Support for returning the result of an {{{}IF{}}}/condition
> - Constant terms on the RHS of LET
> - Support for having a reference on both LHS and RHS of {{IF}} predicates
> - Support for {{{}CONTAINS{}}}, {{{}CONTAINS KEY{}}}, and {{IN}} (important
> for CAS parity)
> - Mixed conditional and unconditional updates
> - Arithmetic operations on references in {{{}INSERT{}}}/{{{}UPDATE{}}} (ex.
> INSERT INTO ks.tbl1 (k, c, v) VALUES (0, 0, a.v + 1)
> - Support TTLs specified in txn updates.
> - Allow partition reads in SELECT (i.e. only limit to one row on the
> right-hand side of LET statements)
> *Tooling*
> - Remove {{reateepochunsafe}} references in {{JMXGetterCheckTest}}
> *Documentation*
> - JavaDoc for all new statement classes
> h3. *Nice to Have*
> *Domain Object Cleanup*
> - Given {{Selector}} is serializable, attempt to reuse it in
> {{TxnReference}} rather than hard coding data conversion cases
> - Separate current current {{LET}} statement from {{{}SelectStatement{}}},
> likely as a new {{LetStatement}} that names a {{SelectStatement}}
> - Explore unifying {{Operation}} and {{ReferenceOperation}}
> - Include non-Row items of {{FilteredPartition}} in
> {{TxnData#estimatedSizeOnHeap()}}
> - Explore possibility of making {{Bound}} serializable and using it directly
> in {{TxnCondition}}
> - Change internal representation of {{TxnDataName}} to avoid {{String}} ->
> {{ByteBuffer}} conversions
> - Have {{{}TxnCondition{}}}/{{{}TxnUpdate{}}} support {{slice()}} to full
> take advantage of partial state replication
> - Update serialization logic to reflect CASSANDRA-18099
> *Features*
> - Full JSON support
> - Nested UDT support
> *Documentation*
> - CQL language documentation and bump the CQL language specification version
> - JavaDoc for all new statement classes
> - Integrate {{demo.txt}} into broader documentation somewhere or remove
--
This message was sent by Atlassian Jira
(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-18107) CEP-15: Multi-Partition Transaction CQL Support (Alpha -> v1)
[
https://issues.apache.org/jira/browse/CASSANDRA-18107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-18107:
Description:
With CASSANDRA-17719 complete, basic/alpha CQL support for Accord is now
available in the
[cep-15-accord|https://github.com/apache/cassandra/commits/cep-15-accord]
branch. There are, however, a number of features and enhancements that we would
still like to add before we make it available to users. Here is a summary of
those items, broadly categorized:
h3. *High Priority*
*Error Messages and UX*
- Fix the element/field names in result metadata to match the user query
- Better error messages
-- Append/subtracting to/from frozen list
-- attempts to use reference in WHERE clause
-- LET using a reserved word
*Testing*
- Figure out the original intent of placeholder tests in
{{AccordIntegrationTest}} (ex. {{{}acceptInvalidationTest(){}}})
*Features*
- Support for returning the result of an {{{}IF{}}}/condition
- Constant terms on the RHS of LET
- Support for having a reference on both LHS and RHS of {{IF}} predicates
- Support for {{{}CONTAINS{}}}, {{{}CONTAINS KEY{}}}, and {{IN}} (important
for CAS parity)
- Mixed conditional and unconditional updates
- Arithmetic operations on references in {{{}INSERT{}}}/{{{}UPDATE{}}} (ex.
INSERT INTO ks.tbl1 (k, c, v) VALUES (0, 0, a.v + 1)
- Support TTLs specified in txn updates.
- Allow partition reads in SELECT (i.e. only limit to one row on the
right-hand side of LET statements)
*Tooling*
- Remove {{reateepochunsafe}} references in {{JMXGetterCheckTest}}
*Documentation*
- JavaDoc for all new statement classes
h3. *Nice to Have*
*Domain Object Cleanup*
- Given {{Selector}} is serializable, attempt to reuse it in {{TxnReference}}
rather than hard coding data conversion cases
- Separate current current {{LET}} statement from {{{}SelectStatement{}}},
likely as a new {{LetStatement}} that names a {{SelectStatement}}
- Explore unifying {{Operation}} and {{ReferenceOperation}}
- Include non-Row items of {{FilteredPartition}} in
{{TxnData#estimatedSizeOnHeap()}}
- Explore possibility of making {{Bound}} serializable and using it directly
in {{TxnCondition}}
- Change internal representation of {{TxnDataName}} to avoid {{String}} ->
{{ByteBuffer}} conversions
- Have {{{}TxnCondition{}}}/{{{}TxnUpdate{}}} support {{slice()}} to full take
advantage of partial state replication
- Update serialization logic to reflect CASSANDRA-18099
*Features*
- Full JSON support
- Nested UDT support
*Documentation*
- CQL language documentation and bump the CQL language specification version
- JavaDoc for all new statement classes
- Integrate {{demo.txt}} into broader documentation somewhere or remove
was:
With CASSANDRA-17719 complete, basic/alpha CQL support for Accord is now
available in the
[cep-15-accord|https://github.com/apache/cassandra/commits/cep-15-accord]
branch. There are, however, a number of features and enhancements that we would
still like to add before we make it available to users. Here is a summary of
those items, broadly categorized:
h3. *High Priority*
*Error Messages and UX*
- Fix the element/field names in result metadata to match the user query
- Better error messages
-- Append/subtracting to/from frozen list
-- attempts to use reference in WHERE clause
-- LET using a reserved word
*Testing*
- Figure out the original intent of placeholder tests in
{{AccordIntegrationTest}} (ex. {{{}acceptInvalidationTest(){}}})
*Features*
- Support for returning the result of an {{{}IF{}}}/condition
- Constant terms on the RHS of LET
- Support for having a reference on both LHS and RHS of {{IF}} predicates
- Support for {{{}CONTAINS{}}}, {{{}CONTAINS KEY{}}}, and {{IN}} (important
for CAS parity)
- Mixed conditional and unconditional updates
- Arithmetic operations on references in {{{}INSERT{}}}/{{{}UPDATE{}}} (ex.
INSERT INTO ks.tbl1 (k, c, v) VALUES (0, 0, a.v + 1)
- Support TTLs specified in txn updates.
*Tooling*
- Remove {{reateepochunsafe}} references in {{JMXGetterCheckTest}}
*Documentation*
- JavaDoc for all new statement classes
h3. *Nice to Have*
*Domain Object Cleanup*
- Given {{Selector}} is serializable, attempt to reuse it in {{TxnReference}}
rather than hard coding data conversion cases
- Separate current current {{LET}} statement from {{{}SelectStatement{}}},
likely as a new {{LetStatement}} that names a {{SelectStatement}}
- Explore unifying {{Operation}} and {{ReferenceOperation}}
- Include non-Row items of {{FilteredPartition}} in
{{TxnData#estimatedSizeOnHeap()}}
- Explore possibility of making {{Bound}} serializable and using it directly
in {{TxnCondition}}
- Change internal representation of {{TxnDataName}} to avoid {{String}} ->
{{ByteBuffer}} conversions
- Have {{{}TxnCondition{}}}/{{{}TxnUpdate{}}} support {{slice()}} to full take
[jira] [Commented] (CASSANDRA-19704) UnsupportedOperationException is thrown when no space for LCS
[
https://issues.apache.org/jira/browse/CASSANDRA-19704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17860220#comment-17860220
]
Caleb Rackliffe commented on CASSANDRA-19704:
-
I'm not seeing anything in CI that's being caused by this patch, so I'll likely
move to commit as soon as Marcus has a chance to take a quick look.
> UnsupportedOperationException is thrown when no space for LCS
> -
>
> Key: CASSANDRA-19704
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19704
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Compaction/LCS
>Reporter: Zhao Yang
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x
>
> Attachments: ci_summary-1.html, ci_summary-2.html, ci_summary-3.html,
> ci_summary.html
>
>
> In {{CompactionTask#buildCompactionCandidatesForAvailableDiskSpace}} with
> LCS, if node has limited disk space and can't remove any sstable from L0 or
> L1 in {{{}LeveledCompactionTask#reduceScopeForLimitedSpace{}}},
> {{LeveledCompactionTask#partialCompactionsAcceptable}} will throw
> {{UnsupportedOperationException}}.
> We should handle {{LeveledCompactionTask#partialCompactionsAcceptable}} more
> gracefully with {{return level <= 1}} or simply {{true}} since
> {{reduceScopeForLimitedSpace}} only removes sstable from L0 or L1.
> Related https://issues.apache.org/jira/browse/CASSANDRA-17272
--
This message was sent by Atlassian Jira
(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-19704) UnsupportedOperationException is thrown when no space for LCS
[
https://issues.apache.org/jira/browse/CASSANDRA-19704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-19704:
Attachment: ci_summary-3.html
> UnsupportedOperationException is thrown when no space for LCS
> -
>
> Key: CASSANDRA-19704
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19704
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Compaction/LCS
>Reporter: Zhao Yang
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x
>
> Attachments: ci_summary-1.html, ci_summary-2.html, ci_summary-3.html,
> ci_summary.html
>
>
> In {{CompactionTask#buildCompactionCandidatesForAvailableDiskSpace}} with
> LCS, if node has limited disk space and can't remove any sstable from L0 or
> L1 in {{{}LeveledCompactionTask#reduceScopeForLimitedSpace{}}},
> {{LeveledCompactionTask#partialCompactionsAcceptable}} will throw
> {{UnsupportedOperationException}}.
> We should handle {{LeveledCompactionTask#partialCompactionsAcceptable}} more
> gracefully with {{return level <= 1}} or simply {{true}} since
> {{reduceScopeForLimitedSpace}} only removes sstable from L0 or L1.
> Related https://issues.apache.org/jira/browse/CASSANDRA-17272
--
This message was sent by Atlassian Jira
(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-19704) UnsupportedOperationException is thrown when no space for LCS
[
https://issues.apache.org/jira/browse/CASSANDRA-19704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17860003#comment-17860003
]
Caleb Rackliffe edited comment on CASSANDRA-19704 at 6/26/24 6:43 PM:
--
4.0 patch: [https://github.com/apache/cassandra/pull/3385] CI:
[^ci_summary.html]
4.1 patch: [https://github.com/apache/cassandra/pull/3386] CI:
[^ci_summary-1.html]
5.0 patch: [https://github.com/apache/cassandra/pull/3387] CI:
[^ci_summary-2.html]
trunk: [https://github.com/apache/cassandra/pull/3388] CI: [^ci_summary-3.html]
was (Author: maedhroz):
4.0 patch: [https://github.com/apache/cassandra/pull/3385] CI:
[^ci_summary.html]
4.1 patch: [https://github.com/apache/cassandra/pull/3386] CI:
[^ci_summary-1.html]
5.0 patch: [https://github.com/apache/cassandra/pull/3387] CI:
[^ci_summary-2.html]
trunk: [https://github.com/apache/cassandra/pull/3388] CI: TODO
> UnsupportedOperationException is thrown when no space for LCS
> -
>
> Key: CASSANDRA-19704
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19704
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Compaction/LCS
>Reporter: Zhao Yang
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x
>
> Attachments: ci_summary-1.html, ci_summary-2.html, ci_summary-3.html,
> ci_summary.html
>
>
> In {{CompactionTask#buildCompactionCandidatesForAvailableDiskSpace}} with
> LCS, if node has limited disk space and can't remove any sstable from L0 or
> L1 in {{{}LeveledCompactionTask#reduceScopeForLimitedSpace{}}},
> {{LeveledCompactionTask#partialCompactionsAcceptable}} will throw
> {{UnsupportedOperationException}}.
> We should handle {{LeveledCompactionTask#partialCompactionsAcceptable}} more
> gracefully with {{return level <= 1}} or simply {{true}} since
> {{reduceScopeForLimitedSpace}} only removes sstable from L0 or L1.
> Related https://issues.apache.org/jira/browse/CASSANDRA-17272
--
This message was sent by Atlassian Jira
(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-19704) UnsupportedOperationException is thrown when no space for LCS
[
https://issues.apache.org/jira/browse/CASSANDRA-19704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17860003#comment-17860003
]
Caleb Rackliffe edited comment on CASSANDRA-19704 at 6/26/24 3:56 PM:
--
4.0 patch: [https://github.com/apache/cassandra/pull/3385] CI:
[^ci_summary.html]
4.1 patch: [https://github.com/apache/cassandra/pull/3386] CI:
[^ci_summary-1.html]
5.0 patch: [https://github.com/apache/cassandra/pull/3387] CI:
[^ci_summary-2.html]
trunk: [https://github.com/apache/cassandra/pull/3388] CI: TODO
was (Author: maedhroz):
4.0 patch: [https://github.com/apache/cassandra/pull/3385] CI:
[^ci_summary.html]
4.1 patch: [https://github.com/apache/cassandra/pull/3386] CI:
[^ci_summary-1.html]
5.0 patch: [https://github.com/apache/cassandra/pull/3387] CI:
[^ci_summary-2.html]
> UnsupportedOperationException is thrown when no space for LCS
> -
>
> Key: CASSANDRA-19704
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19704
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Compaction/LCS
>Reporter: Zhao Yang
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x
>
> Attachments: ci_summary-1.html, ci_summary-2.html, ci_summary.html
>
>
> In {{CompactionTask#buildCompactionCandidatesForAvailableDiskSpace}} with
> LCS, if node has limited disk space and can't remove any sstable from L0 or
> L1 in {{{}LeveledCompactionTask#reduceScopeForLimitedSpace{}}},
> {{LeveledCompactionTask#partialCompactionsAcceptable}} will throw
> {{UnsupportedOperationException}}.
> We should handle {{LeveledCompactionTask#partialCompactionsAcceptable}} more
> gracefully with {{return level <= 1}} or simply {{true}} since
> {{reduceScopeForLimitedSpace}} only removes sstable from L0 or L1.
> Related https://issues.apache.org/jira/browse/CASSANDRA-17272
--
This message was sent by Atlassian Jira
(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-19704) UnsupportedOperationException is thrown when no space for LCS
[
https://issues.apache.org/jira/browse/CASSANDRA-19704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17860003#comment-17860003
]
Caleb Rackliffe edited comment on CASSANDRA-19704 at 6/26/24 2:54 PM:
--
4.0 patch: [https://github.com/apache/cassandra/pull/3385] CI:
[^ci_summary.html]
4.1 patch: [https://github.com/apache/cassandra/pull/3386] CI:
[^ci_summary-1.html]
5.0 patch: [https://github.com/apache/cassandra/pull/3387] CI:
[^ci_summary-2.html]
was (Author: maedhroz):
4.0 patch: [https://github.com/apache/cassandra/pull/3385] CI:
[^ci_summary.html]
4.1 patch: [https://github.com/apache/cassandra/pull/3386] CI:
[^ci_summary-1.html]
5.0 patch: [https://github.com/apache/cassandra/pull/3387] CI: TODO
> UnsupportedOperationException is thrown when no space for LCS
> -
>
> Key: CASSANDRA-19704
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19704
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Compaction/LCS
>Reporter: Zhao Yang
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x
>
> Attachments: ci_summary-1.html, ci_summary-2.html, ci_summary.html
>
>
> In {{CompactionTask#buildCompactionCandidatesForAvailableDiskSpace}} with
> LCS, if node has limited disk space and can't remove any sstable from L0 or
> L1 in {{{}LeveledCompactionTask#reduceScopeForLimitedSpace{}}},
> {{LeveledCompactionTask#partialCompactionsAcceptable}} will throw
> {{UnsupportedOperationException}}.
> We should handle {{LeveledCompactionTask#partialCompactionsAcceptable}} more
> gracefully with {{return level <= 1}} or simply {{true}} since
> {{reduceScopeForLimitedSpace}} only removes sstable from L0 or L1.
> Related https://issues.apache.org/jira/browse/CASSANDRA-17272
--
This message was sent by Atlassian Jira
(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-19704) UnsupportedOperationException is thrown when no space for LCS
[
https://issues.apache.org/jira/browse/CASSANDRA-19704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-19704:
Attachment: ci_summary-2.html
> UnsupportedOperationException is thrown when no space for LCS
> -
>
> Key: CASSANDRA-19704
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19704
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Compaction/LCS
>Reporter: Zhao Yang
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x
>
> Attachments: ci_summary-1.html, ci_summary-2.html, ci_summary.html
>
>
> In {{CompactionTask#buildCompactionCandidatesForAvailableDiskSpace}} with
> LCS, if node has limited disk space and can't remove any sstable from L0 or
> L1 in {{{}LeveledCompactionTask#reduceScopeForLimitedSpace{}}},
> {{LeveledCompactionTask#partialCompactionsAcceptable}} will throw
> {{UnsupportedOperationException}}.
> We should handle {{LeveledCompactionTask#partialCompactionsAcceptable}} more
> gracefully with {{return level <= 1}} or simply {{true}} since
> {{reduceScopeForLimitedSpace}} only removes sstable from L0 or L1.
> Related https://issues.apache.org/jira/browse/CASSANDRA-17272
--
This message was sent by Atlassian Jira
(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-19704) UnsupportedOperationException is thrown when no space for LCS
[
https://issues.apache.org/jira/browse/CASSANDRA-19704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-19704:
Description:
In {{CompactionTask#buildCompactionCandidatesForAvailableDiskSpace}} with LCS,
if node has limited disk space and can't remove any sstable from L0 or L1 in
{{{}LeveledCompactionTask#reduceScopeForLimitedSpace{}}},
{{LeveledCompactionTask#partialCompactionsAcceptable}} will throw
{{UnsupportedOperationException}}.
We should handle {{LeveledCompactionTask#partialCompactionsAcceptable}} more
gracefully with {{return level <= 1}} or simply {{true}} since
{{reduceScopeForLimitedSpace}} only removes sstable from L0 or L1.
Related https://issues.apache.org/jira/browse/CASSANDRA-17272
was:
In `CompactionTask#buildCompactionCandidatesForAvailableDiskSpace` with LCS, if
node has limited disk space and can't remove any sstable from L0 or L1 in
`LeveledCompactionTask#reduceScopeForLimitedSpace`,
`LeveledCompactionTask#partialCompactionsAcceptable` will throw
`UnsupportedOperationException`.
We should handle `LeveledCompactionTask#partialCompactionsAcceptable` more
gracefully with `return level <= 1` or simply `true` since
`reduceScopeForLimitedSpace` only removes sstable from L0 or L1.
Related https://issues.apache.org/jira/browse/CASSANDRA-17272
> UnsupportedOperationException is thrown when no space for LCS
> -
>
> Key: CASSANDRA-19704
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19704
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Compaction/LCS
>Reporter: Zhao Yang
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x
>
> Attachments: ci_summary-1.html, ci_summary.html
>
>
> In {{CompactionTask#buildCompactionCandidatesForAvailableDiskSpace}} with
> LCS, if node has limited disk space and can't remove any sstable from L0 or
> L1 in {{{}LeveledCompactionTask#reduceScopeForLimitedSpace{}}},
> {{LeveledCompactionTask#partialCompactionsAcceptable}} will throw
> {{UnsupportedOperationException}}.
> We should handle {{LeveledCompactionTask#partialCompactionsAcceptable}} more
> gracefully with {{return level <= 1}} or simply {{true}} since
> {{reduceScopeForLimitedSpace}} only removes sstable from L0 or L1.
> Related https://issues.apache.org/jira/browse/CASSANDRA-17272
--
This message was sent by Atlassian Jira
(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-19704) UnsupportedOperationException is thrown when no space for LCS
[ https://issues.apache.org/jira/browse/CASSANDRA-19704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17860040#comment-17860040 ] Caleb Rackliffe commented on CASSANDRA-19704: - [~brandon.williams] [~jasonstack] [~marcuse] Anyone up to review? > UnsupportedOperationException is thrown when no space for LCS > - > > Key: CASSANDRA-19704 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19704 > Project: Cassandra > Issue Type: Bug > Components: Local/Compaction/LCS >Reporter: Zhao Yang >Assignee: Caleb Rackliffe >Priority: Normal > Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x > > Attachments: ci_summary-1.html, ci_summary.html > > > In `CompactionTask#buildCompactionCandidatesForAvailableDiskSpace` with LCS, > if node has limited disk space and can't remove any sstable from L0 or L1 in > `LeveledCompactionTask#reduceScopeForLimitedSpace`, > `LeveledCompactionTask#partialCompactionsAcceptable` will throw > `UnsupportedOperationException`. > We should handle `LeveledCompactionTask#partialCompactionsAcceptable` more > gracefully with `return level <= 1` or simply `true` since > `reduceScopeForLimitedSpace` only removes sstable from L0 or L1. > Related https://issues.apache.org/jira/browse/CASSANDRA-17272 -- This message was sent by Atlassian Jira (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-19726) User documentation for Accord CQL transaction syntax
Caleb Rackliffe created CASSANDRA-19726: --- Summary: User documentation for Accord CQL transaction syntax Key: CASSANDRA-19726 URL: https://issues.apache.org/jira/browse/CASSANDRA-19726 Project: Cassandra Issue Type: Task Reporter: Caleb Rackliffe With a brand new CQL transaction syntax, we'll need new user-facing documentation, covering what's possible, what's not (yet) possible, and what the best ways are to express common patterns. -- This message was sent by Atlassian Jira (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-19725) Integrate tracing with Accord transaction execution
Caleb Rackliffe created CASSANDRA-19725: --- Summary: Integrate tracing with Accord transaction execution Key: CASSANDRA-19725 URL: https://issues.apache.org/jira/browse/CASSANDRA-19725 Project: Cassandra Issue Type: Improvement Components: Accord, Observability/Tracing Reporter: Caleb Rackliffe Assignee: Caleb Rackliffe Accord transactions contain potentially multiple read and write operations, as well as the evaluation of conditions. As of right now, they are not integrated holistically into the CQL query tracing mechanism, at least not completely. There are two things (or categories of events) we might want here. The first is logging events during transaction execution that would be new and specific to Accord. The second is making sure that existing tracing information around local reads and writes are persisted as expected to tracing sessions. -- This message was sent by Atlassian Jira (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-19704) UnsupportedOperationException is thrown when no space for LCS
[ https://issues.apache.org/jira/browse/CASSANDRA-19704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17860003#comment-17860003 ] Caleb Rackliffe edited comment on CASSANDRA-19704 at 6/25/24 9:38 PM: -- 4.0 patch: [https://github.com/apache/cassandra/pull/3385] CI: [^ci_summary.html] 4.1 patch: [https://github.com/apache/cassandra/pull/3386] CI: [^ci_summary-1.html] 5.0 patch: [https://github.com/apache/cassandra/pull/3387] CI: TODO was (Author: maedhroz): 4.0 patch: [https://github.com/apache/cassandra/pull/3385] CI: [^ci_summary.html] 4.1 patch: [https://github.com/apache/cassandra/pull/3386] CI: [^ci_summary-1.html] > UnsupportedOperationException is thrown when no space for LCS > - > > Key: CASSANDRA-19704 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19704 > Project: Cassandra > Issue Type: Bug > Components: Local/Compaction/LCS >Reporter: Zhao Yang >Assignee: Caleb Rackliffe >Priority: Normal > Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x > > Attachments: ci_summary-1.html, ci_summary.html > > > In `CompactionTask#buildCompactionCandidatesForAvailableDiskSpace` with LCS, > if node has limited disk space and can't remove any sstable from L0 or L1 in > `LeveledCompactionTask#reduceScopeForLimitedSpace`, > `LeveledCompactionTask#partialCompactionsAcceptable` will throw > `UnsupportedOperationException`. > We should handle `LeveledCompactionTask#partialCompactionsAcceptable` more > gracefully with `return level <= 1` or simply `true` since > `reduceScopeForLimitedSpace` only removes sstable from L0 or L1. > Related https://issues.apache.org/jira/browse/CASSANDRA-17272 -- This message was sent by Atlassian Jira (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-19724) Disable guardrails that may affect Accord transaction outcome
[ https://issues.apache.org/jira/browse/CASSANDRA-19724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Rackliffe updated CASSANDRA-19724: Bug Category: Parent values: Availability(12983) Complexity: Normal Discovered By: Code Inspection Fix Version/s: 5.x Severity: Normal Assignee: Caleb Rackliffe Status: Open (was: Triage Needed) > Disable guardrails that may affect Accord transaction outcome > - > > Key: CASSANDRA-19724 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19724 > Project: Cassandra > Issue Type: Bug > Components: Accord >Reporter: Caleb Rackliffe >Assignee: Caleb Rackliffe >Priority: Normal > Fix For: 5.x > > > The Guardrails subsystem is comprised of items configured on a per-node > basis. We need to do an inventory of these items and consider disabling the > ones that could affect transaction outcome before execution begins. -- This message was sent by Atlassian Jira (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-19704) UnsupportedOperationException is thrown when no space for LCS
[ https://issues.apache.org/jira/browse/CASSANDRA-19704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17860003#comment-17860003 ] Caleb Rackliffe edited comment on CASSANDRA-19704 at 6/25/24 9:17 PM: -- 4.0 patch: [https://github.com/apache/cassandra/pull/3385] CI: [^ci_summary.html] 4.1 patch: [https://github.com/apache/cassandra/pull/3386] CI: [^ci_summary-1.html] was (Author: maedhroz): 4.0 patch: [https://github.com/apache/cassandra/pull/3385] CI: [^ci_summary.html] 4.1 patch: [https://github.com/apache/cassandra/pull/3386] CI: TODO > UnsupportedOperationException is thrown when no space for LCS > - > > Key: CASSANDRA-19704 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19704 > Project: Cassandra > Issue Type: Bug > Components: Local/Compaction/LCS >Reporter: Zhao Yang >Assignee: Caleb Rackliffe >Priority: Normal > Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x > > Attachments: ci_summary-1.html, ci_summary.html > > > In `CompactionTask#buildCompactionCandidatesForAvailableDiskSpace` with LCS, > if node has limited disk space and can't remove any sstable from L0 or L1 in > `LeveledCompactionTask#reduceScopeForLimitedSpace`, > `LeveledCompactionTask#partialCompactionsAcceptable` will throw > `UnsupportedOperationException`. > We should handle `LeveledCompactionTask#partialCompactionsAcceptable` more > gracefully with `return level <= 1` or simply `true` since > `reduceScopeForLimitedSpace` only removes sstable from L0 or L1. > Related https://issues.apache.org/jira/browse/CASSANDRA-17272 -- This message was sent by Atlassian Jira (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-19704) UnsupportedOperationException is thrown when no space for LCS
[ https://issues.apache.org/jira/browse/CASSANDRA-19704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Rackliffe updated CASSANDRA-19704: Attachment: ci_summary-1.html > UnsupportedOperationException is thrown when no space for LCS > - > > Key: CASSANDRA-19704 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19704 > Project: Cassandra > Issue Type: Bug > Components: Local/Compaction/LCS >Reporter: Zhao Yang >Assignee: Caleb Rackliffe >Priority: Normal > Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x > > Attachments: ci_summary-1.html, ci_summary.html > > > In `CompactionTask#buildCompactionCandidatesForAvailableDiskSpace` with LCS, > if node has limited disk space and can't remove any sstable from L0 or L1 in > `LeveledCompactionTask#reduceScopeForLimitedSpace`, > `LeveledCompactionTask#partialCompactionsAcceptable` will throw > `UnsupportedOperationException`. > We should handle `LeveledCompactionTask#partialCompactionsAcceptable` more > gracefully with `return level <= 1` or simply `true` since > `reduceScopeForLimitedSpace` only removes sstable from L0 or L1. > Related https://issues.apache.org/jira/browse/CASSANDRA-17272 -- This message was sent by Atlassian Jira (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-19724) Disable guardrails that may affect Accord transaction outcome
Caleb Rackliffe created CASSANDRA-19724: --- Summary: Disable guardrails that may affect Accord transaction outcome Key: CASSANDRA-19724 URL: https://issues.apache.org/jira/browse/CASSANDRA-19724 Project: Cassandra Issue Type: Bug Components: Accord Reporter: Caleb Rackliffe The Guardrails subsystem is comprised of items configured on a per-node basis. We need to do an inventory of these items and consider disabling the ones that could affect transaction outcome before execution begins. -- This message was sent by Atlassian Jira (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-19704) UnsupportedOperationException is thrown when no space for LCS
[ https://issues.apache.org/jira/browse/CASSANDRA-19704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17860003#comment-17860003 ] Caleb Rackliffe edited comment on CASSANDRA-19704 at 6/25/24 7:33 PM: -- 4.0 patch: [https://github.com/apache/cassandra/pull/3385] CI: [^ci_summary.html] 4.1 patch: [https://github.com/apache/cassandra/pull/3386] CI: TODO was (Author: maedhroz): 4.0 patch: [https://github.com/apache/cassandra/pull/3385] CI: [^ci_summary.html] > UnsupportedOperationException is thrown when no space for LCS > - > > Key: CASSANDRA-19704 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19704 > Project: Cassandra > Issue Type: Bug > Components: Local/Compaction/LCS >Reporter: Zhao Yang >Assignee: Caleb Rackliffe >Priority: Normal > Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x > > Attachments: ci_summary.html > > > In `CompactionTask#buildCompactionCandidatesForAvailableDiskSpace` with LCS, > if node has limited disk space and can't remove any sstable from L0 or L1 in > `LeveledCompactionTask#reduceScopeForLimitedSpace`, > `LeveledCompactionTask#partialCompactionsAcceptable` will throw > `UnsupportedOperationException`. > We should handle `LeveledCompactionTask#partialCompactionsAcceptable` more > gracefully with `return level <= 1` or simply `true` since > `reduceScopeForLimitedSpace` only removes sstable from L0 or L1. > Related https://issues.apache.org/jira/browse/CASSANDRA-17272 -- This message was sent by Atlassian Jira (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-19704) UnsupportedOperationException is thrown when no space for LCS
[ https://issues.apache.org/jira/browse/CASSANDRA-19704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17860003#comment-17860003 ] Caleb Rackliffe edited comment on CASSANDRA-19704 at 6/25/24 7:30 PM: -- 4.0 patch: [https://github.com/apache/cassandra/pull/3385] CI: [^ci_summary.html] was (Author: maedhroz): 4.0 patch: [https://github.com/apache/cassandra/pull/3385] > UnsupportedOperationException is thrown when no space for LCS > - > > Key: CASSANDRA-19704 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19704 > Project: Cassandra > Issue Type: Bug > Components: Local/Compaction/LCS >Reporter: Zhao Yang >Assignee: Caleb Rackliffe >Priority: Normal > Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x > > Attachments: ci_summary.html > > > In `CompactionTask#buildCompactionCandidatesForAvailableDiskSpace` with LCS, > if node has limited disk space and can't remove any sstable from L0 or L1 in > `LeveledCompactionTask#reduceScopeForLimitedSpace`, > `LeveledCompactionTask#partialCompactionsAcceptable` will throw > `UnsupportedOperationException`. > We should handle `LeveledCompactionTask#partialCompactionsAcceptable` more > gracefully with `return level <= 1` or simply `true` since > `reduceScopeForLimitedSpace` only removes sstable from L0 or L1. > Related https://issues.apache.org/jira/browse/CASSANDRA-17272 -- This message was sent by Atlassian Jira (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-19704) UnsupportedOperationException is thrown when no space for LCS
[ https://issues.apache.org/jira/browse/CASSANDRA-19704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Rackliffe updated CASSANDRA-19704: Attachment: ci_summary.html > UnsupportedOperationException is thrown when no space for LCS > - > > Key: CASSANDRA-19704 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19704 > Project: Cassandra > Issue Type: Bug > Components: Local/Compaction/LCS >Reporter: Zhao Yang >Assignee: Caleb Rackliffe >Priority: Normal > Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x > > Attachments: ci_summary.html > > > In `CompactionTask#buildCompactionCandidatesForAvailableDiskSpace` with LCS, > if node has limited disk space and can't remove any sstable from L0 or L1 in > `LeveledCompactionTask#reduceScopeForLimitedSpace`, > `LeveledCompactionTask#partialCompactionsAcceptable` will throw > `UnsupportedOperationException`. > We should handle `LeveledCompactionTask#partialCompactionsAcceptable` more > gracefully with `return level <= 1` or simply `true` since > `reduceScopeForLimitedSpace` only removes sstable from L0 or L1. > Related https://issues.apache.org/jira/browse/CASSANDRA-17272 -- This message was sent by Atlassian Jira (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-19704) UnsupportedOperationException is thrown when no space for LCS
[
https://issues.apache.org/jira/browse/CASSANDRA-19704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17860010#comment-17860010
]
Caleb Rackliffe commented on CASSANDRA-19704:
-
Note: I wasn't able to reproduce this before 4.0, as
\{{buildCompactionCandidatesForAvailableDiskSpace()}} does not exist.
> UnsupportedOperationException is thrown when no space for LCS
> -
>
> Key: CASSANDRA-19704
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19704
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Compaction/LCS
>Reporter: Zhao Yang
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x
>
>
> In `CompactionTask#buildCompactionCandidatesForAvailableDiskSpace` with LCS,
> if node has limited disk space and can't remove any sstable from L0 or L1 in
> `LeveledCompactionTask#reduceScopeForLimitedSpace`,
> `LeveledCompactionTask#partialCompactionsAcceptable` will throw
> `UnsupportedOperationException`.
> We should handle `LeveledCompactionTask#partialCompactionsAcceptable` more
> gracefully with `return level <= 1` or simply `true` since
> `reduceScopeForLimitedSpace` only removes sstable from L0 or L1.
> Related https://issues.apache.org/jira/browse/CASSANDRA-17272
--
This message was sent by Atlassian Jira
(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-19704) UnsupportedOperationException is thrown when no space for LCS
[ https://issues.apache.org/jira/browse/CASSANDRA-19704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Rackliffe updated CASSANDRA-19704: Fix Version/s: (was: 3.0.x) (was: 3.11.x) > UnsupportedOperationException is thrown when no space for LCS > - > > Key: CASSANDRA-19704 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19704 > Project: Cassandra > Issue Type: Bug > Components: Local/Compaction/LCS >Reporter: Zhao Yang >Assignee: Caleb Rackliffe >Priority: Normal > Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x > > > In `CompactionTask#buildCompactionCandidatesForAvailableDiskSpace` with LCS, > if node has limited disk space and can't remove any sstable from L0 or L1 in > `LeveledCompactionTask#reduceScopeForLimitedSpace`, > `LeveledCompactionTask#partialCompactionsAcceptable` will throw > `UnsupportedOperationException`. > We should handle `LeveledCompactionTask#partialCompactionsAcceptable` more > gracefully with `return level <= 1` or simply `true` since > `reduceScopeForLimitedSpace` only removes sstable from L0 or L1. > Related https://issues.apache.org/jira/browse/CASSANDRA-17272 -- This message was sent by Atlassian Jira (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-19704) UnsupportedOperationException is thrown when no space for LCS
[ https://issues.apache.org/jira/browse/CASSANDRA-19704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Rackliffe updated CASSANDRA-19704: Test and Documentation Plan: new test that reproduces the UOE in the description Status: Patch Available (was: In Progress) 4.0 patch: [https://github.com/apache/cassandra/pull/3385] > UnsupportedOperationException is thrown when no space for LCS > - > > Key: CASSANDRA-19704 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19704 > Project: Cassandra > Issue Type: Bug > Components: Local/Compaction/LCS >Reporter: Zhao Yang >Assignee: Caleb Rackliffe >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.0.x, 5.x > > > In `CompactionTask#buildCompactionCandidatesForAvailableDiskSpace` with LCS, > if node has limited disk space and can't remove any sstable from L0 or L1 in > `LeveledCompactionTask#reduceScopeForLimitedSpace`, > `LeveledCompactionTask#partialCompactionsAcceptable` will throw > `UnsupportedOperationException`. > We should handle `LeveledCompactionTask#partialCompactionsAcceptable` more > gracefully with `return level <= 1` or simply `true` since > `reduceScopeForLimitedSpace` only removes sstable from L0 or L1. > Related https://issues.apache.org/jira/browse/CASSANDRA-17272 -- This message was sent by Atlassian Jira (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-18988) Updating the column of a non-existent row in an Accord transaction results in Atomicity violation
[
https://issues.apache.org/jira/browse/CASSANDRA-18988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-18988:
Resolution: Not A Problem
Status: Resolved (was: Open)
> Updating the column of a non-existent row in an Accord transaction results in
> Atomicity violation
> -
>
> Key: CASSANDRA-18988
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18988
> Project: Cassandra
> Issue Type: Bug
> Components: Accord
>Reporter: Luis E Fernandez
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 5.x
>
>
> *System configuration and information:*
> Single node Cassandra with Accord transactions enabled running on docker
> Built from commit:
> [a7cd114435704b988c81f47ef53d0bfd6441f38b|https://github.com/apache/cassandra/commit/a7cd114435704b988c81f47ef53d0bfd6441f38b]
> CQLSH: [cqlsh 6.2.0 | Cassandra 5.0-alpha2-SNAPSHOT | CQL spec 3.4.7 | Native
> protocol v5]
>
> *Steps to reproduce in CQLSH:*
> {code:java}
> CREATE KEYSPACE accord WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;{code}
> {code:java}
> CREATE TABLE accord.accounts (
> partition text,
> account_id int,
> balance int,
> PRIMARY KEY (partition, account_id)
> ) WITH CLUSTERING ORDER BY (account_id ASC);
> {code}
> {code:java}
> BEGIN TRANSACTION
> INSERT INTO accord.accounts (partition, account_id, balance) VALUES
> ('default', 0, 100);
> INSERT INTO accord.accounts (partition, account_id, balance) VALUES
> ('default', 1, 100);
> COMMIT TRANSACTION;{code}
> atomicity bug happens after executing the following statement:
> Based on [Cassandra
> documentation|https://cassandra.apache.org/doc/4.1/cassandra/cql/dml.html#update-statement]
> regarding the use of UPDATE statements, I expect the result of this
> transaction to be the insertion of a new account (\{ account_id: 3, balance:
> 10 }). The total balance across the three (3) accounts should be maintained
> (200). After executing the below transaction, the total number of accounts
> remains at two (2) and the total balance drops to 190. Basically, it appears
> as if only one half of the transaction proceeds.
> {code:java}
> BEGIN TRANSACTION
> UPDATE accord.accounts
> SET balance -= 10
> WHERE
> partition = 'default'
> AND account_id = 1;
> UPDATE accord.accounts
> SET balance += 10
> WHERE
> partition = 'default'
> AND account_id = 3;
> COMMIT TRANSACTION;{code}
> Bug / Error:
> ==
> The result of performing a table read after executing the buggy transaction
> is:
> {code:java}
> partition | account_id | balance
> ---++-
> default | 0 | 100
> default | 1 | 90
> {code}
> {color:#172b4d}Note that the above transactions are not possible without a
> transaction block because only counter type columns can be updated with += or
> -= syntax in normal (non-transactional) cql statements. Using counter type
> columns also results in a separate, related bug:
> [CASSANDRA-18987|https://issues.apache.org/jira/browse/CASSANDRA-18987]{color}
> {color:#172b4d}This was found while testing Accord transactions with
> [~henrik.ingo] and team.{color}
--
This message was sent by Atlassian Jira
(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-18988) Updating the column of a non-existent row in an Accord transaction results in Atomicity violation
[
https://issues.apache.org/jira/browse/CASSANDRA-18988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17859983#comment-17859983
]
Caleb Rackliffe commented on CASSANDRA-18988:
-
It looks like the discussion has settled on the dev list, and this behavior
will stay the same for the time being. However, there is still a question of
what we might return to the user generally when no explicit SELECT is defined
in the transaction and we have updates that may or not be applied. That and
mixed conditional/non-conditional updates can be handled as part of
CASSANDRA-18107.
> Updating the column of a non-existent row in an Accord transaction results in
> Atomicity violation
> -
>
> Key: CASSANDRA-18988
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18988
> Project: Cassandra
> Issue Type: Bug
> Components: Accord
>Reporter: Luis E Fernandez
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 5.x
>
>
> *System configuration and information:*
> Single node Cassandra with Accord transactions enabled running on docker
> Built from commit:
> [a7cd114435704b988c81f47ef53d0bfd6441f38b|https://github.com/apache/cassandra/commit/a7cd114435704b988c81f47ef53d0bfd6441f38b]
> CQLSH: [cqlsh 6.2.0 | Cassandra 5.0-alpha2-SNAPSHOT | CQL spec 3.4.7 | Native
> protocol v5]
>
> *Steps to reproduce in CQLSH:*
> {code:java}
> CREATE KEYSPACE accord WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;{code}
> {code:java}
> CREATE TABLE accord.accounts (
> partition text,
> account_id int,
> balance int,
> PRIMARY KEY (partition, account_id)
> ) WITH CLUSTERING ORDER BY (account_id ASC);
> {code}
> {code:java}
> BEGIN TRANSACTION
> INSERT INTO accord.accounts (partition, account_id, balance) VALUES
> ('default', 0, 100);
> INSERT INTO accord.accounts (partition, account_id, balance) VALUES
> ('default', 1, 100);
> COMMIT TRANSACTION;{code}
> atomicity bug happens after executing the following statement:
> Based on [Cassandra
> documentation|https://cassandra.apache.org/doc/4.1/cassandra/cql/dml.html#update-statement]
> regarding the use of UPDATE statements, I expect the result of this
> transaction to be the insertion of a new account (\{ account_id: 3, balance:
> 10 }). The total balance across the three (3) accounts should be maintained
> (200). After executing the below transaction, the total number of accounts
> remains at two (2) and the total balance drops to 190. Basically, it appears
> as if only one half of the transaction proceeds.
> {code:java}
> BEGIN TRANSACTION
> UPDATE accord.accounts
> SET balance -= 10
> WHERE
> partition = 'default'
> AND account_id = 1;
> UPDATE accord.accounts
> SET balance += 10
> WHERE
> partition = 'default'
> AND account_id = 3;
> COMMIT TRANSACTION;{code}
> Bug / Error:
> ==
> The result of performing a table read after executing the buggy transaction
> is:
> {code:java}
> partition | account_id | balance
> ---++-
> default | 0 | 100
> default | 1 | 90
> {code}
> {color:#172b4d}Note that the above transactions are not possible without a
> transaction block because only counter type columns can be updated with += or
> -= syntax in normal (non-transactional) cql statements. Using counter type
> columns also results in a separate, related bug:
> [CASSANDRA-18987|https://issues.apache.org/jira/browse/CASSANDRA-18987]{color}
> {color:#172b4d}This was found while testing Accord transactions with
> [~henrik.ingo] and team.{color}
--
This message was sent by Atlassian Jira
(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-19704) UnsupportedOperationException is thrown when no space for LCS
[ https://issues.apache.org/jira/browse/CASSANDRA-19704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17859761#comment-17859761 ] Caleb Rackliffe commented on CASSANDRA-19704: - [~marcuse] and I have a patch for this. I'll try to get it posted this week some time. > UnsupportedOperationException is thrown when no space for LCS > - > > Key: CASSANDRA-19704 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19704 > Project: Cassandra > Issue Type: Bug > Components: Local/Compaction/LCS >Reporter: Zhao Yang >Assignee: Caleb Rackliffe >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.0.x, 5.x > > > In `CompactionTask#buildCompactionCandidatesForAvailableDiskSpace` with LCS, > if node has limited disk space and can't remove any sstable from L0 or L1 in > `LeveledCompactionTask#reduceScopeForLimitedSpace`, > `LeveledCompactionTask#partialCompactionsAcceptable` will throw > `UnsupportedOperationException`. > We should handle `LeveledCompactionTask#partialCompactionsAcceptable` more > gracefully with `return level <= 1` or simply `true` since > `reduceScopeForLimitedSpace` only removes sstable from L0 or L1. > Related https://issues.apache.org/jira/browse/CASSANDRA-17272 -- This message was sent by Atlassian Jira (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-19704) UnsupportedOperationException is thrown when no space for LCS
[ https://issues.apache.org/jira/browse/CASSANDRA-19704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Rackliffe reassigned CASSANDRA-19704: --- Assignee: Caleb Rackliffe > UnsupportedOperationException is thrown when no space for LCS > - > > Key: CASSANDRA-19704 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19704 > Project: Cassandra > Issue Type: Bug > Components: Local/Compaction/LCS >Reporter: Zhao Yang >Assignee: Caleb Rackliffe >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.0.x, 5.x > > > In `CompactionTask#buildCompactionCandidatesForAvailableDiskSpace` with LCS, > if node has limited disk space and can't remove any sstable from L0 or L1 in > `LeveledCompactionTask#reduceScopeForLimitedSpace`, > `LeveledCompactionTask#partialCompactionsAcceptable` will throw > `UnsupportedOperationException`. > We should handle `LeveledCompactionTask#partialCompactionsAcceptable` more > gracefully with `return level <= 1` or simply `true` since > `reduceScopeForLimitedSpace` only removes sstable from L0 or L1. > Related https://issues.apache.org/jira/browse/CASSANDRA-17272 -- This message was sent by Atlassian Jira (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-18107) CEP-15: Multi-Partition Transaction CQL Support (Alpha -> v1)
[
https://issues.apache.org/jira/browse/CASSANDRA-18107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-18107:
Description:
With CASSANDRA-17719 complete, basic/alpha CQL support for Accord is now
available in the
[cep-15-accord|https://github.com/apache/cassandra/commits/cep-15-accord]
branch. There are, however, a number of features and enhancements that we would
still like to add before we make it available to users. Here is a summary of
those items, broadly categorized:
h3. *High Priority*
*Error Messages and UX*
- Fix the element/field names in result metadata to match the user query
- Better error messages
-- Append/subtracting to/from frozen list
-- attempts to use reference in WHERE clause
-- LET using a reserved word
*Testing*
- Figure out the original intent of placeholder tests in
{{AccordIntegrationTest}} (ex. {{{}acceptInvalidationTest(){}}})
*Features*
- Support for returning the result of an {{{}IF{}}}/condition
- Constant terms on the RHS of LET
- Support for having a reference on both LHS and RHS of {{IF}} predicates
- Support for {{{}CONTAINS{}}}, {{{}CONTAINS KEY{}}}, and {{IN}} (important
for CAS parity)
- Mixed conditional and unconditional updates
- Arithmetic operations on references in {{{}INSERT{}}}/{{{}UPDATE{}}} (ex.
INSERT INTO ks.tbl1 (k, c, v) VALUES (0, 0, a.v + 1)
- Support TTLs specified in txn updates.
*Tooling*
- Remove {{reateepochunsafe}} references in {{JMXGetterCheckTest}}
*Documentation*
- JavaDoc for all new statement classes
h3. *Nice to Have*
*Domain Object Cleanup*
- Given {{Selector}} is serializable, attempt to reuse it in {{TxnReference}}
rather than hard coding data conversion cases
- Separate current current {{LET}} statement from {{{}SelectStatement{}}},
likely as a new {{LetStatement}} that names a {{SelectStatement}}
- Explore unifying {{Operation}} and {{ReferenceOperation}}
- Include non-Row items of {{FilteredPartition}} in
{{TxnData#estimatedSizeOnHeap()}}
- Explore possibility of making {{Bound}} serializable and using it directly
in {{TxnCondition}}
- Change internal representation of {{TxnDataName}} to avoid {{String}} ->
{{ByteBuffer}} conversions
- Have {{{}TxnCondition{}}}/{{{}TxnUpdate{}}} support {{slice()}} to full take
advantage of partial state replication
- Update serialization logic to reflect CASSANDRA-18099
*Features*
- Full JSON support
- Nested UDT support
*Documentation*
- CQL language documentation and bump the CQL language specification version
- JavaDoc for all new statement classes
- Integrate {{demo.txt}} into broader documentation somewhere or remove
was:
With CASSANDRA-17719 complete, basic/alpha CQL support for Accord is now
available in the
[cep-15-accord|https://github.com/apache/cassandra/commits/cep-15-accord]
branch. There are, however, a number of features and enhancements that we would
still like to add before we make it available to users. Here is a summary of
those items, broadly categorized:
h3. *High Priority*
*Error Messages and UX*
- Fix the element/field names in result metadata to match the user query
- Better error messages
-- Append/subtracting to/from frozen list
-- attempts to use reference in WHERE clause
-- LET using a reserved word
*Testing*
- Figure out the original intent of placeholder tests in
{{AccordIntegrationTest}} (ex. {{{}acceptInvalidationTest(){}}}){-}{{-}}
*Features*
- Support for returning the result of an {{{}IF{}}}/condition
- Constant terms on the RHS of LET
- Support for having a reference on both LHS and RHS of {{IF}} predicates
- Support for {{{}CONTAINS{}}}, {{{}CONTAINS KEY{}}}, and {{IN}} (important
for CAS parity)
- Mixed conditional and unconditional updates
- Arithmetic operations on references in {{{}INSERT{}}}/{{{}UPDATE{}}} (ex.
INSERT INTO ks.tbl1 (k, c, v) VALUES (0, 0, a.v + 1)
- Support TTLs specified in txn updates.
*Tooling*
- Remove {{reateepochunsafe}} references in {{JMXGetterCheckTest}}
*Documentation*
- JavaDoc for all new statement classes
h3. *Nice to Have*
*Domain Object Cleanup*
- Given {{Selector}} is serializable, attempt to reuse it in {{TxnReference}}
rather than hard coding data conversion cases
- Separate current current {{LET}} statement from {{{}SelectStatement{}}},
likely as a new {{LetStatement}} that names a {{SelectStatement}}
- Explore unifying {{Operation}} and {{ReferenceOperation}}
- Include non-Row items of {{FilteredPartition}} in
{{TxnData#estimatedSizeOnHeap()}}
- Explore possibility of making {{Bound}} serializable and using it directly
in {{TxnCondition}}
- Change internal representation of {{TxnDataName}} to avoid {{String}} ->
{{ByteBuffer}} conversions
- Have {{{}TxnCondition{}}}/{{{}TxnUpdate{}}} support {{slice()}} to full take
advantage of partial state replication
- Update serialization logic to reflect CASSANDRA-18099
[jira] [Assigned] (CASSANDRA-19321) Accord: Command to mark replicas as “stale" for decommission
[ https://issues.apache.org/jira/browse/CASSANDRA-19321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Rackliffe reassigned CASSANDRA-19321: --- Assignee: Caleb Rackliffe > Accord: Command to mark replicas as “stale" for decommission > > > Key: CASSANDRA-19321 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19321 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: Benedict Elliott Smith >Assignee: Caleb Rackliffe >Priority: Normal > > So that other replicas may continue to cleanup their state, we must have an > operator command for marking replicas as stale so that the remaining replicas > do not wait for them to coordinate their durability status. -- This message was sent by Atlassian Jira (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-18107) CEP-15: Multi-Partition Transaction CQL Support (Alpha -> v1)
[
https://issues.apache.org/jira/browse/CASSANDRA-18107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-18107:
Description:
With CASSANDRA-17719 complete, basic/alpha CQL support for Accord is now
available in the
[cep-15-accord|https://github.com/apache/cassandra/commits/cep-15-accord]
branch. There are, however, a number of features and enhancements that we would
still like to add before we make it available to users. Here is a summary of
those items, broadly categorized:
h3. {*}High Priority{*}{*}{*}
*Error Messages and UX*
- Fix the element/field names in result metadata to match the user query
- Better error messages
-- Append/subtracting to/from frozen list
-- attempts to use reference in WHERE clause
-- LET using a reserved word
*Testing*
- Figure out the original intent of placeholder tests in
{{AccordIntegrationTest}} (ex. {{{}acceptInvalidationTest(){}}}){-}{{-}}
*Features*
- Support for returning the result of an {{{}IF{}}}/condition
- Constant terms on the RHS of LET
- Support for having a reference on both LHS and RHS of {{IF}} predicates
- Support for {{{}CONTAINS{}}}, {{{}CONTAINS KEY{}}}, and {{IN}} (important
for CAS parity)
- Mixed conditional and unconditional updates
- Arithmetic operations on references in {{{}INSERT{}}}/{{{}UPDATE{}}} (ex.
INSERT INTO ks.tbl1 (k, c, v) VALUES (0, 0, a.v + 1)
- Support TTLs specified in txn updates.
*Tooling*
- Remove {{reateepochunsafe}} references in {{JMXGetterCheckTest}}
*Documentation*
- JavaDoc for all new statement classes
h3. *Nice to Have*
*Domain Object Cleanup*
- Given {{Selector}} is serializable, attempt to reuse it in {{TxnReference}}
rather than hard coding data conversion cases
- Separate current current {{LET}} statement from {{{}SelectStatement{}}},
likely as a new {{LetStatement}} that names a {{SelectStatement}}
- Explore unifying {{Operation}} and {{ReferenceOperation}}
- Include non-Row items of {{FilteredPartition}} in
{{TxnData#estimatedSizeOnHeap()}}
- Explore possibility of making {{Bound}} serializable and using it directly
in {{TxnCondition}}
- Change internal representation of {{TxnDataName}} to avoid {{String}} ->
{{ByteBuffer}} conversions
- Have {{{}TxnCondition{}}}/{{{}TxnUpdate{}}} support {{slice()}} to full take
advantage of partial state replication
- Update serialization logic to reflect CASSANDRA-18099
*Features*
- Full JSON support
- Nested UDT support
*Documentation*
- CQL language documentation and bump the CQL language specification version
- JavaDoc for all new statement classes
- Integrate {{demo.txt}} into broader documentation somewhere or remove
was:
With CASSANDRA-17719 complete, basic/alpha CQL support for Accord is now
available in the
[cep-15-accord|https://github.com/apache/cassandra/commits/cep-15-accord]
branch. There are, however, a number of features and enhancements that we would
still like to add before we make it available to users. Here is a summary of
those items, broadly categorized:
h3. {*}High Priority{*}{*}{*}
*Error Messages and UX*
- Fix the element/field names in result metadata to match the user query
- Better error messages
-- Append/subtracting to/from frozen list
-- attempts to use reference in WHERE clause
-- LET using a reserved word
*Testing*
- Figure out the original intent of placeholder tests in
{{AccordIntegrationTest}} (ex. {{{}acceptInvalidationTest(){}}}){-}{-}
*Features*
- Support for returning the result of an {{{}IF{}}}/condition
- Constant terms on the RHS of LET
- Support for having a reference on both LHS and RHS of {{IF}} predicates
- Support for {{{}CONTAINS{}}}, {{{}CONTAINS KEY{}}}, and {{IN}} (important
for CAS parity)
- Mixed conditional and unconditional updates
- Arithmetic operations on references in {{{}INSERT{}}}/{{{}UPDATE{}}} (ex.
INSERT INTO ks.tbl1 (k, c, v) VALUES (0, 0, a.v + 1)
- Support TTLs specified in txn updates.
*Tooling*
- Remove {{reateepochunsafe}} references in {{JMXGetterCheckTest}}
*Documentation*
- JavaDoc for all new statement classes
h3. *Nice to Have*
*Domain Object Cleanup*
- Given {{Selector}} is serializable, attempt to reuse it in {{TxnReference}}
rather than hard coding data conversion cases
- Separate current current {{LET}} statement from {{{}SelectStatement{}}},
likely as a new {{LetStatement}} that names a {{SelectStatement}}
- Explore unifying {{Operation}} and {{ReferenceOperation}}
- Include non-Row items of {{FilteredPartition}} in
{{TxnData#estimatedSizeOnHeap()}}
- Explore possibility of making {{Bound}} serializable and using it directly
in {{TxnCondition}}
- Change internal representation of {{TxnDataName}} to avoid {{String}} ->
{{ByteBuffer}} conversions
- Have {{{}TxnCondition{}}}/{{{}TxnUpdate{}}} support {{slice()}} to full take
advantage of partial state replication
- Update serialization logic to
[jira] [Updated] (CASSANDRA-18107) CEP-15: Multi-Partition Transaction CQL Support (Alpha -> v1)
[
https://issues.apache.org/jira/browse/CASSANDRA-18107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-18107:
Description:
With CASSANDRA-17719 complete, basic/alpha CQL support for Accord is now
available in the
[cep-15-accord|https://github.com/apache/cassandra/commits/cep-15-accord]
branch. There are, however, a number of features and enhancements that we would
still like to add before we make it available to users. Here is a summary of
those items, broadly categorized:
h3. *High Priority*
*Error Messages and UX*
- Fix the element/field names in result metadata to match the user query
- Better error messages
-- Append/subtracting to/from frozen list
-- attempts to use reference in WHERE clause
-- LET using a reserved word
*Testing*
- Figure out the original intent of placeholder tests in
{{AccordIntegrationTest}} (ex. {{{}acceptInvalidationTest(){}}}){-}{{-}}
*Features*
- Support for returning the result of an {{{}IF{}}}/condition
- Constant terms on the RHS of LET
- Support for having a reference on both LHS and RHS of {{IF}} predicates
- Support for {{{}CONTAINS{}}}, {{{}CONTAINS KEY{}}}, and {{IN}} (important
for CAS parity)
- Mixed conditional and unconditional updates
- Arithmetic operations on references in {{{}INSERT{}}}/{{{}UPDATE{}}} (ex.
INSERT INTO ks.tbl1 (k, c, v) VALUES (0, 0, a.v + 1)
- Support TTLs specified in txn updates.
*Tooling*
- Remove {{reateepochunsafe}} references in {{JMXGetterCheckTest}}
*Documentation*
- JavaDoc for all new statement classes
h3. *Nice to Have*
*Domain Object Cleanup*
- Given {{Selector}} is serializable, attempt to reuse it in {{TxnReference}}
rather than hard coding data conversion cases
- Separate current current {{LET}} statement from {{{}SelectStatement{}}},
likely as a new {{LetStatement}} that names a {{SelectStatement}}
- Explore unifying {{Operation}} and {{ReferenceOperation}}
- Include non-Row items of {{FilteredPartition}} in
{{TxnData#estimatedSizeOnHeap()}}
- Explore possibility of making {{Bound}} serializable and using it directly
in {{TxnCondition}}
- Change internal representation of {{TxnDataName}} to avoid {{String}} ->
{{ByteBuffer}} conversions
- Have {{{}TxnCondition{}}}/{{{}TxnUpdate{}}} support {{slice()}} to full take
advantage of partial state replication
- Update serialization logic to reflect CASSANDRA-18099
*Features*
- Full JSON support
- Nested UDT support
*Documentation*
- CQL language documentation and bump the CQL language specification version
- JavaDoc for all new statement classes
- Integrate {{demo.txt}} into broader documentation somewhere or remove
was:
With CASSANDRA-17719 complete, basic/alpha CQL support for Accord is now
available in the
[cep-15-accord|https://github.com/apache/cassandra/commits/cep-15-accord]
branch. There are, however, a number of features and enhancements that we would
still like to add before we make it available to users. Here is a summary of
those items, broadly categorized:
h3. {*}High Priority{*}{*}{*}
*Error Messages and UX*
- Fix the element/field names in result metadata to match the user query
- Better error messages
-- Append/subtracting to/from frozen list
-- attempts to use reference in WHERE clause
-- LET using a reserved word
*Testing*
- Figure out the original intent of placeholder tests in
{{AccordIntegrationTest}} (ex. {{{}acceptInvalidationTest(){}}}){-}{{-}}
*Features*
- Support for returning the result of an {{{}IF{}}}/condition
- Constant terms on the RHS of LET
- Support for having a reference on both LHS and RHS of {{IF}} predicates
- Support for {{{}CONTAINS{}}}, {{{}CONTAINS KEY{}}}, and {{IN}} (important
for CAS parity)
- Mixed conditional and unconditional updates
- Arithmetic operations on references in {{{}INSERT{}}}/{{{}UPDATE{}}} (ex.
INSERT INTO ks.tbl1 (k, c, v) VALUES (0, 0, a.v + 1)
- Support TTLs specified in txn updates.
*Tooling*
- Remove {{reateepochunsafe}} references in {{JMXGetterCheckTest}}
*Documentation*
- JavaDoc for all new statement classes
h3. *Nice to Have*
*Domain Object Cleanup*
- Given {{Selector}} is serializable, attempt to reuse it in {{TxnReference}}
rather than hard coding data conversion cases
- Separate current current {{LET}} statement from {{{}SelectStatement{}}},
likely as a new {{LetStatement}} that names a {{SelectStatement}}
- Explore unifying {{Operation}} and {{ReferenceOperation}}
- Include non-Row items of {{FilteredPartition}} in
{{TxnData#estimatedSizeOnHeap()}}
- Explore possibility of making {{Bound}} serializable and using it directly
in {{TxnCondition}}
- Change internal representation of {{TxnDataName}} to avoid {{String}} ->
{{ByteBuffer}} conversions
- Have {{{}TxnCondition{}}}/{{{}TxnUpdate{}}} support {{slice()}} to full take
advantage of partial state replication
- Update serialization logic to reflect
[jira] [Updated] (CASSANDRA-18107) CEP-15: Multi-Partition Transaction CQL Support (Alpha -> v1)
[
https://issues.apache.org/jira/browse/CASSANDRA-18107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-18107:
Description:
With CASSANDRA-17719 complete, basic/alpha CQL support for Accord is now
available in the
[cep-15-accord|https://github.com/apache/cassandra/commits/cep-15-accord]
branch. There are, however, a number of features and enhancements that we would
still like to add before we make it available to users. Here is a summary of
those items, broadly categorized:
h3. {*}High Priority{*}{*}{*}
*Error Messages and UX*
- Fix the element/field names in result metadata to match the user query
- Better error messages
-- Append/subtracting to/from frozen list
-- attempts to use reference in WHERE clause
-- LET using a reserved word
*Testing*
- Figure out the original intent of placeholder tests in
{{AccordIntegrationTest}} (ex. {{{}acceptInvalidationTest(){}}}){-}{-}
*Features*
- Support for returning the result of an {{{}IF{}}}/condition
- Constant terms on the RHS of LET
- Support for having a reference on both LHS and RHS of {{IF}} predicates
- Support for {{{}CONTAINS{}}}, {{{}CONTAINS KEY{}}}, and {{IN}} (important
for CAS parity)
- Mixed conditional and unconditional updates
- Arithmetic operations on references in {{{}INSERT{}}}/{{{}UPDATE{}}} (ex.
INSERT INTO ks.tbl1 (k, c, v) VALUES (0, 0, a.v + 1)
- Support TTLs specified in txn updates.
*Tooling*
- Remove {{reateepochunsafe}} references in {{JMXGetterCheckTest}}
*Documentation*
- JavaDoc for all new statement classes
h3. *Nice to Have*
*Domain Object Cleanup*
- Given {{Selector}} is serializable, attempt to reuse it in {{TxnReference}}
rather than hard coding data conversion cases
- Separate current current {{LET}} statement from {{{}SelectStatement{}}},
likely as a new {{LetStatement}} that names a {{SelectStatement}}
- Explore unifying {{Operation}} and {{ReferenceOperation}}
- Include non-Row items of {{FilteredPartition}} in
{{TxnData#estimatedSizeOnHeap()}}
- Explore possibility of making {{Bound}} serializable and using it directly
in {{TxnCondition}}
- Change internal representation of {{TxnDataName}} to avoid {{String}} ->
{{ByteBuffer}} conversions
- Have {{{}TxnCondition{}}}/{{{}TxnUpdate{}}} support {{slice()}} to full take
advantage of partial state replication
- Update serialization logic to reflect CASSANDRA-18099
*Features*
- Full JSON support
- Nested UDT support
*Documentation*
- CQL language documentation and bump the CQL language specification version
- JavaDoc for all new statement classes
- Integrate {{demo.txt}} into broader documentation somewhere or remove
was:
With CASSANDRA-17719 complete, basic/alpha CQL support for Accord is now
available in the
[cep-15-accord|https://github.com/apache/cassandra/commits/cep-15-accord]
branch. There are, however, a number of features and enhancements that we would
still like to add before we make it available to users. Here is a summary of
those items, broadly categorized:
*Error Messages and UX*
- Fix the element/field names in result metadata to match the user query
- Better error messages
-- Append/subtracting to/from frozen list
-- attempts to use reference in WHERE clause
-- LET using a reserved word
*Domain Object Cleanup* (Potentially move to post v1)
- Given {{Selector}} is serializable, attempt to reuse it in {{TxnReference}}
rather than hard coding data conversion cases
- Separate current current {{LET}} statement from {{{}SelectStatement{}}},
likely as a new {{LetStatement}} that names a {{SelectStatement}}
- Explore unifying {{Operation}} and {{ReferenceOperation}}
- Include non-Row items of {{FilteredPartition}} in
{{TxnData#estimatedSizeOnHeap()}}
- Explore possibility of making {{Bound}} serializable and using it directly
in {{TxnCondition}}
- Change internal representation of {{TxnDataName}} to avoid {{String}} ->
{{ByteBuffer}} conversions
- Have {{{}TxnCondition{}}}/{{{}TxnUpdate{}}} support {{slice()}} to full take
advantage of partial state replication
- Update serialization logic to reflect CASSANDRA-18099
*Testing*
- Figure out the original intent of placeholder tests in
{{AccordIntegrationTest}} (ex. {{{}acceptInvalidationTest(){}}})
- -Remove hack in {{AccordConfigurationService}} (when we have Transactional
Metadata)-
- Verify concretely that we disable Guardrails (TODO: Break out into its own
Jira?)
- -Audit the way we propagate timestamps through execution.-
*Features*
- Full JSON support
- Final decision of whether we should support returning the result of an
{{{}IF{}}}/condition
- Constant terms on the RHS of LET
- Support for having a reference on both LHS and RHS of {{IF}} predicates
- Support for {{{}CONTAINS{}}}, {{{}CONTAINS KEY{}}}, and {{IN}} (important
for CAS parity)
- Nested UDT support
- Mixed conditional and unconditional updates
[jira] [Commented] (CASSANDRA-18988) Updating the column of a non-existent row in an Accord transaction results in Atomicity violation
[
https://issues.apache.org/jira/browse/CASSANDRA-18988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17856605#comment-17856605
]
Caleb Rackliffe commented on CASSANDRA-18988:
-
I've started a thread on the dev mailing list to see if there's any appetite to
change this behavior, which is, as [~benedict] has mentioned, the intended one.
[https://lists.apache.org/thread/rb29cbdkqv20gmbsx6w92r4lj0h4tmq8]
> Updating the column of a non-existent row in an Accord transaction results in
> Atomicity violation
> -
>
> Key: CASSANDRA-18988
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18988
> Project: Cassandra
> Issue Type: Bug
> Components: Accord
>Reporter: Luis E Fernandez
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 5.x
>
>
> *System configuration and information:*
> Single node Cassandra with Accord transactions enabled running on docker
> Built from commit:
> [a7cd114435704b988c81f47ef53d0bfd6441f38b|https://github.com/apache/cassandra/commit/a7cd114435704b988c81f47ef53d0bfd6441f38b]
> CQLSH: [cqlsh 6.2.0 | Cassandra 5.0-alpha2-SNAPSHOT | CQL spec 3.4.7 | Native
> protocol v5]
>
> *Steps to reproduce in CQLSH:*
> {code:java}
> CREATE KEYSPACE accord WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;{code}
> {code:java}
> CREATE TABLE accord.accounts (
> partition text,
> account_id int,
> balance int,
> PRIMARY KEY (partition, account_id)
> ) WITH CLUSTERING ORDER BY (account_id ASC);
> {code}
> {code:java}
> BEGIN TRANSACTION
> INSERT INTO accord.accounts (partition, account_id, balance) VALUES
> ('default', 0, 100);
> INSERT INTO accord.accounts (partition, account_id, balance) VALUES
> ('default', 1, 100);
> COMMIT TRANSACTION;{code}
> atomicity bug happens after executing the following statement:
> Based on [Cassandra
> documentation|https://cassandra.apache.org/doc/4.1/cassandra/cql/dml.html#update-statement]
> regarding the use of UPDATE statements, I expect the result of this
> transaction to be the insertion of a new account (\{ account_id: 3, balance:
> 10 }). The total balance across the three (3) accounts should be maintained
> (200). After executing the below transaction, the total number of accounts
> remains at two (2) and the total balance drops to 190. Basically, it appears
> as if only one half of the transaction proceeds.
> {code:java}
> BEGIN TRANSACTION
> UPDATE accord.accounts
> SET balance -= 10
> WHERE
> partition = 'default'
> AND account_id = 1;
> UPDATE accord.accounts
> SET balance += 10
> WHERE
> partition = 'default'
> AND account_id = 3;
> COMMIT TRANSACTION;{code}
> Bug / Error:
> ==
> The result of performing a table read after executing the buggy transaction
> is:
> {code:java}
> partition | account_id | balance
> ---++-
> default | 0 | 100
> default | 1 | 90
> {code}
> {color:#172b4d}Note that the above transactions are not possible without a
> transaction block because only counter type columns can be updated with += or
> -= syntax in normal (non-transactional) cql statements. Using counter type
> columns also results in a separate, related bug:
> [CASSANDRA-18987|https://issues.apache.org/jira/browse/CASSANDRA-18987]{color}
> {color:#172b4d}This was found while testing Accord transactions with
> [~henrik.ingo] and team.{color}
--
This message was sent by Atlassian Jira
(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-19675) Avoid streams in the common case for UpdateTransaction creation
[
https://issues.apache.org/jira/browse/CASSANDRA-19675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-19675:
Fix Version/s: 5.0
5.1
(was: 5.x)
(was: 5.0.x)
Source Control Link:
https://github.com/apache/cassandra/commit/ba5ab993c7a279b014f439a5d06683d3b568d4ff
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
> Avoid streams in the common case for UpdateTransaction creation
> ---
>
> Key: CASSANDRA-19675
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19675
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/SAI
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 5.0, 5.1
>
> Attachments: ci_summary-1.html, ci_summary.html,
> new_update_txn_streams.png
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Some recent Accord profiling highlighted some easily addressable inefficiency
> in the way we create new {{UpdateTransaction}} objects in
> {{SecondaryIndexManager}} that have existed since the introduction of index
> groups for SAI. We should be able to clean this up by avoiding stream
> creation or even iteration over the groups when there is a single index
> group, which is going to be the most common case with SAI anyway. If we do
> have to iterate, there should also be no reason to copy the collection of
> index groups via {{listIndexGroups()}}, although that copying can remain in
> the method itself for external callers.
> !new_update_txn_streams.png!
--
This message was sent by Atlassian Jira
(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-19675) Avoid streams in the common case for UpdateTransaction creation
[
https://issues.apache.org/jira/browse/CASSANDRA-19675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-19675:
Status: Ready to Commit (was: Review In Progress)
> Avoid streams in the common case for UpdateTransaction creation
> ---
>
> Key: CASSANDRA-19675
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19675
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/SAI
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 5.0.x, 5.x
>
> Attachments: ci_summary-1.html, ci_summary.html,
> new_update_txn_streams.png
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Some recent Accord profiling highlighted some easily addressable inefficiency
> in the way we create new {{UpdateTransaction}} objects in
> {{SecondaryIndexManager}} that have existed since the introduction of index
> groups for SAI. We should be able to clean this up by avoiding stream
> creation or even iteration over the groups when there is a single index
> group, which is going to be the most common case with SAI anyway. If we do
> have to iterate, there should also be no reason to copy the collection of
> index groups via {{listIndexGroups()}}, although that copying can remain in
> the method itself for external callers.
> !new_update_txn_streams.png!
--
This message was sent by Atlassian Jira
(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-19697) Test failure: materialized_views_test.py::TestMaterializedViews::test_rename_column_atomicity
[ https://issues.apache.org/jira/browse/CASSANDRA-19697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17856123#comment-17856123 ] Caleb Rackliffe commented on CASSANDRA-19697: - bq. along with my patch to limit waiting on Dispatcher.isDone to native_transport_timeout. I feel like that safeguard is a good idea since we don't know what other behavior may cause it to hang indefinitely. +1 > Test failure: > materialized_views_test.py::TestMaterializedViews::test_rename_column_atomicity > - > > Key: CASSANDRA-19697 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19697 > Project: Cassandra > Issue Type: Bug > Components: Feature/Materialized Views >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 5.0-rc, 5.x > > Attachments: shutdown_stuck.txt > > > Breaking this out from CASSANDRA-19683. The byteman script fails to execute > in 5.0/trunk after CASSANDRA-19534. -- This message was sent by Atlassian Jira (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-19675) Avoid streams in the common case for UpdateTransaction creation
[
https://issues.apache.org/jira/browse/CASSANDRA-19675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-19675:
Reviewers: David Capwell, Jeremiah Jordan (was: David Capwell)
> Avoid streams in the common case for UpdateTransaction creation
> ---
>
> Key: CASSANDRA-19675
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19675
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/SAI
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 5.0.x, 5.x
>
> Attachments: ci_summary-1.html, ci_summary.html,
> new_update_txn_streams.png
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Some recent Accord profiling highlighted some easily addressable inefficiency
> in the way we create new {{UpdateTransaction}} objects in
> {{SecondaryIndexManager}} that have existed since the introduction of index
> groups for SAI. We should be able to clean this up by avoiding stream
> creation or even iteration over the groups when there is a single index
> group, which is going to be the most common case with SAI anyway. If we do
> have to iterate, there should also be no reason to copy the collection of
> index groups via {{listIndexGroups()}}, although that copying can remain in
> the method itself for external callers.
> !new_update_txn_streams.png!
--
This message was sent by Atlassian Jira
(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-19675) Avoid streams in the common case for UpdateTransaction creation
[
https://issues.apache.org/jira/browse/CASSANDRA-19675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-19675:
Attachment: ci_summary-1.html
> Avoid streams in the common case for UpdateTransaction creation
> ---
>
> Key: CASSANDRA-19675
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19675
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/SAI
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 5.0.x, 5.x
>
> Attachments: ci_summary-1.html, ci_summary.html,
> new_update_txn_streams.png
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Some recent Accord profiling highlighted some easily addressable inefficiency
> in the way we create new {{UpdateTransaction}} objects in
> {{SecondaryIndexManager}} that have existed since the introduction of index
> groups for SAI. We should be able to clean this up by avoiding stream
> creation or even iteration over the groups when there is a single index
> group, which is going to be the most common case with SAI anyway. If we do
> have to iterate, there should also be no reason to copy the collection of
> index groups via {{listIndexGroups()}}, although that copying can remain in
> the method itself for external callers.
> !new_update_txn_streams.png!
--
This message was sent by Atlassian Jira
(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-19675) Avoid streams in the common case for UpdateTransaction creation
[
https://issues.apache.org/jira/browse/CASSANDRA-19675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17855665#comment-17855665
]
Caleb Rackliffe commented on CASSANDRA-19675:
-
trunk CI looks fine as well [^ci_summary-1.html]
> Avoid streams in the common case for UpdateTransaction creation
> ---
>
> Key: CASSANDRA-19675
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19675
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/SAI
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 5.0.x, 5.x
>
> Attachments: ci_summary-1.html, ci_summary.html,
> new_update_txn_streams.png
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Some recent Accord profiling highlighted some easily addressable inefficiency
> in the way we create new {{UpdateTransaction}} objects in
> {{SecondaryIndexManager}} that have existed since the introduction of index
> groups for SAI. We should be able to clean this up by avoiding stream
> creation or even iteration over the groups when there is a single index
> group, which is going to be the most common case with SAI anyway. If we do
> have to iterate, there should also be no reason to copy the collection of
> index groups via {{listIndexGroups()}}, although that copying can remain in
> the method itself for external callers.
> !new_update_txn_streams.png!
--
This message was sent by Atlassian Jira
(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-19675) Avoid streams in the common case for UpdateTransaction creation
[
https://issues.apache.org/jira/browse/CASSANDRA-19675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-19675:
Reviewers: David Capwell
Status: Review In Progress (was: Patch Available)
> Avoid streams in the common case for UpdateTransaction creation
> ---
>
> Key: CASSANDRA-19675
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19675
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/SAI
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 5.0.x, 5.x
>
> Attachments: ci_summary-1.html, ci_summary.html,
> new_update_txn_streams.png
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Some recent Accord profiling highlighted some easily addressable inefficiency
> in the way we create new {{UpdateTransaction}} objects in
> {{SecondaryIndexManager}} that have existed since the introduction of index
> groups for SAI. We should be able to clean this up by avoiding stream
> creation or even iteration over the groups when there is a single index
> group, which is going to be the most common case with SAI anyway. If we do
> have to iterate, there should also be no reason to copy the collection of
> index groups via {{listIndexGroups()}}, although that copying can remain in
> the method itself for external callers.
> !new_update_txn_streams.png!
--
This message was sent by Atlassian Jira
(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-19697) Test failure: materialized_views_test.py::TestMaterializedViews::test_rename_column_atomicity
[ https://issues.apache.org/jira/browse/CASSANDRA-19697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Rackliffe updated CASSANDRA-19697: Reviewers: Caleb Rackliffe, Stefan Miklosovic (was: Stefan Miklosovic) > Test failure: > materialized_views_test.py::TestMaterializedViews::test_rename_column_atomicity > - > > Key: CASSANDRA-19697 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19697 > Project: Cassandra > Issue Type: Bug > Components: Feature/Materialized Views >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 5.0-rc, 5.x > > Attachments: shutdown_stuck.txt > > > Breaking this out from CASSANDRA-19683. The byteman script fails to execute > in 5.0/trunk after CASSANDRA-19534. -- This message was sent by Atlassian Jira (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-19697) Test failure: materialized_views_test.py::TestMaterializedViews::test_rename_column_atomicity
[
https://issues.apache.org/jira/browse/CASSANDRA-19697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17855114#comment-17855114
]
Caleb Rackliffe commented on CASSANDRA-19697:
-
{{shutdownClientServers()}} looks like it only affects drain and decom, so I
have no problem w/ the patch, and all it seems to do is revert to pre
CASSANDRA-19534 behavior. It doesn't matter on 4.1, as that doesn't wait for
the {{Dispatcher}} anyway. I'm just not entirely sure why 5.0 isn't getting
into a state where {{Dispatcher#requestExecutor}} is finished.
CC [~ifesdjeen]
> Test failure:
> materialized_views_test.py::TestMaterializedViews::test_rename_column_atomicity
> -
>
> Key: CASSANDRA-19697
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19697
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Materialized Views
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
> Attachments: shutdown_stuck.txt
>
>
> Breaking this out from CASSANDRA-19683. The byteman script fails to execute
> in 5.0/trunk after CASSANDRA-19534.
--
This message was sent by Atlassian Jira
(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-18107) CEP-15: Multi-Partition Transaction CQL Support (Alpha -> v1)
[
https://issues.apache.org/jira/browse/CASSANDRA-18107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-18107:
Description:
With CASSANDRA-17719 complete, basic/alpha CQL support for Accord is now
available in the
[cep-15-accord|https://github.com/apache/cassandra/commits/cep-15-accord]
branch. There are, however, a number of features and enhancements that we would
still like to add before we make it available to users. Here is a summary of
those items, broadly categorized:
*Error Messages and UX*
- Fix the element/field names in result metadata to match the user query
- Better error messages
-- Append/subtracting to/from frozen list
-- attempts to use reference in WHERE clause
-- LET using a reserved word
*Domain Object Cleanup* (Potentially move to post v1)
- Given {{Selector}} is serializable, attempt to reuse it in {{TxnReference}}
rather than hard coding data conversion cases
- Separate current current {{LET}} statement from {{{}SelectStatement{}}},
likely as a new {{LetStatement}} that names a {{SelectStatement}}
- Explore unifying {{Operation}} and {{ReferenceOperation}}
- Include non-Row items of {{FilteredPartition}} in
{{TxnData#estimatedSizeOnHeap()}}
- Explore possibility of making {{Bound}} serializable and using it directly
in {{TxnCondition}}
- Change internal representation of {{TxnDataName}} to avoid {{String}} ->
{{ByteBuffer}} conversions
- Have {{{}TxnCondition{}}}/{{{}TxnUpdate{}}} support {{slice()}} to full take
advantage of partial state replication
- Update serialization logic to reflect CASSANDRA-18099
*Testing*
- Figure out the original intent of placeholder tests in
{{AccordIntegrationTest}} (ex. {{{}acceptInvalidationTest(){}}})
- -Remove hack in {{AccordConfigurationService}} (when we have Transactional
Metadata)-
- Verify concretely that we disable Guardrails (TODO: Break out into its own
Jira?)
- -Audit the way we propagate timestamps through execution.-
*Features*
- Full JSON support
- Final decision of whether we should support returning the result of an
{{{}IF{}}}/condition
- Constant terms on the RHS of LET
- Support for having a reference on both LHS and RHS of {{IF}} predicates
- Support for {{{}CONTAINS{}}}, {{{}CONTAINS KEY{}}}, and {{IN}} (important
for CAS parity)
- Nested UDT support
- Mixed conditional and unconditional updates (should this be post-v1?)
- Arithmetic operations on references in {{{}INSERT{}}}/{{{}UPDATE{}}} (ex.
INSERT INTO ks.tbl1 (k, c, v) VALUES (0, 0, a.v + 1)
*Tooling*
- Eliminate {{nodetool createepochunsafe}} once transactional metadata is
available.
-- UPDATE: Removed now, but still in {{JMXGetterCheckTest}}
*Documentation*
- CQL language documentation and bump the CQL language specification version
- JavaDoc for all new statement classes
- Integrate {{demo.txt}} into broader documentation somewhere or remove
*Questions*
- How should txn statement parsing/preparation handle TTLs specified in
updates? (Should be supported.)
- At what level do we want to integrate tracing? (TODO: Break out into its own
Jira?)
was:
With CASSANDRA-17719 complete, basic/alpha CQL support for Accord is now
available in the
[cep-15-accord|https://github.com/apache/cassandra/commits/cep-15-accord]
branch. There are, however, a number of features and enhancements that we would
still like to add before we make it available to users. Here is a summary of
those items, broadly categorized:
*Error Messages and UX*
- Fix the element/field names in result metadata to match the user query
- Better error messages
-- Append/subtracting to/from frozen list
-- attempts to use reference in WHERE clause
-- LET using a reserved word
*Domain Object Cleanup*
- Given {{Selector}} is serializable, attempt to reuse it in {{TxnReference}}
rather than hard coding data conversion cases
- Separate current current {{LET}} statement from {{{}SelectStatement{}}},
likely as a new {{LetStatement}} that names a {{SelectStatement}}
- Explore unifying {{Operation}} and {{ReferenceOperation}}
- Include non-Row items of {{FilteredPartition}} in
{{TxnData#estimatedSizeOnHeap()}}
- Explore possibility of making {{Bound}} serializable and using it directly
in {{TxnCondition}}
- Change internal representation of {{TxnDataName}} to avoid {{String}} ->
{{ByteBuffer}} conversions
- Have {{{}TxnCondition{}}}/{{{}TxnUpdate{}}} support {{slice()}} to full take
advantage of partial state replication
- Update serialization logic to reflect CASSANDRA-18099
*Testing*
- Figure out the original intent of placeholder tests in
{{AccordIntegrationTest}} (ex. {{{}acceptInvalidationTest(){}}})
- -Remove hack in {{AccordConfigurationService}} (when we have Transactional
Metadata)-
- Verify concretely that we disable Guardrails.
- Audit the way we propagate timestamps through execution.
*Features*
- Full JSON
[jira] [Updated] (CASSANDRA-18107) CEP-15: Multi-Partition Transaction CQL Support (Alpha -> v1)
[
https://issues.apache.org/jira/browse/CASSANDRA-18107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-18107:
Description:
With CASSANDRA-17719 complete, basic/alpha CQL support for Accord is now
available in the
[cep-15-accord|https://github.com/apache/cassandra/commits/cep-15-accord]
branch. There are, however, a number of features and enhancements that we would
still like to add before we make it available to users. Here is a summary of
those items, broadly categorized:
*Error Messages and UX*
- Fix the element/field names in result metadata to match the user query
- Better error messages
-- Append/subtracting to/from frozen list
-- attempts to use reference in WHERE clause
-- LET using a reserved word
*Domain Object Cleanup*
- Given {{Selector}} is serializable, attempt to reuse it in {{TxnReference}}
rather than hard coding data conversion cases
- Separate current current {{LET}} statement from {{{}SelectStatement{}}},
likely as a new {{LetStatement}} that names a {{SelectStatement}}
- Explore unifying {{Operation}} and {{ReferenceOperation}}
- Include non-Row items of {{FilteredPartition}} in
{{TxnData#estimatedSizeOnHeap()}}
- Explore possibility of making {{Bound}} serializable and using it directly
in {{TxnCondition}}
- Change internal representation of {{TxnDataName}} to avoid {{String}} ->
{{ByteBuffer}} conversions
- Have {{{}TxnCondition{}}}/{{{}TxnUpdate{}}} support {{slice()}} to full take
advantage of partial state replication
- Update serialization logic to reflect CASSANDRA-18099
*Testing*
- Figure out the original intent of placeholder tests in
{{AccordIntegrationTest}} (ex. {{{}acceptInvalidationTest(){}}})
- -Remove hack in {{AccordConfigurationService}} (when we have Transactional
Metadata)-
- Verify concretely that we disable Guardrails.
- Audit the way we propagate timestamps through execution.
*Features*
- Full JSON support
- Final decision of whether we should support returning the result of an
{{{}IF{}}}/condition
- Constant terms on the RHS of LET
- Support for having a reference on both LHS and RHS of {{IF}} predicates
- Support for {{{}CONTAINS{}}}, {{{}CONTAINS KEY{}}}, and {{IN}} (important
for CAS parity)
- Nested UDT support
- Mixed conditional and unconditional updates (should this be post-v1?)
- Arithmetic operations on references in {{{}INSERT{}}}/{{{}UPDATE{}}} (ex.
INSERT INTO ks.tbl1 (k, c, v) VALUES (0, 0, a.v + 1)
*Tooling*
- Eliminate {{nodetool createepochunsafe}} once transactional metadata is
available.
-- UPDATE: Removed now, but still in {{JMXGetterCheckTest }}and
accord_demo.txt
*Documentation*
- CQL language documentation and bump the CQL language specification version
- JavaDoc for all new statement classes
- Integrate {{demo.txt}} into broader documentation somewhere or remove
*Questions*
- How should txn statement parsing/preparation handle TTLs specified in
updates?
- At what level do we want to integrate tracing?
was:
With CASSANDRA-17719 complete, basic/alpha CQL support for Accord is now
available in the
[cep-15-accord|https://github.com/apache/cassandra/commits/cep-15-accord]
branch. There are, however, a number of features and enhancements that we would
still like to add before we make it available to users. Here is a summary of
those items, broadly categorized:
*Error Messages and UX*
- Fix the element/field names in result metadata to match the user query
- Better error messages
-- Append/subtracting to/from frozen list
-- attempts to use reference in WHERE clause
-- LET using a reserved word
*Domain Object Cleanup*
- Given {{Selector}} is serializable, attempt to reuse it in {{TxnReference}}
rather than hard coding data conversion cases
- Separate current current {{LET}} statement from {{{}SelectStatement{}}},
likely as a new {{LetStatement}} that names a {{SelectStatement}}
- Explore unifying {{Operation}} and {{ReferenceOperation}}
- Include non-Row items of {{FilteredPartition}} in
{{TxnData#estimatedSizeOnHeap()}}
- Explore possibility of making {{Bound}} serializable and using it directly
in {{TxnCondition}}
- Change internal representation of {{TxnDataName}} to avoid {{String}} ->
{{ByteBuffer}} conversions
- Have {{{}TxnCondition{}}}/{{{}TxnUpdate{}}} support {{slice()}} to full take
advantage of partial state replication
- Update serialization logic to reflect CASSANDRA-18099
*Testing*
- Figure out the original intent of placeholder tests in
{{AccordIntegrationTest}} (ex. {{{}acceptInvalidationTest(){}}})
- -Remove hack in {{AccordConfigurationService}} (when we have Transactional
Metadata)-
- Verify concretely that we disable Guardrails.
- Audit the way we propagate timestamps through execution.
*Features*
- Full JSON support
- Final decision of whether we should support returning the result of an
{{{}IF{}}}/condition
-
[jira] [Updated] (CASSANDRA-18107) CEP-15: Multi-Partition Transaction CQL Support (Alpha -> v1)
[
https://issues.apache.org/jira/browse/CASSANDRA-18107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-18107:
Description:
With CASSANDRA-17719 complete, basic/alpha CQL support for Accord is now
available in the
[cep-15-accord|https://github.com/apache/cassandra/commits/cep-15-accord]
branch. There are, however, a number of features and enhancements that we would
still like to add before we make it available to users. Here is a summary of
those items, broadly categorized:
*Error Messages and UX*
- Fix the element/field names in result metadata to match the user query
- Better error messages
-- Append/subtracting to/from frozen list
-- attempts to use reference in WHERE clause
-- LET using a reserved word
*Domain Object Cleanup*
- Given {{Selector}} is serializable, attempt to reuse it in {{TxnReference}}
rather than hard coding data conversion cases
- Separate current current {{LET}} statement from {{{}SelectStatement{}}},
likely as a new {{LetStatement}} that names a {{SelectStatement}}
- Explore unifying {{Operation}} and {{ReferenceOperation}}
- Include non-Row items of {{FilteredPartition}} in
{{TxnData#estimatedSizeOnHeap()}}
- Explore possibility of making {{Bound}} serializable and using it directly
in {{TxnCondition}}
- Change internal representation of {{TxnDataName}} to avoid {{String}} ->
{{ByteBuffer}} conversions
- Have {{{}TxnCondition{}}}/{{{}TxnUpdate{}}} support {{slice()}} to full take
advantage of partial state replication
- Update serialization logic to reflect CASSANDRA-18099
*Testing*
- Figure out the original intent of placeholder tests in
{{AccordIntegrationTest}} (ex. {{{}acceptInvalidationTest(){}}})
- -Remove hack in {{AccordConfigurationService}} (when we have Transactional
Metadata)-
- Verify concretely that we disable Guardrails.
- Audit the way we propagate timestamps through execution.
*Features*
- Full JSON support
- Final decision of whether we should support returning the result of an
{{{}IF{}}}/condition
- Constant terms on the RHS of LET
- Support for having a reference on both LHS and RHS of {{IF}} predicates
- Support for {{{}CONTAINS{}}}, {{{}CONTAINS KEY{}}}, and {{IN}} (important
for CAS parity)
- Nested UDT support
- Mixed conditional and unconditional updates (should this be post-v1?)
- Arithmetic operations on references in {{{}INSERT{}}}/{{{}UPDATE{}}} (ex.
INSERT INTO ks.tbl1 (k, c, v) VALUES (0, 0, a.v + 1)
*Tooling*
- Eliminate {{nodetool createepochunsafe}} once transactional metadata is
available.
-- UPDATE: Removed now, but still in {{JMXGetterCheckTest}} and
accord_demo.txt
*Documentation*
- CQL language documentation and bump the CQL language specification version
- JavaDoc for all new statement classes
- Integrate {{demo.txt}} into broader documentation somewhere or remove
*Questions*
- How should txn statement parsing/preparation handle TTLs specified in
updates?
- At what level do we want to integrate tracing?
was:
With CASSANDRA-17719 complete, basic/alpha CQL support for Accord is now
available in the
[cep-15-accord|https://github.com/apache/cassandra/commits/cep-15-accord]
branch. There are, however, a number of features and enhancements that we would
still like to add before we make it available to users. Here is a summary of
those items, broadly categorized:
*Error Messages and UX*
- Fix the element/field names in result metadata to match the user query
- Better error messages
-- Append/subtracting to/from frozen list
-- attempts to use reference in WHERE clause
-- LET using a reserved word
*Domain Object Cleanup*
- Given {{Selector}} is serializable, attempt to reuse it in {{TxnReference}}
rather than hard coding data conversion cases
- Separate current current {{LET}} statement from {{{}SelectStatement{}}},
likely as a new {{LetStatement}} that names a {{SelectStatement}}
- Explore unifying {{Operation}} and {{ReferenceOperation}}
- Include non-Row items of {{FilteredPartition}} in
{{TxnData#estimatedSizeOnHeap()}}
- Explore possibility of making {{Bound}} serializable and using it directly
in {{TxnCondition}}
- Change internal representation of {{TxnDataName}} to avoid {{String}} ->
{{ByteBuffer}} conversions
- Have {{{}TxnCondition{}}}/{{{}TxnUpdate{}}} support {{slice()}} to full take
advantage of partial state replication
- Update serialization logic to reflect CASSANDRA-18099
*Testing*
- Figure out the original intent of placeholder tests in
{{AccordIntegrationTest}} (ex. {{{}acceptInvalidationTest(){}}})
- -Remove hack in {{AccordConfigurationService}} (when we have Transactional
Metadata)-
- Verify concretely that we disable Guardrails.
- Audit the way we propagate timestamps through execution.
*Features*
- Full JSON support
- Final decision of whether we should support returning the result of an
{{{}IF{}}}/condition
-
[jira] [Updated] (CASSANDRA-18107) CEP-15: Multi-Partition Transaction CQL Support (Alpha -> v1)
[
https://issues.apache.org/jira/browse/CASSANDRA-18107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-18107:
Description:
With CASSANDRA-17719 complete, basic/alpha CQL support for Accord is now
available in the
[cep-15-accord|https://github.com/apache/cassandra/commits/cep-15-accord]
branch. There are, however, a number of features and enhancements that we would
still like to add before we make it available to users. Here is a summary of
those items, broadly categorized:
*Error Messages and UX*
- Fix the element/field names in result metadata to match the user query
- Better error messages
-- Append/subtracting to/from frozen list
-- attempts to use reference in WHERE clause
-- LET using a reserved word
*Domain Object Cleanup*
- Given {{Selector}} is serializable, attempt to reuse it in {{TxnReference}}
rather than hard coding data conversion cases
- Separate current current {{LET}} statement from {{{}SelectStatement{}}},
likely as a new {{LetStatement}} that names a {{SelectStatement}}
- Explore unifying {{Operation}} and {{ReferenceOperation}}
- Include non-Row items of {{FilteredPartition}} in
{{TxnData#estimatedSizeOnHeap()}}
- Explore possibility of making {{Bound}} serializable and using it directly
in {{TxnCondition}}
- Change internal representation of {{TxnDataName}} to avoid {{String}} ->
{{ByteBuffer}} conversions
- Have {{{}TxnCondition{}}}/{{{}TxnUpdate{}}} support {{slice()}} to full take
advantage of partial state replication
- Update serialization logic to reflect CASSANDRA-18099
*Testing*
- Figure out the original intent of placeholder tests in
{{AccordIntegrationTest}} (ex. {{{}acceptInvalidationTest(){}}})
- -Remove hack in {{AccordConfigurationService}} (when we have Transactional
Metadata)-
- Verify concretely that we disable Guardrails.
- Audit the way we propagate timestamps through execution.
*Features*
- Full JSON support
- Final decision of whether we should support returning the result of an
{{{}IF{}}}/condition
- Constant terms on the RHS of LET
- Support for having a reference on both LHS and RHS of {{IF}} predicates
- Support for {{{}CONTAINS{}}}, {{{}CONTAINS KEY{}}}, and {{IN}} (important
for CAS parity)
- Nested UDT support
- Mixed conditional and unconditional updates (should this be post-v1?)
- Arithmetic operations on references in {{{}INSERT{}}}/{{{}UPDATE{}}} (ex.
INSERT INTO ks.tbl1 (k, c, v) VALUES (0, 0, a.v + 1)
*Tooling*
- Eliminate {{nodetool createepochunsafe}} once transactional metadata is
available.
*Documentation*
- CQL language documentation and bump the CQL language specification version
- JavaDoc for all new statement classes
- Integrate {{demo.txt}} into broader documentation somewhere or remove
*Questions*
- How should txn statement parsing/preparation handle TTLs specified in
updates?
- At what level do we want to integrate tracing?
was:
With CASSANDRA-17719 complete, basic/alpha CQL support for Accord is now
available in the
[cep-15-accord|https://github.com/apache/cassandra/commits/cep-15-accord]
branch. There are, however, a number of features and enhancements that we would
still like to add before we make it available to users. Here is a summary of
those items, broadly categorized:
*Error Messages and UX*
- Fix the element/field names in result metadata to match the user query
- Better error messages
-- Append/subtracting to/from frozen list
-- attempts to use reference in WHERE clause
-- LET using a reserved word
*Domain Object Cleanup*
- Given {{Selector}} is serializable, attempt to reuse it in {{TxnReference}}
rather than hard coding data conversion cases
- Separate current current {{LET}} statement from {{SelectStatement}}, likely
as a new {{LetStatement}} that names a {{SelectStatement}}
- Explore unifying {{Operation}} and {{ReferenceOperation}}
- Include non-Row items of {{FilteredPartition}} in
{{TxnData#estimatedSizeOnHeap()}}
- Explore possibility of making {{Bound}} serializable and using it directly in
{{TxnCondition}}
- Change internal representation of {{TxnDataName}} to avoid {{String}} ->
{{ByteBuffer}} conversions
- Have {{TxnCondition}}/{{TxnUpdate}} support {{slice()}} to full take
advantage of partial state replication
- Update serialization logic to reflect CASSANDRA-18099
*Testing*
- Figure out the original intent of placeholder tests in
{{AccordIntegrationTest}} (ex. {{acceptInvalidationTest()}})
- Remove hack in {{AccordConfigurationService}} (when we have Transactional
Metadata)
- Verify concretely that we disable Guardrails.
- Audit the way we propagate timestamps through execution.
*Features*
- Full JSON support
- Final decision of whether we should support returning the result of an
{{IF}}/condition
- Constant terms on the RHS of LET
- Support for having a reference on both LHS and RHS of {{IF}} predicates
- Support for
