[jira] [Updated] (CASSANDRA-18839) Catch SSLHandshakeExceptions exceptions
[
https://issues.apache.org/jira/browse/CASSANDRA-18839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-18839:
Reviewers: Caleb Rackliffe, Maxwell Guo (was: Maxwell Guo)
> 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: 3h 20m
> 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] [Updated] (CASSANDRA-19120) local consistencies may get timeout if blocking read repair is sending the read repair mutation to other DC
[ https://issues.apache.org/jira/browse/CASSANDRA-19120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-19120: -- Reviewers: Stefan Miklosovic, Stefan Miklosovic (was: Stefan Miklosovic) Stefan Miklosovic, Stefan Miklosovic (was: Stefan Miklosovic) Status: Review In Progress (was: Patch Available) > local consistencies may get timeout if blocking read repair is sending the > read repair mutation to other DC > > > Key: CASSANDRA-19120 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19120 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Repair >Reporter: Runtian Liu >Assignee: Runtian Liu >Priority: Normal > Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x > > Attachments: image-2023-11-29-15-26-08-056.png, signature.asc > > Time Spent: 10m > Remaining Estimate: 0h > > For a two DCs cluster setup. When a new node is being added to DC1, for > blocking read repair triggered by local_quorum in DC1, it will require to > send read repair mutation to an extra node(1)(2). The selector for read > repair may select *ANY* node that has not been contacted before(3) instead of > selecting the DC1 nodes. If a node from DC2 is selected, this will cause 100% > timeout because of the bug described below: > When we initialized the latch(4) for blocking read repair, the shouldBlockOn > function will only return true for local nodes(5), the blockFor value will be > reduced if a local node doesn't require repair(6). The blockFor is same as > the number of read repair mutation sent out. But when the coordinator node > receives the response from the target nodes, the latch only count down for > nodes in same DC(7). The latch will wait till timeout and the read request > will timeout. > This can be reproduced if you have a constant load on a 3 + 3 cluster when > adding a node. If you have someway to trigger blocking read repair(maybe by > adding load using stress tool). If you use local_quorum consistency with a > constant read after write load in the same DC that you are adding node. You > will see read timeout issue from time to time because of the bug described > above > > I think for read repair when selecting the extra node to do repair, we should > prefer local nodes than the nodes from other region. Also, we need to fix the > latch part so even if we send mutation to the nodes in other DC, we don't get > a timeout. > (1)[https://github.com/apache/cassandra/blob/cassandra-4.0.11/src/java/org/apache/cassandra/locator/ReplicaPlans.java#L455] > (2)[https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/ConsistencyLevel.java#L183] > (3)[https://github.com/apache/cassandra/blob/cassandra-4.0.11/src/java/org/apache/cassandra/locator/ReplicaPlans.java#L458] > (4)[https://github.com/apache/cassandra/blob/cassandra-4.0.11/src/java/org/apache/cassandra/service/reads/repair/BlockingPartitionRepair.java#L96] > (5)[https://github.com/apache/cassandra/blob/cassandra-4.0.11/src/java/org/apache/cassandra/service/reads/repair/BlockingPartitionRepair.java#L71] > (6)[https://github.com/apache/cassandra/blob/cassandra-4.0.11/src/java/org/apache/cassandra/service/reads/repair/BlockingPartitionRepair.java#L88] > (7)[https://github.com/apache/cassandra/blob/cassandra-4.0.11/src/java/org/apache/cassandra/service/reads/repair/BlockingPartitionRepair.java#L113] > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19120) local consistencies may get timeout if blocking read repair is sending the read repair mutation to other DC
[ https://issues.apache.org/jira/browse/CASSANDRA-19120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-19120: -- Test and Documentation Plan: ci Status: Patch Available (was: In Progress) > local consistencies may get timeout if blocking read repair is sending the > read repair mutation to other DC > > > Key: CASSANDRA-19120 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19120 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Repair >Reporter: Runtian Liu >Assignee: Runtian Liu >Priority: Normal > Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x > > Attachments: image-2023-11-29-15-26-08-056.png, signature.asc > > Time Spent: 10m > Remaining Estimate: 0h > > For a two DCs cluster setup. When a new node is being added to DC1, for > blocking read repair triggered by local_quorum in DC1, it will require to > send read repair mutation to an extra node(1)(2). The selector for read > repair may select *ANY* node that has not been contacted before(3) instead of > selecting the DC1 nodes. If a node from DC2 is selected, this will cause 100% > timeout because of the bug described below: > When we initialized the latch(4) for blocking read repair, the shouldBlockOn > function will only return true for local nodes(5), the blockFor value will be > reduced if a local node doesn't require repair(6). The blockFor is same as > the number of read repair mutation sent out. But when the coordinator node > receives the response from the target nodes, the latch only count down for > nodes in same DC(7). The latch will wait till timeout and the read request > will timeout. > This can be reproduced if you have a constant load on a 3 + 3 cluster when > adding a node. If you have someway to trigger blocking read repair(maybe by > adding load using stress tool). If you use local_quorum consistency with a > constant read after write load in the same DC that you are adding node. You > will see read timeout issue from time to time because of the bug described > above > > I think for read repair when selecting the extra node to do repair, we should > prefer local nodes than the nodes from other region. Also, we need to fix the > latch part so even if we send mutation to the nodes in other DC, we don't get > a timeout. > (1)[https://github.com/apache/cassandra/blob/cassandra-4.0.11/src/java/org/apache/cassandra/locator/ReplicaPlans.java#L455] > (2)[https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/ConsistencyLevel.java#L183] > (3)[https://github.com/apache/cassandra/blob/cassandra-4.0.11/src/java/org/apache/cassandra/locator/ReplicaPlans.java#L458] > (4)[https://github.com/apache/cassandra/blob/cassandra-4.0.11/src/java/org/apache/cassandra/service/reads/repair/BlockingPartitionRepair.java#L96] > (5)[https://github.com/apache/cassandra/blob/cassandra-4.0.11/src/java/org/apache/cassandra/service/reads/repair/BlockingPartitionRepair.java#L71] > (6)[https://github.com/apache/cassandra/blob/cassandra-4.0.11/src/java/org/apache/cassandra/service/reads/repair/BlockingPartitionRepair.java#L88] > (7)[https://github.com/apache/cassandra/blob/cassandra-4.0.11/src/java/org/apache/cassandra/service/reads/repair/BlockingPartitionRepair.java#L113] > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19187) nodetool assassinate may cause thread serialization for that node
[
https://issues.apache.org/jira/browse/CASSANDRA-19187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17803436#comment-17803436
]
Stefan Miklosovic commented on CASSANDRA-19187:
---
Do I get it right this is not ready for the commit then? I think until we
answer remaining questions about the flakiness etc we can't ship that ...
> nodetool assassinate may cause thread serialization for that node
> -
>
> Key: CASSANDRA-19187
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19187
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Membership
>Reporter: Runtian Liu
>Assignee: Runtian Liu
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0.x
>
>
> When assassinate an ip address that is not in the gossip map, a "corrupted"
> entry will be inserted into the gossip map.
> [(1)|https://github.com/apache/cassandra/blob/cassandra-4.0/src/java/org/apache/cassandra/gms/Gossiper.java#L810]
> For example, if we do "nodetool assassinate 10.1.1.1"
> we will get an entry like below by running "nodetool gossipinfo":
>
> {code:java}
> /10.1.1.1
> generation:1702006511
> heartbeat:
> STATUS:209516:LEFT,-8393921141401589197,1702265651923
> STATUS_WITH_PORT:209515:LEFT,-8393921141401589197,1702265651923
> TOKENS: not present {code}
>
> This entry in endpointStateMap will cause issue for
> [isUpgradingFromVersionLowerThan|https://github.com/apache/cassandra/blob/cassandra-4.0/src/java/org/apache/cassandra/gms/Gossiper.java#L2284]
> function. Because the
> [upgradeFromVersionSupplier|https://github.com/apache/cassandra/blob/cassandra-4.0/src/java/org/apache/cassandra/gms/Gossiper.java#L191]
> supplier will always set the
> [allHostsHaveKnownVersion|https://github.com/apache/cassandra/blob/cassandra-4.0/src/java/org/apache/cassandra/gms/Gossiper.java#L216]
> flag to false so no memoized value will be returned. The "get" function will
> always require a lock from this
> [line|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/utils/ExpiringMemoizingSupplier.java#L66].
> If application is using "fetchAll", the native-transport-requests thread will
> hit this
> [line|https://github.com/apache/cassandra/blob/cassandra-4.0/src/java/org/apache/cassandra/db/filter/ColumnFilter.java#L574].
> This means all the native-transport-requests thread is serialized, also, the
> lock is shared by GossipStage threads. It means if a node in a cluster with
> the corrupted gossip map is restart, the node will run into this problem.
> To fix the issue,
> # Why we want to add a dummy entry for nodetool assassinate if the endpoint
> is not in the map anymore. Should we do nothing or throw exception if the
> node is not in the gossip map anymore?
> # Before checking if a version is null, we should make sure the node is not
> a dead node. A decommissioned node, a left node should not be considered part
> of the cluster anymore when calculating "upgradeInProgressPossible"
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19187) nodetool assassinate may cause thread serialization for that node
[
https://issues.apache.org/jira/browse/CASSANDRA-19187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-19187:
--
Status: Patch Available (was: Ready to Commit)
> nodetool assassinate may cause thread serialization for that node
> -
>
> Key: CASSANDRA-19187
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19187
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Membership
>Reporter: Runtian Liu
>Assignee: Runtian Liu
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0.x
>
>
> When assassinate an ip address that is not in the gossip map, a "corrupted"
> entry will be inserted into the gossip map.
> [(1)|https://github.com/apache/cassandra/blob/cassandra-4.0/src/java/org/apache/cassandra/gms/Gossiper.java#L810]
> For example, if we do "nodetool assassinate 10.1.1.1"
> we will get an entry like below by running "nodetool gossipinfo":
>
> {code:java}
> /10.1.1.1
> generation:1702006511
> heartbeat:
> STATUS:209516:LEFT,-8393921141401589197,1702265651923
> STATUS_WITH_PORT:209515:LEFT,-8393921141401589197,1702265651923
> TOKENS: not present {code}
>
> This entry in endpointStateMap will cause issue for
> [isUpgradingFromVersionLowerThan|https://github.com/apache/cassandra/blob/cassandra-4.0/src/java/org/apache/cassandra/gms/Gossiper.java#L2284]
> function. Because the
> [upgradeFromVersionSupplier|https://github.com/apache/cassandra/blob/cassandra-4.0/src/java/org/apache/cassandra/gms/Gossiper.java#L191]
> supplier will always set the
> [allHostsHaveKnownVersion|https://github.com/apache/cassandra/blob/cassandra-4.0/src/java/org/apache/cassandra/gms/Gossiper.java#L216]
> flag to false so no memoized value will be returned. The "get" function will
> always require a lock from this
> [line|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/utils/ExpiringMemoizingSupplier.java#L66].
> If application is using "fetchAll", the native-transport-requests thread will
> hit this
> [line|https://github.com/apache/cassandra/blob/cassandra-4.0/src/java/org/apache/cassandra/db/filter/ColumnFilter.java#L574].
> This means all the native-transport-requests thread is serialized, also, the
> lock is shared by GossipStage threads. It means if a node in a cluster with
> the corrupted gossip map is restart, the node will run into this problem.
> To fix the issue,
> # Why we want to add a dummy entry for nodetool assassinate if the endpoint
> is not in the map anymore. Should we do nothing or throw exception if the
> node is not in the gossip map anymore?
> # Before checking if a version is null, we should make sure the node is not
> a dead node. A decommissioned node, a left node should not be considered part
> of the cluster anymore when calculating "upgradeInProgressPossible"
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18939) Creating a SASI index after creating an SAI index breaks secondary index queries
[
https://issues.apache.org/jira/browse/CASSANDRA-18939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17803434#comment-17803434
]
Stefan Miklosovic edited comment on CASSANDRA-18939 at 1/5/24 7:25 AM:
---
Nothing out of ordinary, I created CASSANDRA-19250 that fails all the time in
trunk.
There is also e.g. CASSANDRA-19097 happening in 5.0
was (Author: smiklosovic):
Nothing out of ordinary, I created CASSANDRA-19250 that fails all the time in
trunk.
> Creating a SASI index after creating an SAI index breaks secondary index
> queries
>
>
> Key: CASSANDRA-18939
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18939
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/2i Index
>Reporter: Jon Haddad
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> In the 5.0 branch, HEAD is e45c1092f91edd63591f562b2120ea6a5fd3edd5, I was
> able to break secondary indexes by doing the following:
> {code}
> cqlsh -e "create KEYSPACE test WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': 1};"
> cqlsh -e "create table test.blah (id int primary key, val text);"
> cqlsh -e "create INDEX on test.blah (val) using 'sai';"
> bin/nodetool flush
> ❯ cqlsh -e "SELECT * from test.blah WHERE val = 'something';"
> id | val
> +-
> (0 rows)
> cqlsh -e "create custom INDEX on test.blah (val) using
> 'org.apache.cassandra.index.sasi.SASIIndex';"
> Warnings :
> SASI indexes are experimental and are not recommended for production use.
> cqlsh -e "SELECT * from test.blah WHERE val = 'something';"
> :1:ReadFailure: Error from server: code=1300 [Replica(s) failed to
> execute read] message="Operation failed - received 0 responses and 1
> failures: UNKNOWN from localhost/127.0.0.1:7000" info={'consistency': 'ONE',
> 'required_responses': 1, 'received_responses': 0, 'failures': 1,
> 'error_code_map': {'127.0.0.1': '0x'}}
> {code}
> Server throws an exception:
> {code}
> ERROR [ReadStage-2] 2023-10-18 12:09:42,391 JVMStabilityInspector.java:70 -
> Exception in thread Thread[ReadStage-2,10,SharedPool]
> java.lang.RuntimeException: java.lang.ClassCastException: class
> org.apache.cassandra.index.sai.StorageAttachedIndex cannot be cast to class
> org.apache.cassandra.index.sasi.SASIIndex
> (org.apache.cassandra.index.sai.StorageAttachedIndex and
> org.apache.cassandra.index.sasi.SASIIndex are in unnamed module of loader
> 'app')
> at
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2585)
> at
> org.apache.cassandra.concurrent.ExecutionFailure$2.run(ExecutionFailure.java:163)
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:143)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:829)
> Caused by: java.lang.ClassCastException: class
> org.apache.cassandra.index.sai.StorageAttachedIndex cannot be cast to class
> org.apache.cassandra.index.sasi.SASIIndex
> (org.apache.cassandra.index.sai.StorageAttachedIndex and
> org.apache.cassandra.index.sasi.SASIIndex are in unnamed module of loader
> 'app')
> at
> org.apache.cassandra.index.sasi.plan.QueryController.getIndex(QueryController.java:96)
> at
> org.apache.cassandra.index.sasi.plan.Operation.analyzeGroup(Operation.java:282)
> at
> org.apache.cassandra.index.sasi.plan.Operation$Builder.complete(Operation.java:433)
> at
> org.apache.cassandra.index.sasi.plan.SASIIndexSearcher.analyze(SASIIndexSearcher.java:65)
> at
> org.apache.cassandra.index.sasi.plan.SASIIndexSearcher.search(SASIIndexSearcher.java:77)
> at
> org.apache.cassandra.db.ReadCommand.executeLocally(ReadCommand.java:425)
> at
> org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:2184)
> at org.apache.cassandra.service
> {code}
> Dropping the SASI index restores correct behavior.
--
This message was sent by Atlassian Jira
(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-18939) Creating a SASI index after creating an SAI index breaks secondary index queries
[
https://issues.apache.org/jira/browse/CASSANDRA-18939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-18939:
--
Status: Ready to Commit (was: Review In Progress)
> Creating a SASI index after creating an SAI index breaks secondary index
> queries
>
>
> Key: CASSANDRA-18939
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18939
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/2i Index
>Reporter: Jon Haddad
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> In the 5.0 branch, HEAD is e45c1092f91edd63591f562b2120ea6a5fd3edd5, I was
> able to break secondary indexes by doing the following:
> {code}
> cqlsh -e "create KEYSPACE test WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': 1};"
> cqlsh -e "create table test.blah (id int primary key, val text);"
> cqlsh -e "create INDEX on test.blah (val) using 'sai';"
> bin/nodetool flush
> ❯ cqlsh -e "SELECT * from test.blah WHERE val = 'something';"
> id | val
> +-
> (0 rows)
> cqlsh -e "create custom INDEX on test.blah (val) using
> 'org.apache.cassandra.index.sasi.SASIIndex';"
> Warnings :
> SASI indexes are experimental and are not recommended for production use.
> cqlsh -e "SELECT * from test.blah WHERE val = 'something';"
> :1:ReadFailure: Error from server: code=1300 [Replica(s) failed to
> execute read] message="Operation failed - received 0 responses and 1
> failures: UNKNOWN from localhost/127.0.0.1:7000" info={'consistency': 'ONE',
> 'required_responses': 1, 'received_responses': 0, 'failures': 1,
> 'error_code_map': {'127.0.0.1': '0x'}}
> {code}
> Server throws an exception:
> {code}
> ERROR [ReadStage-2] 2023-10-18 12:09:42,391 JVMStabilityInspector.java:70 -
> Exception in thread Thread[ReadStage-2,10,SharedPool]
> java.lang.RuntimeException: java.lang.ClassCastException: class
> org.apache.cassandra.index.sai.StorageAttachedIndex cannot be cast to class
> org.apache.cassandra.index.sasi.SASIIndex
> (org.apache.cassandra.index.sai.StorageAttachedIndex and
> org.apache.cassandra.index.sasi.SASIIndex are in unnamed module of loader
> 'app')
> at
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2585)
> at
> org.apache.cassandra.concurrent.ExecutionFailure$2.run(ExecutionFailure.java:163)
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:143)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:829)
> Caused by: java.lang.ClassCastException: class
> org.apache.cassandra.index.sai.StorageAttachedIndex cannot be cast to class
> org.apache.cassandra.index.sasi.SASIIndex
> (org.apache.cassandra.index.sai.StorageAttachedIndex and
> org.apache.cassandra.index.sasi.SASIIndex are in unnamed module of loader
> 'app')
> at
> org.apache.cassandra.index.sasi.plan.QueryController.getIndex(QueryController.java:96)
> at
> org.apache.cassandra.index.sasi.plan.Operation.analyzeGroup(Operation.java:282)
> at
> org.apache.cassandra.index.sasi.plan.Operation$Builder.complete(Operation.java:433)
> at
> org.apache.cassandra.index.sasi.plan.SASIIndexSearcher.analyze(SASIIndexSearcher.java:65)
> at
> org.apache.cassandra.index.sasi.plan.SASIIndexSearcher.search(SASIIndexSearcher.java:77)
> at
> org.apache.cassandra.db.ReadCommand.executeLocally(ReadCommand.java:425)
> at
> org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:2184)
> at org.apache.cassandra.service
> {code}
> Dropping the SASI index restores correct behavior.
--
This message was sent by Atlassian Jira
(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-18939) Creating a SASI index after creating an SAI index breaks secondary index queries
[
https://issues.apache.org/jira/browse/CASSANDRA-18939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17803434#comment-17803434
]
Stefan Miklosovic edited comment on CASSANDRA-18939 at 1/5/24 7:23 AM:
---
Nothing out of ordinary, I created CASSANDRA-19250 that fails all the time in
trunk.
was (Author: smiklosovic):
Noting out of ordinary, I created CASSANDRA-19250 that fails all the time in
trunk.
> Creating a SASI index after creating an SAI index breaks secondary index
> queries
>
>
> Key: CASSANDRA-18939
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18939
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/2i Index
>Reporter: Jon Haddad
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> In the 5.0 branch, HEAD is e45c1092f91edd63591f562b2120ea6a5fd3edd5, I was
> able to break secondary indexes by doing the following:
> {code}
> cqlsh -e "create KEYSPACE test WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': 1};"
> cqlsh -e "create table test.blah (id int primary key, val text);"
> cqlsh -e "create INDEX on test.blah (val) using 'sai';"
> bin/nodetool flush
> ❯ cqlsh -e "SELECT * from test.blah WHERE val = 'something';"
> id | val
> +-
> (0 rows)
> cqlsh -e "create custom INDEX on test.blah (val) using
> 'org.apache.cassandra.index.sasi.SASIIndex';"
> Warnings :
> SASI indexes are experimental and are not recommended for production use.
> cqlsh -e "SELECT * from test.blah WHERE val = 'something';"
> :1:ReadFailure: Error from server: code=1300 [Replica(s) failed to
> execute read] message="Operation failed - received 0 responses and 1
> failures: UNKNOWN from localhost/127.0.0.1:7000" info={'consistency': 'ONE',
> 'required_responses': 1, 'received_responses': 0, 'failures': 1,
> 'error_code_map': {'127.0.0.1': '0x'}}
> {code}
> Server throws an exception:
> {code}
> ERROR [ReadStage-2] 2023-10-18 12:09:42,391 JVMStabilityInspector.java:70 -
> Exception in thread Thread[ReadStage-2,10,SharedPool]
> java.lang.RuntimeException: java.lang.ClassCastException: class
> org.apache.cassandra.index.sai.StorageAttachedIndex cannot be cast to class
> org.apache.cassandra.index.sasi.SASIIndex
> (org.apache.cassandra.index.sai.StorageAttachedIndex and
> org.apache.cassandra.index.sasi.SASIIndex are in unnamed module of loader
> 'app')
> at
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2585)
> at
> org.apache.cassandra.concurrent.ExecutionFailure$2.run(ExecutionFailure.java:163)
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:143)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:829)
> Caused by: java.lang.ClassCastException: class
> org.apache.cassandra.index.sai.StorageAttachedIndex cannot be cast to class
> org.apache.cassandra.index.sasi.SASIIndex
> (org.apache.cassandra.index.sai.StorageAttachedIndex and
> org.apache.cassandra.index.sasi.SASIIndex are in unnamed module of loader
> 'app')
> at
> org.apache.cassandra.index.sasi.plan.QueryController.getIndex(QueryController.java:96)
> at
> org.apache.cassandra.index.sasi.plan.Operation.analyzeGroup(Operation.java:282)
> at
> org.apache.cassandra.index.sasi.plan.Operation$Builder.complete(Operation.java:433)
> at
> org.apache.cassandra.index.sasi.plan.SASIIndexSearcher.analyze(SASIIndexSearcher.java:65)
> at
> org.apache.cassandra.index.sasi.plan.SASIIndexSearcher.search(SASIIndexSearcher.java:77)
> at
> org.apache.cassandra.db.ReadCommand.executeLocally(ReadCommand.java:425)
> at
> org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:2184)
> at org.apache.cassandra.service
> {code}
> Dropping the SASI index restores correct behavior.
--
This message was sent by Atlassian Jira
(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-18939) Creating a SASI index after creating an SAI index breaks secondary index queries
[
https://issues.apache.org/jira/browse/CASSANDRA-18939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-18939:
--
Reviewers: Andres de la Peña, Caleb Rackliffe, Stefan Miklosovic (was:
Caleb Rackliffe)
Status: Review In Progress (was: Patch Available)
> Creating a SASI index after creating an SAI index breaks secondary index
> queries
>
>
> Key: CASSANDRA-18939
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18939
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/2i Index
>Reporter: Jon Haddad
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> In the 5.0 branch, HEAD is e45c1092f91edd63591f562b2120ea6a5fd3edd5, I was
> able to break secondary indexes by doing the following:
> {code}
> cqlsh -e "create KEYSPACE test WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': 1};"
> cqlsh -e "create table test.blah (id int primary key, val text);"
> cqlsh -e "create INDEX on test.blah (val) using 'sai';"
> bin/nodetool flush
> ❯ cqlsh -e "SELECT * from test.blah WHERE val = 'something';"
> id | val
> +-
> (0 rows)
> cqlsh -e "create custom INDEX on test.blah (val) using
> 'org.apache.cassandra.index.sasi.SASIIndex';"
> Warnings :
> SASI indexes are experimental and are not recommended for production use.
> cqlsh -e "SELECT * from test.blah WHERE val = 'something';"
> :1:ReadFailure: Error from server: code=1300 [Replica(s) failed to
> execute read] message="Operation failed - received 0 responses and 1
> failures: UNKNOWN from localhost/127.0.0.1:7000" info={'consistency': 'ONE',
> 'required_responses': 1, 'received_responses': 0, 'failures': 1,
> 'error_code_map': {'127.0.0.1': '0x'}}
> {code}
> Server throws an exception:
> {code}
> ERROR [ReadStage-2] 2023-10-18 12:09:42,391 JVMStabilityInspector.java:70 -
> Exception in thread Thread[ReadStage-2,10,SharedPool]
> java.lang.RuntimeException: java.lang.ClassCastException: class
> org.apache.cassandra.index.sai.StorageAttachedIndex cannot be cast to class
> org.apache.cassandra.index.sasi.SASIIndex
> (org.apache.cassandra.index.sai.StorageAttachedIndex and
> org.apache.cassandra.index.sasi.SASIIndex are in unnamed module of loader
> 'app')
> at
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2585)
> at
> org.apache.cassandra.concurrent.ExecutionFailure$2.run(ExecutionFailure.java:163)
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:143)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:829)
> Caused by: java.lang.ClassCastException: class
> org.apache.cassandra.index.sai.StorageAttachedIndex cannot be cast to class
> org.apache.cassandra.index.sasi.SASIIndex
> (org.apache.cassandra.index.sai.StorageAttachedIndex and
> org.apache.cassandra.index.sasi.SASIIndex are in unnamed module of loader
> 'app')
> at
> org.apache.cassandra.index.sasi.plan.QueryController.getIndex(QueryController.java:96)
> at
> org.apache.cassandra.index.sasi.plan.Operation.analyzeGroup(Operation.java:282)
> at
> org.apache.cassandra.index.sasi.plan.Operation$Builder.complete(Operation.java:433)
> at
> org.apache.cassandra.index.sasi.plan.SASIIndexSearcher.analyze(SASIIndexSearcher.java:65)
> at
> org.apache.cassandra.index.sasi.plan.SASIIndexSearcher.search(SASIIndexSearcher.java:77)
> at
> org.apache.cassandra.db.ReadCommand.executeLocally(ReadCommand.java:425)
> at
> org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:2184)
> at org.apache.cassandra.service
> {code}
> Dropping the SASI index restores correct behavior.
--
This message was sent by Atlassian Jira
(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-19250) Test failure: org.apache.cassandra.fuzz.ring.ClusterMetadataUpgradeHarryTest#simpleUpgradeTest
[
https://issues.apache.org/jira/browse/CASSANDRA-19250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-19250:
--
Component/s: Test/fuzz
> Test failure:
> org.apache.cassandra.fuzz.ring.ClusterMetadataUpgradeHarryTest#simpleUpgradeTest
> --
>
> Key: CASSANDRA-19250
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19250
> Project: Cassandra
> Issue Type: Bug
> Components: Test/fuzz
>Reporter: Stefan Miklosovic
>Priority: Normal
>
> This fails consistently in trunk. It seems to be introduced since Harry is
> in-tree.
> {code:java}
> java.lang.NullPointerException: Cannot invoke "java.util.List.stream()"
> because the return value of "java.util.Map.get(Object)" is null
> at
> org.apache.cassandra.distributed.shared.Versions.getLatest(Versions.java:127)
> at
> org.apache.cassandra.distributed.upgrade.UpgradeTestBase$TestCase.upgradesTo(UpgradeTestBase.java:219)
> at
> org.apache.cassandra.distributed.upgrade.UpgradeTestBase$TestCase.upgradesToCurrentFrom(UpgradeTestBase.java:204)
> at
> org.apache.cassandra.fuzz.ring.ClusterMetadataUpgradeHarryTest.simpleUpgradeTest(ClusterMetadataUpgradeHarryTest.java:77)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18939) Creating a SASI index after creating an SAI index breaks secondary index queries
[
https://issues.apache.org/jira/browse/CASSANDRA-18939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17803434#comment-17803434
]
Stefan Miklosovic commented on CASSANDRA-18939:
---
Noting out of ordinary, I created CASSANDRA-19250 that fails all the time in
trunk.
> Creating a SASI index after creating an SAI index breaks secondary index
> queries
>
>
> Key: CASSANDRA-18939
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18939
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/2i Index
>Reporter: Jon Haddad
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> In the 5.0 branch, HEAD is e45c1092f91edd63591f562b2120ea6a5fd3edd5, I was
> able to break secondary indexes by doing the following:
> {code}
> cqlsh -e "create KEYSPACE test WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': 1};"
> cqlsh -e "create table test.blah (id int primary key, val text);"
> cqlsh -e "create INDEX on test.blah (val) using 'sai';"
> bin/nodetool flush
> ❯ cqlsh -e "SELECT * from test.blah WHERE val = 'something';"
> id | val
> +-
> (0 rows)
> cqlsh -e "create custom INDEX on test.blah (val) using
> 'org.apache.cassandra.index.sasi.SASIIndex';"
> Warnings :
> SASI indexes are experimental and are not recommended for production use.
> cqlsh -e "SELECT * from test.blah WHERE val = 'something';"
> :1:ReadFailure: Error from server: code=1300 [Replica(s) failed to
> execute read] message="Operation failed - received 0 responses and 1
> failures: UNKNOWN from localhost/127.0.0.1:7000" info={'consistency': 'ONE',
> 'required_responses': 1, 'received_responses': 0, 'failures': 1,
> 'error_code_map': {'127.0.0.1': '0x'}}
> {code}
> Server throws an exception:
> {code}
> ERROR [ReadStage-2] 2023-10-18 12:09:42,391 JVMStabilityInspector.java:70 -
> Exception in thread Thread[ReadStage-2,10,SharedPool]
> java.lang.RuntimeException: java.lang.ClassCastException: class
> org.apache.cassandra.index.sai.StorageAttachedIndex cannot be cast to class
> org.apache.cassandra.index.sasi.SASIIndex
> (org.apache.cassandra.index.sai.StorageAttachedIndex and
> org.apache.cassandra.index.sasi.SASIIndex are in unnamed module of loader
> 'app')
> at
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2585)
> at
> org.apache.cassandra.concurrent.ExecutionFailure$2.run(ExecutionFailure.java:163)
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:143)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:829)
> Caused by: java.lang.ClassCastException: class
> org.apache.cassandra.index.sai.StorageAttachedIndex cannot be cast to class
> org.apache.cassandra.index.sasi.SASIIndex
> (org.apache.cassandra.index.sai.StorageAttachedIndex and
> org.apache.cassandra.index.sasi.SASIIndex are in unnamed module of loader
> 'app')
> at
> org.apache.cassandra.index.sasi.plan.QueryController.getIndex(QueryController.java:96)
> at
> org.apache.cassandra.index.sasi.plan.Operation.analyzeGroup(Operation.java:282)
> at
> org.apache.cassandra.index.sasi.plan.Operation$Builder.complete(Operation.java:433)
> at
> org.apache.cassandra.index.sasi.plan.SASIIndexSearcher.analyze(SASIIndexSearcher.java:65)
> at
> org.apache.cassandra.index.sasi.plan.SASIIndexSearcher.search(SASIIndexSearcher.java:77)
> at
> org.apache.cassandra.db.ReadCommand.executeLocally(ReadCommand.java:425)
> at
> org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:2184)
> at org.apache.cassandra.service
> {code}
> Dropping the SASI index restores correct behavior.
--
This message was sent by Atlassian Jira
(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-19250) Test failure: org.apache.cassandra.fuzz.ring.ClusterMetadataUpgradeHarryTest#simpleUpgradeTest
Stefan Miklosovic created CASSANDRA-19250:
-
Summary: Test failure:
org.apache.cassandra.fuzz.ring.ClusterMetadataUpgradeHarryTest#simpleUpgradeTest
Key: CASSANDRA-19250
URL: https://issues.apache.org/jira/browse/CASSANDRA-19250
Project: Cassandra
Issue Type: Bug
Reporter: Stefan Miklosovic
This fails consistently in trunk. It seems to be introduced since Harry is
in-tree.
{code:java}
java.lang.NullPointerException: Cannot invoke "java.util.List.stream()" because
the return value of "java.util.Map.get(Object)" is null
at
org.apache.cassandra.distributed.shared.Versions.getLatest(Versions.java:127)
at
org.apache.cassandra.distributed.upgrade.UpgradeTestBase$TestCase.upgradesTo(UpgradeTestBase.java:219)
at
org.apache.cassandra.distributed.upgrade.UpgradeTestBase$TestCase.upgradesToCurrentFrom(UpgradeTestBase.java:204)
at
org.apache.cassandra.fuzz.ring.ClusterMetadataUpgradeHarryTest.simpleUpgradeTest(ClusterMetadataUpgradeHarryTest.java:77)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19206) ./bin/cqlsh breaks with an python version 3.12.1
[ https://issues.apache.org/jira/browse/CASSANDRA-19206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17803404#comment-17803404 ] Gautam G commented on CASSANDRA-19206: -- Thank you for the info > ./bin/cqlsh breaks with an python version 3.12.1 > > > Key: CASSANDRA-19206 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19206 > Project: Cassandra > Issue Type: Bug >Reporter: Gautam G >Priority: Normal > Attachments: image-2023-12-18-01-38-47-424.png, > image-2023-12-18-01-39-33-839.png, image-2023-12-18-01-40-38-974.png > > > Inside cassandra directory, on running ./bin/cqlsh gives ModuleNotFoundError > when run using python 3.12.1. > ./bin/cqlsh works well for python versions like 3.9.18. > > The below image shows the error that occured while using python 3.12.1 > !image-2023-12-18-01-39-33-839.png! > > The below image shows how it should normally work, it was ran on python 3.9.18 > !image-2023-12-18-01-40-38-974.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] [Comment Edited] (CASSANDRA-19018) An SAI-specific mechanism to ensure consistency isn't violated for multi-column (i.e. AND) queries at CL > ONE
[
https://issues.apache.org/jira/browse/CASSANDRA-19018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17803386#comment-17803386
]
Caleb Rackliffe edited comment on CASSANDRA-19018 at 1/5/24 3:00 AM:
-
In terms of scope, the biggest thing I'm worried about right now is the case
where we have a non-empty {{postIndexQueryFilter()}} which needs to be applied.
Right now, I think it may only be safe to apply it when "strict" filtering is
allowed.
Also, I think we have a bug where RFP doesn't apply non-index-based filters
during its post-filtering if we have even a non-tokenizing analyzer.
[~adelapena] I may need to catch up w/ you on these if/when you have a minute.
I think I'm going to have to expand the test matrix to look at the post-filter
vs. indexed expressions issue at least...
Part of what brought these things to my attention was [playing
around|https://github.com/maedhroz/cassandra/pull/14] w/ a fix based on the
patch for this Jira for CASSANDRA-19007 for basic filtering.
was (Author: maedhroz):
In terms of scope, the biggest thing I'm worried about right now is the case
where we have a non-empty {{postIndexQueryFilter()}} which needs to be applied.
Right now, I think it may only be safe to apply it when "strict" filtering is
allowed.
Also, I think we have a bug where RFP doesn't alloy non-index filters during
its post-filtering if we have even a non-tokenizing analyzer.
[~adelapena] I may need to catch up w/ you on these if/when you have a minute.
I think I'm going to have to expand the test matrix to look at the post-filter
vs. indexed expressions issue at least...
Part of what brought these things to my attention was playing around w/ a fix
based on the patch for this Jira for 19007 here:
https://github.com/maedhroz/cassandra/pull/14
> An SAI-specific mechanism to ensure consistency isn't violated for
> multi-column (i.e. AND) queries at CL > ONE
> --
>
> Key: CASSANDRA-19018
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19018
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination, Feature/SAI
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
> Time Spent: 3h 10m
> Remaining Estimate: 0h
>
> CASSANDRA-19007 is going to be where we add a guardrail around
> filtering/index queries that use intersection/AND over partially updated
> non-key columns. (ex. Restricting one clustering column and one normal column
> does not cause a consistency problem, as primary keys cannot be partially
> updated.) This issue exists to attempt to fix this specifically for SAI in
> 5.0.x, as Accord will (last I checked) not be available until the 5.1 release.
> The SAI-specific version of the originally reported issue is this:
> {noformat}
> try (Cluster cluster = init(Cluster.build(2).withConfig(config ->
> config.with(GOSSIP).with(NETWORK)).start()))
> {
> cluster.schemaChange(withKeyspace("CREATE TABLE %s.t (k int
> PRIMARY KEY, a int, b int)"));
> cluster.schemaChange(withKeyspace("CREATE INDEX ON %s.t(a) USING
> 'sai'"));
> cluster.schemaChange(withKeyspace("CREATE INDEX ON %s.t(b) USING
> 'sai'"));
> // insert a split row
> cluster.get(1).executeInternal(withKeyspace("INSERT INTO %s.t(k,
> a) VALUES (0, 1)"));
> cluster.get(2).executeInternal(withKeyspace("INSERT INTO %s.t(k,
> b) VALUES (0, 2)"));
> // Uncomment this line and test succeeds w/ partial writes
> completed...
> //cluster.get(1).nodetoolResult("repair",
> KEYSPACE).asserts().success();
> String select = withKeyspace("SELECT * FROM %s.t WHERE a = 1 AND
> b = 2");
> Object[][] initialRows = cluster.coordinator(1).execute(select,
> ConsistencyLevel.ALL);
> assertRows(initialRows, row(0, 1, 2)); // not found!!
> }
> {noformat}
> To make a long story short, the local SAI indexes are hiding local partial
> matches from the coordinator that would combine there to form full matches.
> Simple non-index filtering queries also suffer from this problem, but they
> hide the partial matches in a different way. I'll outline a possible solution
> for this in the comments that takes advantage of replica filtering protection
> and the repaired/unrepaired datasets...and attempts to minimize the amount of
> extra row data sent to the coordinator.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail:
[jira] [Comment Edited] (CASSANDRA-19018) An SAI-specific mechanism to ensure consistency isn't violated for multi-column (i.e. AND) queries at CL > ONE
[
https://issues.apache.org/jira/browse/CASSANDRA-19018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17803386#comment-17803386
]
Caleb Rackliffe edited comment on CASSANDRA-19018 at 1/5/24 2:58 AM:
-
In terms of scope, the biggest thing I'm worried about right now is the case
where we have a non-empty {{postIndexQueryFilter()}} which needs to be applied.
Right now, I think it may only be safe to apply it when "strict" filtering is
allowed.
Also, I think we have a bug where RFP doesn't alloy non-index filters during
its post-filtering if we have even a non-tokenizing analyzer.
[~adelapena] I may need to catch up w/ you on these if/when you have a minute.
I think I'm going to have to expand the test matrix to look at the post-filter
vs. indexed expressions issue at least...
Part of what brought these things to my attention was playing around w/ a fix
based on the patch for this Jira for 19007 here:
https://github.com/maedhroz/cassandra/pull/14
was (Author: maedhroz):
In terms of scope, the biggest thing I'm worried about right now is the case
where we have a non-empty {{postIndexQueryFilter()}} which needs to be applied.
Right now, I think it may only be safe to apply it when "strict" filtering is
allowed.
Also, I think we have a bug where RFP doesn't alloy non-index filters during
its post-filtering if we have even a non-tokenizing analyzer.
[~adelapena] I may need to catch up w/ you on these if/when you have a minute.
I think I'm going to have to expand the test matrix to look at the post-filter
vs. indexed expressions issue at least...
> An SAI-specific mechanism to ensure consistency isn't violated for
> multi-column (i.e. AND) queries at CL > ONE
> --
>
> Key: CASSANDRA-19018
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19018
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination, Feature/SAI
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
> Time Spent: 3h 10m
> Remaining Estimate: 0h
>
> CASSANDRA-19007 is going to be where we add a guardrail around
> filtering/index queries that use intersection/AND over partially updated
> non-key columns. (ex. Restricting one clustering column and one normal column
> does not cause a consistency problem, as primary keys cannot be partially
> updated.) This issue exists to attempt to fix this specifically for SAI in
> 5.0.x, as Accord will (last I checked) not be available until the 5.1 release.
> The SAI-specific version of the originally reported issue is this:
> {noformat}
> try (Cluster cluster = init(Cluster.build(2).withConfig(config ->
> config.with(GOSSIP).with(NETWORK)).start()))
> {
> cluster.schemaChange(withKeyspace("CREATE TABLE %s.t (k int
> PRIMARY KEY, a int, b int)"));
> cluster.schemaChange(withKeyspace("CREATE INDEX ON %s.t(a) USING
> 'sai'"));
> cluster.schemaChange(withKeyspace("CREATE INDEX ON %s.t(b) USING
> 'sai'"));
> // insert a split row
> cluster.get(1).executeInternal(withKeyspace("INSERT INTO %s.t(k,
> a) VALUES (0, 1)"));
> cluster.get(2).executeInternal(withKeyspace("INSERT INTO %s.t(k,
> b) VALUES (0, 2)"));
> // Uncomment this line and test succeeds w/ partial writes
> completed...
> //cluster.get(1).nodetoolResult("repair",
> KEYSPACE).asserts().success();
> String select = withKeyspace("SELECT * FROM %s.t WHERE a = 1 AND
> b = 2");
> Object[][] initialRows = cluster.coordinator(1).execute(select,
> ConsistencyLevel.ALL);
> assertRows(initialRows, row(0, 1, 2)); // not found!!
> }
> {noformat}
> To make a long story short, the local SAI indexes are hiding local partial
> matches from the coordinator that would combine there to form full matches.
> Simple non-index filtering queries also suffer from this problem, but they
> hide the partial matches in a different way. I'll outline a possible solution
> for this in the comments that takes advantage of replica filtering protection
> and the repaired/unrepaired datasets...and attempts to minimize the amount of
> extra row data sent to the coordinator.
--
This message was sent by Atlassian Jira
(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-19018) An SAI-specific mechanism to ensure consistency isn't violated for multi-column (i.e. AND) queries at CL > ONE
[
https://issues.apache.org/jira/browse/CASSANDRA-19018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17803386#comment-17803386
]
Caleb Rackliffe commented on CASSANDRA-19018:
-
In terms of scope, the biggest thing I'm worried about right now is the case
where we have a non-empty {{postIndexQueryFilter()}} which needs to be applied.
Right now, I think it may only be safe to apply it when "strict" filtering is
allowed.
Also, I think we have a bug where RFP doesn't alloy non-index filters during
its post-filtering if we have even a non-tokenizing analyzer.
[~adelapena] I may need to catch up w/ you on these if/when you have a minute.
I think I'm going to have to expand the test matrix to look at the post-filter
vs. indexed expressions issue at least...
> An SAI-specific mechanism to ensure consistency isn't violated for
> multi-column (i.e. AND) queries at CL > ONE
> --
>
> Key: CASSANDRA-19018
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19018
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination, Feature/SAI
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
> Time Spent: 3h 10m
> Remaining Estimate: 0h
>
> CASSANDRA-19007 is going to be where we add a guardrail around
> filtering/index queries that use intersection/AND over partially updated
> non-key columns. (ex. Restricting one clustering column and one normal column
> does not cause a consistency problem, as primary keys cannot be partially
> updated.) This issue exists to attempt to fix this specifically for SAI in
> 5.0.x, as Accord will (last I checked) not be available until the 5.1 release.
> The SAI-specific version of the originally reported issue is this:
> {noformat}
> try (Cluster cluster = init(Cluster.build(2).withConfig(config ->
> config.with(GOSSIP).with(NETWORK)).start()))
> {
> cluster.schemaChange(withKeyspace("CREATE TABLE %s.t (k int
> PRIMARY KEY, a int, b int)"));
> cluster.schemaChange(withKeyspace("CREATE INDEX ON %s.t(a) USING
> 'sai'"));
> cluster.schemaChange(withKeyspace("CREATE INDEX ON %s.t(b) USING
> 'sai'"));
> // insert a split row
> cluster.get(1).executeInternal(withKeyspace("INSERT INTO %s.t(k,
> a) VALUES (0, 1)"));
> cluster.get(2).executeInternal(withKeyspace("INSERT INTO %s.t(k,
> b) VALUES (0, 2)"));
> // Uncomment this line and test succeeds w/ partial writes
> completed...
> //cluster.get(1).nodetoolResult("repair",
> KEYSPACE).asserts().success();
> String select = withKeyspace("SELECT * FROM %s.t WHERE a = 1 AND
> b = 2");
> Object[][] initialRows = cluster.coordinator(1).execute(select,
> ConsistencyLevel.ALL);
> assertRows(initialRows, row(0, 1, 2)); // not found!!
> }
> {noformat}
> To make a long story short, the local SAI indexes are hiding local partial
> matches from the coordinator that would combine there to form full matches.
> Simple non-index filtering queries also suffer from this problem, but they
> hide the partial matches in a different way. I'll outline a possible solution
> for this in the comments that takes advantage of replica filtering protection
> and the repaired/unrepaired datasets...and attempts to minimize the amount of
> extra row data sent to the coordinator.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19007) Queries with multi-column replica-side filtering can miss rows
[
https://issues.apache.org/jira/browse/CASSANDRA-19007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17803370#comment-17803370
]
Caleb Rackliffe commented on CASSANDRA-19007:
-
For anyone watching this but not CASSANDRA-19018, I've posted a patch there
that should resolve the issue (albeit without what seem like unavoidable
performance tradeoffs) for SAI specifically (although it contains a couple
components that we might be able to leverage to fix filtering more generally).
> Queries with multi-column replica-side filtering can miss rows
> --
>
> Key: CASSANDRA-19007
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19007
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination
>Reporter: Andres de la Peña
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 5.0.x, 5.x
>
>
> {{SELECT}} queries with multi-column replica-side filtering can miss rows if
> the filtered columns are spread across out-of-sync replicas. This dtest
> reproduces the issue:
> {code:java}
> @Test
> public void testMultiColumnReplicaSideFiltering() throws IOException
> {
> try (Cluster cluster = init(Cluster.build().withNodes(2).start()))
> {
> cluster.schemaChange(withKeyspace("CREATE TABLE %s.t (k int PRIMARY
> KEY, a int, b int)"));
> // insert a split row
> cluster.get(1).executeInternal(withKeyspace("INSERT INTO %s.t(k, a)
> VALUES (0, 1)"));
> cluster.get(2).executeInternal(withKeyspace("INSERT INTO %s.t(k, b)
> VALUES (0, 2)"));
> String select = withKeyspace("SELECT * FROM %s.t WHERE a = 1 AND b =
> 2 ALLOW FILTERING");
> Object[][] initialRows = cluster.coordinator(1).execute(select, ALL);
> assertRows(initialRows, row(0, 1, 2)); // not found!!
> }
> }
> {code}
> This edge case affects queries using {{ALLOW FILTERING}} or any index
> implementation.
> It affects all branches since multi-column replica-side filtering queries
> were introduced, long before 3.0.
> The protection mechanism added by CASSANDRA-8272/8273 won't deal with this
> case, since it only solves single-column conflicts where stale rows could
> resurrect. This bug however doesn't resurrect data, it can only miss rows
> while the replicas are out-of-sync.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19248) "nodetool bootstrap resume" starts unnecessary streaming session on joining node
[
https://issues.apache.org/jira/browse/CASSANDRA-19248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paulo Motta updated CASSANDRA-19248:
Description:
Calling {{nodetool boostrap resume}} triggers a new bootstrap streaming session
on a joining node, even if there's a bootstrap streaming session currently
running.
Each time this command is called, a new bootstrap streaming session is started,
causing the same data to be needlessly streamed from peers.
It should only be possible to call {{nodetool bootstrap resume}} if a previous
bootstrap attempt has failed.
An example of multiple invocations of {{nodetool bootstrap resume}} in a
joining node is shown below:
{noformat}
$ nodetool netstats
Mode: JOINING
Bootstrap a1cf3bf0-ab3a-11ee-9fcf-5746a7aee9ca
/A.B.C.D
Receiving 13 files, 14302312660 bytes total. Already received 2 files,
52389676 bytes total
ks1/tbl1 80/80 bytes(100%) received from idx:0/A.B.C.D
ks2/tbl2 471/471 bytes(100%) received from idx:0/A.B.C.D
/E.F.G.H
/I.J.K.L
Bootstrap 7f1e7000-ab3d-11ee-9fcf-5746a7aee9ca
/A.B.C.D
Receiving 13 files, 14302312660 bytes total. Already received 0 files,
0 bytes total
/E.F.G.H
/I.J.K.L
Bootstrap 9ca42500-ab3a-11ee-9fcf-5746a7aee9ca
/A.B.C.D
/E.F.G.H
Receiving 13 files, 14302312660 bytes total. Already received 2 files,
104838752 bytes total
ks1/tbl1 80/80 bytes(100%) received from idx:0/E.F.G.H
ks2/tbl2 471/471 bytes(100%) received from idx:0/E.F.G.H
/I.J.K.L {noformat}
was:
Calling {{nodetool boostrap resume}} triggers a new bootstrap streaming session
on a joining node, even if there's a bootstrap streaming session currently
running.
Each time this command is called, a new bootstrap streaming session is started,
causing the same data to be needlessly streamed from peers.
It should only be possible to call {{nodetool bootstrap resume}} if a previous
bootstrap attempt has failed.
An example of multiple invocations of {{nodetool bootstrap resume}} in a
joining node is shown below:
{noformat}
$ nodetool netstats
Mode: JOINING
Bootstrap a1cf3bf0-ab3a-11ee-9fcf-5746a7aee9ca
/A.B.C.D
Receiving 13 files, 14302312660 bytes total. Already received 2 files,
52389676 bytes total
ks1/tbl1 80/80 bytes(100%) received from idx:0/10.34.194.220
ks2/tbl2 471/471 bytes(100%) received from idx:0/10.34.194.220
/E.F.G.H
/I.J.K.L
Bootstrap 7f1e7000-ab3d-11ee-9fcf-5746a7aee9ca
/A.B.C.D
Receiving 13 files, 14302312660 bytes total. Already received 0 files,
0 bytes total
/E.F.G.H
/I.J.K.L
Bootstrap 9ca42500-ab3a-11ee-9fcf-5746a7aee9ca
/A.B.C.D
/E.F.G.H
Receiving 13 files, 14302312660 bytes total. Already received 2 files,
104838752 bytes total
ks1/tbl1 80/80 bytes(100%) received from idx:0/10.34.194.220
ks2/tbl2 471/471 bytes(100%) received from idx:0/10.34.194.220
/I.J.K.L {noformat}
> "nodetool bootstrap resume" starts unnecessary streaming session on joining
> node
>
>
> Key: CASSANDRA-19248
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19248
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Membership
>Reporter: Paulo Motta
>Priority: Normal
> Labels: lhf
>
> Calling {{nodetool boostrap resume}} triggers a new bootstrap streaming
> session on a joining node, even if there's a bootstrap streaming session
> currently running.
> Each time this command is called, a new bootstrap streaming session is
> started, causing the same data to be needlessly streamed from peers.
> It should only be possible to call {{nodetool bootstrap resume}} if a
> previous bootstrap attempt has failed.
> An example of multiple invocations of {{nodetool bootstrap resume}} in a
> joining node is shown below:
> {noformat}
> $ nodetool netstats
> Mode: JOINING
> Bootstrap a1cf3bf0-ab3a-11ee-9fcf-5746a7aee9ca
> /A.B.C.D
> Receiving 13 files, 14302312660 bytes total. Already received 2
> files, 52389676 bytes total
> ks1/tbl1 80/80 bytes(100%) received from idx:0/A.B.C.D
> ks2/tbl2 471/471 bytes(100%) received from idx:0/A.B.C.D
> /E.F.G.H
> /I.J.K.L
> Bootstrap 7f1e7000-ab3d-11ee-9fcf-5746a7aee9ca
> /A.B.C.D
> Receiving 13 files, 14302312660 bytes total. Already received 0
> files, 0 bytes total
> /E.F.G.H
> /I.J.K.L
> Bootstrap 9ca42500-ab3a-11ee-9fcf-5746a7aee9ca
> /A.B.C.D
> /E.F.G.H
> Receiving 13 files, 14302312660 bytes total. Already received 2
> files, 104838752 bytes total
> ks1/tbl1 80/80 bytes(100%) received from idx:0/E.F.G.H
> ks2/tbl2 471/471 bytes(100%) received from
[jira] [Commented] (CASSANDRA-19018) An SAI-specific mechanism to ensure consistency isn't violated for multi-column (i.e. AND) queries at CL > ONE
[
https://issues.apache.org/jira/browse/CASSANDRA-19018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17803363#comment-17803363
]
Caleb Rackliffe commented on CASSANDRA-19018:
-
I have J11 CI running as well, and I'll post those results when I have them...
> An SAI-specific mechanism to ensure consistency isn't violated for
> multi-column (i.e. AND) queries at CL > ONE
> --
>
> Key: CASSANDRA-19018
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19018
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination, Feature/SAI
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> CASSANDRA-19007 is going to be where we add a guardrail around
> filtering/index queries that use intersection/AND over partially updated
> non-key columns. (ex. Restricting one clustering column and one normal column
> does not cause a consistency problem, as primary keys cannot be partially
> updated.) This issue exists to attempt to fix this specifically for SAI in
> 5.0.x, as Accord will (last I checked) not be available until the 5.1 release.
> The SAI-specific version of the originally reported issue is this:
> {noformat}
> try (Cluster cluster = init(Cluster.build(2).withConfig(config ->
> config.with(GOSSIP).with(NETWORK)).start()))
> {
> cluster.schemaChange(withKeyspace("CREATE TABLE %s.t (k int
> PRIMARY KEY, a int, b int)"));
> cluster.schemaChange(withKeyspace("CREATE INDEX ON %s.t(a) USING
> 'sai'"));
> cluster.schemaChange(withKeyspace("CREATE INDEX ON %s.t(b) USING
> 'sai'"));
> // insert a split row
> cluster.get(1).executeInternal(withKeyspace("INSERT INTO %s.t(k,
> a) VALUES (0, 1)"));
> cluster.get(2).executeInternal(withKeyspace("INSERT INTO %s.t(k,
> b) VALUES (0, 2)"));
> // Uncomment this line and test succeeds w/ partial writes
> completed...
> //cluster.get(1).nodetoolResult("repair",
> KEYSPACE).asserts().success();
> String select = withKeyspace("SELECT * FROM %s.t WHERE a = 1 AND
> b = 2");
> Object[][] initialRows = cluster.coordinator(1).execute(select,
> ConsistencyLevel.ALL);
> assertRows(initialRows, row(0, 1, 2)); // not found!!
> }
> {noformat}
> To make a long story short, the local SAI indexes are hiding local partial
> matches from the coordinator that would combine there to form full matches.
> Simple non-index filtering queries also suffer from this problem, but they
> hide the partial matches in a different way. I'll outline a possible solution
> for this in the comments that takes advantage of replica filtering protection
> and the repaired/unrepaired datasets...and attempts to minimize the amount of
> extra row data sent to the coordinator.
--
This message was sent by Atlassian Jira
(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-19018) An SAI-specific mechanism to ensure consistency isn't violated for multi-column (i.e. AND) queries at CL > ONE
[
https://issues.apache.org/jira/browse/CASSANDRA-19018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-19018:
Test and Documentation Plan: New matrix of almost 200 tests that covers
both RFP and the newly discovered consistency problems.
Status: Patch Available (was: In Progress)
The [5.0 patch|https://github.com/apache/cassandra/pull/2935] is now ready for
review, and I anticipate very little if any change porting forward to trunk.
I've made comments inline in the PR where there might still be some discussion,
but I tried to address the holes in the test matrix [~adelapena] had kindly
pointed out.
> An SAI-specific mechanism to ensure consistency isn't violated for
> multi-column (i.e. AND) queries at CL > ONE
> --
>
> Key: CASSANDRA-19018
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19018
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination, Feature/SAI
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> CASSANDRA-19007 is going to be where we add a guardrail around
> filtering/index queries that use intersection/AND over partially updated
> non-key columns. (ex. Restricting one clustering column and one normal column
> does not cause a consistency problem, as primary keys cannot be partially
> updated.) This issue exists to attempt to fix this specifically for SAI in
> 5.0.x, as Accord will (last I checked) not be available until the 5.1 release.
> The SAI-specific version of the originally reported issue is this:
> {noformat}
> try (Cluster cluster = init(Cluster.build(2).withConfig(config ->
> config.with(GOSSIP).with(NETWORK)).start()))
> {
> cluster.schemaChange(withKeyspace("CREATE TABLE %s.t (k int
> PRIMARY KEY, a int, b int)"));
> cluster.schemaChange(withKeyspace("CREATE INDEX ON %s.t(a) USING
> 'sai'"));
> cluster.schemaChange(withKeyspace("CREATE INDEX ON %s.t(b) USING
> 'sai'"));
> // insert a split row
> cluster.get(1).executeInternal(withKeyspace("INSERT INTO %s.t(k,
> a) VALUES (0, 1)"));
> cluster.get(2).executeInternal(withKeyspace("INSERT INTO %s.t(k,
> b) VALUES (0, 2)"));
> // Uncomment this line and test succeeds w/ partial writes
> completed...
> //cluster.get(1).nodetoolResult("repair",
> KEYSPACE).asserts().success();
> String select = withKeyspace("SELECT * FROM %s.t WHERE a = 1 AND
> b = 2");
> Object[][] initialRows = cluster.coordinator(1).execute(select,
> ConsistencyLevel.ALL);
> assertRows(initialRows, row(0, 1, 2)); // not found!!
> }
> {noformat}
> To make a long story short, the local SAI indexes are hiding local partial
> matches from the coordinator that would combine there to form full matches.
> Simple non-index filtering queries also suffer from this problem, but they
> hide the partial matches in a different way. I'll outline a possible solution
> for this in the comments that takes advantage of replica filtering protection
> and the repaired/unrepaired datasets...and attempts to minimize the amount of
> extra row data sent to the coordinator.
--
This message was sent by Atlassian Jira
(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-18990) Fix SAI docs issues
[ https://issues.apache.org/jira/browse/CASSANDRA-18990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17803359#comment-17803359 ] Lorina Poland commented on CASSANDRA-18990: --- Checked for the error in the comment above, and I believe it was already fixed. Need to do the other tasks. > Fix SAI docs issues > --- > > Key: CASSANDRA-18990 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18990 > Project: Cassandra > Issue Type: Task >Reporter: Lorina Poland >Assignee: Lorina Poland >Priority: Normal > > # Change CREATE CUSTOM INDEX syntax to CREATE INDEX in SAI quickstart. > # Consolidate SAI code examples. -- This message was sent by Atlassian Jira (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-19206) ./bin/cqlsh breaks with an python version 3.12.1
[ https://issues.apache.org/jira/browse/CASSANDRA-19206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17803349#comment-17803349 ] Bret McGuire commented on CASSANDRA-19206: -- In ASF Slack the user indicated that they were able to get past the six issue by updating six (although a huge +1 to [~bschoeni] 's suggestion above to upgrade the Python driver version used by cqlsh). They then reported the following errors: ModuleNotFoundError: No module named '[cassandra.io|http://cassandra.io/].libevwrapper' ModuleNotFoundError: No module named 'asyncore' I mentioned this on ASF Slack but I'll repeat it here for discoverability. Python 3.12 completely removed asyncore in favor of asyncio; that's why you see the second error mentioned above. The asyncore reactor is also the default reactor for the Python driver so if you're using Python 3.12 you must specify one of the alternate reactors for your app, and due to some other changes in Python 3.12 this winds up leading to more verbose errors like the ones cited above. These were largely addressed in [PYTHON-1366|https://datastax-oss.atlassian.net/browse/PYTHON-1366] so the new Python driver should behave better here. You will still need to provide an alternate reactor, however. > ./bin/cqlsh breaks with an python version 3.12.1 > > > Key: CASSANDRA-19206 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19206 > Project: Cassandra > Issue Type: Bug >Reporter: Gautam G >Priority: Normal > Attachments: image-2023-12-18-01-38-47-424.png, > image-2023-12-18-01-39-33-839.png, image-2023-12-18-01-40-38-974.png > > > Inside cassandra directory, on running ./bin/cqlsh gives ModuleNotFoundError > when run using python 3.12.1. > ./bin/cqlsh works well for python versions like 3.9.18. > > The below image shows the error that occured while using python 3.12.1 > !image-2023-12-18-01-39-33-839.png! > > The below image shows how it should normally work, it was ran on python 3.9.18 > !image-2023-12-18-01-40-38-974.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] [Created] (CASSANDRA-19249) Fix some errors in Vector Search
Lorina Poland created CASSANDRA-19249: - Summary: Fix some errors in Vector Search Key: CASSANDRA-19249 URL: https://issues.apache.org/jira/browse/CASSANDRA-19249 Project: Cassandra Issue Type: Bug Components: Documentation Reporter: Lorina Poland Assignee: Lorina Poland Fix vector type description: Vector types in 5.0 support all data types. But vector indexing only support floats. Subtle diff. Astra only supports float. Add some additional embeddings 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-19248) "nodetool bootstrap resume" starts unnecessary streaming session on joining node
[
https://issues.apache.org/jira/browse/CASSANDRA-19248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paulo Motta updated CASSANDRA-19248:
Since Version: 2.2.0 beta 1
Labels: lhf (was: )
> "nodetool bootstrap resume" starts unnecessary streaming session on joining
> node
>
>
> Key: CASSANDRA-19248
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19248
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Membership
>Reporter: Paulo Motta
>Priority: Normal
> Labels: lhf
>
> Calling {{nodetool boostrap resume}} triggers a new bootstrap streaming
> session on a joining node, even if there's a bootstrap streaming session
> currently running.
> Each time this command is called, a new bootstrap streaming session is
> started, causing the same data to be needlessly streamed from peers.
> It should only be possible to call {{nodetool bootstrap resume}} if a
> previous bootstrap attempt has failed.
> An example of multiple invocations of {{nodetool bootstrap resume}} in a
> joining node is shown below:
> {noformat}
> $ nodetool netstats
> Mode: JOINING
> Bootstrap a1cf3bf0-ab3a-11ee-9fcf-5746a7aee9ca
> /A.B.C.D
> Receiving 13 files, 14302312660 bytes total. Already received 2
> files, 52389676 bytes total
> ks1/tbl1 80/80 bytes(100%) received from idx:0/10.34.194.220
> ks2/tbl2 471/471 bytes(100%) received from idx:0/10.34.194.220
> /E.F.G.H
> /I.J.K.L
> Bootstrap 7f1e7000-ab3d-11ee-9fcf-5746a7aee9ca
> /A.B.C.D
> Receiving 13 files, 14302312660 bytes total. Already received 0
> files, 0 bytes total
> /E.F.G.H
> /I.J.K.L
> Bootstrap 9ca42500-ab3a-11ee-9fcf-5746a7aee9ca
> /A.B.C.D
> /E.F.G.H
> Receiving 13 files, 14302312660 bytes total. Already received 2
> files, 104838752 bytes total
> ks1/tbl1 80/80 bytes(100%) received from idx:0/10.34.194.220
> ks2/tbl2 471/471 bytes(100%) received from idx:0/10.34.194.220
> /I.J.K.L {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19248) "nodetool bootstrap resume" starts unnecessary streaming session on joining node
[
https://issues.apache.org/jira/browse/CASSANDRA-19248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paulo Motta updated CASSANDRA-19248:
Bug Category: Parent values: Correctness(12982)Level 1 values: API /
Semantic Implementation(12988)
Complexity: Low Hanging Fruit
Component/s: Cluster/Membership
Discovered By: User Report
Severity: Low
Status: Open (was: Triage Needed)
> "nodetool bootstrap resume" starts unnecessary streaming session on joining
> node
>
>
> Key: CASSANDRA-19248
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19248
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Membership
>Reporter: Paulo Motta
>Priority: Normal
>
> Calling {{nodetool boostrap resume}} triggers a new bootstrap streaming
> session on a joining node, even if there's a bootstrap streaming session
> currently running.
> Each time this command is called, a new bootstrap streaming session is
> started, causing the same data to be needlessly streamed from peers.
> It should only be possible to call {{nodetool bootstrap resume}} if a
> previous bootstrap attempt has failed.
> An example of multiple invocations of {{nodetool bootstrap resume}} in a
> joining node is shown below:
> {noformat}
> $ nodetool netstats
> Mode: JOINING
> Bootstrap a1cf3bf0-ab3a-11ee-9fcf-5746a7aee9ca
> /A.B.C.D
> Receiving 13 files, 14302312660 bytes total. Already received 2
> files, 52389676 bytes total
> ks1/tbl1 80/80 bytes(100%) received from idx:0/10.34.194.220
> ks2/tbl2 471/471 bytes(100%) received from idx:0/10.34.194.220
> /E.F.G.H
> /I.J.K.L
> Bootstrap 7f1e7000-ab3d-11ee-9fcf-5746a7aee9ca
> /A.B.C.D
> Receiving 13 files, 14302312660 bytes total. Already received 0
> files, 0 bytes total
> /E.F.G.H
> /I.J.K.L
> Bootstrap 9ca42500-ab3a-11ee-9fcf-5746a7aee9ca
> /A.B.C.D
> /E.F.G.H
> Receiving 13 files, 14302312660 bytes total. Already received 2
> files, 104838752 bytes total
> ks1/tbl1 80/80 bytes(100%) received from idx:0/10.34.194.220
> ks2/tbl2 471/471 bytes(100%) received from idx:0/10.34.194.220
> /I.J.K.L {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-19248) "nodetool bootstrap resume" starts unnecessary streaming session on joining node
Paulo Motta created CASSANDRA-19248:
---
Summary: "nodetool bootstrap resume" starts unnecessary streaming
session on joining node
Key: CASSANDRA-19248
URL: https://issues.apache.org/jira/browse/CASSANDRA-19248
Project: Cassandra
Issue Type: Bug
Reporter: Paulo Motta
Calling {{nodetool boostrap resume}} triggers a new bootstrap streaming session
on a joining node, even if there's a bootstrap streaming session currently
running.
Each time this command is called, a new bootstrap streaming session is started,
causing the same data to be needlessly streamed from peers.
It should only be possible to call {{nodetool bootstrap resume}} if a previous
bootstrap attempt has failed.
An example of multiple invocations of {{nodetool bootstrap resume}} in a
joining node is shown below:
{noformat}
$ nodetool netstats
Mode: JOINING
Bootstrap a1cf3bf0-ab3a-11ee-9fcf-5746a7aee9ca
/A.B.C.D
Receiving 13 files, 14302312660 bytes total. Already received 2 files,
52389676 bytes total
ks1/tbl1 80/80 bytes(100%) received from idx:0/10.34.194.220
ks2/tbl2 471/471 bytes(100%) received from idx:0/10.34.194.220
/E.F.G.H
/I.J.K.L
Bootstrap 7f1e7000-ab3d-11ee-9fcf-5746a7aee9ca
/A.B.C.D
Receiving 13 files, 14302312660 bytes total. Already received 0 files,
0 bytes total
/E.F.G.H
/I.J.K.L
Bootstrap 9ca42500-ab3a-11ee-9fcf-5746a7aee9ca
/A.B.C.D
/E.F.G.H
Receiving 13 files, 14302312660 bytes total. Already received 2 files,
104838752 bytes total
ks1/tbl1 80/80 bytes(100%) received from idx:0/10.34.194.220
ks2/tbl2 471/471 bytes(100%) received from idx:0/10.34.194.220
/I.J.K.L {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18824) Backport CASSANDRA-16418: Cleanup behaviour during node decommission caused missing replica
[ https://issues.apache.org/jira/browse/CASSANDRA-18824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17803329#comment-17803329 ] Brandon Williams commented on CASSANDRA-18824: -- There was an unused import in 5.0 I removed. Unfortunately however, it looks like cleanupDuringDecommissionTest is [flaky|https://app.circleci.com/pipelines/github/driftx/cassandra/1442/workflows/d06f2dcf-1382-4d3a-8b02-0b40934c6329/jobs/69573/tests]. > Backport CASSANDRA-16418: Cleanup behaviour during node decommission caused > missing replica > --- > > Key: CASSANDRA-18824 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18824 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Bootstrap and Decommission >Reporter: Szymon Miezal >Assignee: Szymon Miezal >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.0.x, 5.x > > Time Spent: 1h > Remaining Estimate: 0h > > Node decommission triggers data transfer to other nodes. While this transfer > is in progress, > receiving nodes temporarily hold token ranges in a pending state. However, > the cleanup process currently doesn't consider these pending ranges when > calculating token ownership. > As a consequence, data that is already stored in sstables gets inadvertently > cleaned up. > STR: > * Create two node cluster > * Create keyspace with RF=1 > * Insert sample data (assert data is available when querying both nodes) > * Start decommission process of node 1 > * Start running cleanup in a loop on node 2 until decommission on node 1 > finishes > * Verify of all rows are in the cluster - it will fail as the previous step > removed some of the rows > It seems that the cleanup process does not take into account the pending > ranges, it uses only the local ranges - > [https://github.com/apache/cassandra/blob/caad2f24f95b494d05c6b5d86a8d25fbee58d7c2/src/java/org/apache/cassandra/db/compaction/CompactionManager.java#L466]. > There are two solutions to the problem. > One would be to change the cleanup process in a way that it start taking > pending ranges into account. Even thought it might sound tempting at first it > will require involving changes and a lot of testing effort. > Alternatively we could interrupt/prevent the cleanup process from running > when any pending range on a node is detected. That sounds like a reasonable > alternative to the problem and something that is relatively easy to implement. > The bug has been already fixed in 4.x with CASSANDRA-16418, the goal of this > ticket is to backport it to 3.x. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19146) Upgrade owasp to 9.0.x
[
https://issues.apache.org/jira/browse/CASSANDRA-19146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-19146:
---
Fix Version/s: 3.0.30
3.11.17
4.0.12
4.1.4
5.1
(was: 3.0.x)
(was: 3.11.x)
(was: 5.x)
(was: 4.0.x)
(was: 4.1.x)
> Upgrade owasp to 9.0.x
> --
>
> Key: CASSANDRA-19146
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19146
> Project: Cassandra
> Issue Type: Bug
> Components: Build
>Reporter: Brandon Williams
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 3.0.30, 3.11.17, 4.0.12, 4.1.4, 5.0-beta2, 5.0, 5.1
>
> Attachments: signature.asc
>
>
> From https://github.com/jeremylong/DependencyCheck :
> {quote}
> Upgrading to 9.0.0 or later is mandatory; previous versions of
> dependency-check utilize the NVD data feeds which will be deprecated on Dec
> 15th, 2023.
> {quote}
--
This message was sent by Atlassian Jira
(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-18598) Use trie for literal index building
[ https://issues.apache.org/jira/browse/CASSANDRA-18598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-18598: --- Source Control Link: https://github.com/apache/cassandra/commit/3b05051f8678c28bc9d93a89123c68f8d0b93b7b (was: https://github.com/apache/cassandra/pull/2989) > Use trie for literal index building > --- > > Key: CASSANDRA-18598 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18598 > Project: Cassandra > Issue Type: Improvement > Components: Feature/SAI >Reporter: Mike Adamson >Assignee: Mike Adamson >Priority: Normal > Fix For: 5.0-beta2, 5.0, 5.1 > > Time Spent: 7h 50m > Remaining Estimate: 0h > > The BlockBalancedTreeRamBuffer for numerics indexes uses a trie for building > indexes in memory before flushing to disk. The RAMStringIndexer for literal > indexes does not do this. It uses lucene classes to build the in memory index > before flushing. > We should combine both of the in-memory index builders and have them both use > the trie. -- This message was sent by Atlassian Jira (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-18902) Test failure: org.apache.cassandra.distributed.test.MigrationCoordinatorTest.explicitEndpointIgnore
[ https://issues.apache.org/jira/browse/CASSANDRA-18902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-18902: --- Fix Version/s: 4.1.4 5.1 (was: 5.x) (was: 4.1.x) > Test failure: > org.apache.cassandra.distributed.test.MigrationCoordinatorTest.explicitEndpointIgnore > --- > > Key: CASSANDRA-18902 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18902 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest/java >Reporter: Jacek Lewandowski >Assignee: Jacek Lewandowski >Priority: Normal > Fix For: 4.1.4, 5.0-beta2, 5.0, 5.1 > > > Repeated run from `cassandra-4.1` > [https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/941/workflows/46fc6cb7-135e-4862-b9d3-6996c0993de8] > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18598) Use trie for literal index building
[ https://issues.apache.org/jira/browse/CASSANDRA-18598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-18598: --- Fix Version/s: 5.0 5.1 > Use trie for literal index building > --- > > Key: CASSANDRA-18598 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18598 > Project: Cassandra > Issue Type: Improvement > Components: Feature/SAI >Reporter: Mike Adamson >Assignee: Mike Adamson >Priority: Normal > Fix For: 5.0-beta2, 5.0, 5.1 > > Time Spent: 7h 50m > Remaining Estimate: 0h > > The BlockBalancedTreeRamBuffer for numerics indexes uses a trie for building > indexes in memory before flushing to disk. The RAMStringIndexer for literal > indexes does not do this. It uses lucene classes to build the in memory index > before flushing. > We should combine both of the in-memory index builders and have them both use > the trie. -- This message was sent by Atlassian Jira (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-19084) Test Failure: IndexStreamingFailureTest.testAvailabilityAfterFailed*EntireFileStreaming
[
https://issues.apache.org/jira/browse/CASSANDRA-19084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-19084:
---
Fix Version/s: 5.1
(was: 5.x)
> Test Failure:
> IndexStreamingFailureTest.testAvailabilityAfterFailed*EntireFileStreaming
> ---
>
> Key: CASSANDRA-19084
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19084
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/SAI
>Reporter: Michael Semb Wever
>Assignee: Mike Adamson
>Priority: Normal
> Fix For: 5.0-beta2, 5.0, 5.1
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Flakies
> https://app.circleci.com/pipelines/github/adelapena/cassandra/3329/workflows/f2124edd-fa0e-4bc5-ab03-ddfb886bf015/jobs/93097/tests
> {noformat}
> java.lang.NullPointerException
> at
> java.base/sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:133)
> at
> java.base/sun.net.www.protocol.jar.JarURLConnection.getInputStream(JarURLConnection.java:155)
> at java.base/java.net.URL.openStream(URL.java:1165)
> at
> java.base/java.lang.ClassLoader.getResourceAsStream(ClassLoader.java:1739)
> at
> net.bytebuddy.dynamic.ClassFileLocator$ForClassLoader.locate(ClassFileLocator.java:453)
> at
> net.bytebuddy.dynamic.ClassFileLocator$ForClassLoader.locate(ClassFileLocator.java:434)
> at
> net.bytebuddy.dynamic.scaffold.TypeWriter$Default$ForInlining.create(TypeWriter.java:4009)
> at
> net.bytebuddy.dynamic.scaffold.TypeWriter$Default.make(TypeWriter.java:2224)
> at
> net.bytebuddy.dynamic.DynamicType$Builder$AbstractBase$UsingTypeWriter.make(DynamicType.java:4050)
> at
> net.bytebuddy.dynamic.DynamicType$Builder$AbstractBase.make(DynamicType.java:3734)
> at
> net.bytebuddy.dynamic.DynamicType$Builder$AbstractBase$Delegator.make(DynamicType.java:3986)
> at
> org.apache.cassandra.distributed.test.sai.IndexStreamingFailureTest$ByteBuddyHelper.installErrors(IndexStreamingFailureTest.java:154)
> at
> org.apache.cassandra.distributed.shared.AbstractBuilder$1.initialise(AbstractBuilder.java:360)
> at
> org.apache.cassandra.distributed.impl.AbstractCluster$Wrapper.newInstance(AbstractCluster.java:312)
> at
> org.apache.cassandra.distributed.impl.AbstractCluster$Wrapper.delegateForStartup(AbstractCluster.java:292)
> at
> org.apache.cassandra.distributed.impl.AbstractCluster$Wrapper.startup(AbstractCluster.java:410)
> at
> org.apache.cassandra.distributed.impl.AbstractCluster$Wrapper.startup(AbstractCluster.java:383)
> at
> org.apache.cassandra.distributed.test.sai.IndexStreamingFailureTest.testAvailabilityAfterStreaming(IndexStreamingFailureTest.java:123)
> at
> org.apache.cassandra.distributed.test.sai.IndexStreamingFailureTest.testAvailabilityAfterFailedNonEntireFileStreaming(IndexStreamingFailureTest.java:79)
> {noformat}
> {noformat}
> java.lang.IllegalStateException: Can't use shutdown instances, delegate is
> null
> at
> org.apache.cassandra.distributed.impl.AbstractCluster$Wrapper.delegate(AbstractCluster.java:285)
> at
> org.apache.cassandra.distributed.impl.DelegatingInvokableInstance.transfer(DelegatingInvokableInstance.java:49)
> at
> org.apache.cassandra.distributed.api.IInvokableInstance.runsOnInstance(IInvokableInstance.java:45)
> at
> org.apache.cassandra.distributed.api.IInvokableInstance.runOnInstance(IInvokableInstance.java:46)
> at
> org.apache.cassandra.distributed.test.sai.IndexStreamingFailureTest.testAvailabilityAfterFailedEntireFileStreaming(IndexStreamingFailureTest.java:85)
> {noformat}
> https://ci-cassandra.apache.org/job/Cassandra-5.0/106/testReport/org.apache.cassandra.distributed.test.sai/IndexStreamingFailureTest/testAvailabilityAfterFailedNonEntireFileStreaming__jdk11_x86_64_novnode/
> {noformat}
> java.lang.RuntimeException: The class file could not be written
> at
> net.bytebuddy.dynamic.scaffold.TypeWriter$Default$ForInlining.create(TypeWriter.java:4021)
> at
> net.bytebuddy.dynamic.scaffold.TypeWriter$Default.make(TypeWriter.java:2224)
> at
> net.bytebuddy.dynamic.DynamicType$Builder$AbstractBase$UsingTypeWriter.make(DynamicType.java:4050)
> at
> net.bytebuddy.dynamic.DynamicType$Builder$AbstractBase.make(DynamicType.java:3734)
> at
> net.bytebuddy.dynamic.DynamicType$Builder$AbstractBase$Delegator.make(DynamicType.java:3986)
> at
> org.apache.cassandra.distributed.test.sai.IndexStreamingFailureTest$ByteBuddyHelper.installErrors(IndexStreamingFailureTest.java:155)
> at
> org.apache.cassandra.distributed.shared.AbstractBuilder$1.initialise(AbstractBuilder.java:360)
> at
[jira] [Updated] (CASSANDRA-18944) Test failure: org.apache.cassandra.simulator.test.ShortPaxosSimulationTest.simulationTest
[
https://issues.apache.org/jira/browse/CASSANDRA-18944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-18944:
---
Fix Version/s: 5.1
(was: 5.x)
> Test failure:
> org.apache.cassandra.simulator.test.ShortPaxosSimulationTest.simulationTest
> -
>
> Key: CASSANDRA-18944
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18944
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Andres de la Peña
>Priority: Normal
> Fix For: 5.0-beta2, 5.0, 5.1
>
>
> The simulator test
> {{org.apache.cassandra.simulator.test.ShortPaxosSimulationTest#simulationTest}}
> is flaky on 5.0 and trunk:
> *
> https://app.circleci.com/pipelines/github/mike-tr-adamson/cassandra/332/workflows/946e28f4-2dec-4384-ac38-de011093f6c6/jobs/25735/tests
> *
> https://app.circleci.com/pipelines/github/adelapena/cassandra/3253/workflows/e48b49e9-cf36-412a-a811-d813031e6f01/jobs/83735/tests
> *
> https://app.circleci.com/pipelines/github/adelapena/cassandra/3254/workflows/69f451ef-fb39-48e4-b1d1-40ee4141b0c1/jobs/83739/tests
> {code}
> org.apache.cassandra.simulator.SimulationException: Failed on seed
> 0xb01206bb3b021127
> Caused by: java.lang.ClassCastException: class
> org.apache.cassandra.net.NoPayload cannot be cast to class
> org.apache.cassandra.gms.GossipShutdown (org.apache.cassandra.net.NoPayload
> and org.apache.cassandra.gms.GossipShutdown are in unnamed module of loader
> org.apache.cassandra.distributed.shared.InstanceClassLoader @68801feb)
> at
> org.apache.cassandra.gms.GossipShutdown$Serializer.serialize(GossipShutdown.java:41)
> at
> org.apache.cassandra.net.Message$Serializer.serialize(Message.java:722)
> at
> org.apache.cassandra.distributed.impl.Instance.serializeMessage(Instance.java:427)
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$registerOutboundFilter$5(Instance.java:370)
> at
> org.apache.cassandra.net.OutboundSink$Filtered.accept(OutboundSink.java:54)
> at org.apache.cassandra.net.OutboundSink.accept(OutboundSink.java:70)
> at
> org.apache.cassandra.net.MessagingService.send(MessagingService.java:449)
> at
> org.apache.cassandra.net.MessagingService.send(MessagingService.java:419)
> at
> org.apache.cassandra.gms.Gossiper.unsafeSendShutdown(Gossiper.java:2634)
> at
> org.apache.cassandra.simulator.cluster.OnInstanceSendShutdown.lambda$invokableSendShutdown$1(OnInstanceSendShutdown.java:48)
> at org.apache.cassandra.concurrent.FutureTask$1.call(FutureTask.java:96)
> at org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:61)
> at org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:71)
> at org.apache.cassandra.concurrent.FutureTask$1.call(FutureTask.java:96)
> at
> org.apache.cassandra.concurrent.SyncFutureTask$1.call(SyncFutureTask.java:46)
> at
> org.apache.cassandra.concurrent.SyncFutureTask.run(SyncFutureTask.java:68)
> at
> org.apache.cassandra.simulator.systems.InterceptingExecutor$AbstractSingleThreadedExecutorPlus.lambda$new$0(InterceptingExecutor.java:584)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:829)
> {code}
> The test failure can easily be reproduced on CircleCI with:
> {code}
> .circleci/generate.sh -sp \
> -e
> REPEATED_SIMULATOR_DTESTS=org.apache.cassandra.simulator.test.ShortPaxosSimulationTest
> \
> -e REPEATED_SIMULATOR_DTESTS_COUNT=100
> {code}
> Flakiness seems ~18%.
> The test failure is not reported on Butler because simulator tests are not
> run by Jenkins.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19247) Minor corrections to TCM Implementation documentation
[
https://issues.apache.org/jira/browse/CASSANDRA-19247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17803257#comment-17803257
]
n.v.harikrishna commented on CASSANDRA-19247:
-
Raised [PR|https://github.com/apache/cassandra/pull/3028] with the chagnes.
> Minor corrections to TCM Implementation documentation
> -
>
> Key: CASSANDRA-19247
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19247
> Project: Cassandra
> Issue Type: Bug
> Components: Documentation, Transactional Cluster Metadata
>Reporter: n.v.harikrishna
>Assignee: n.v.harikrishna
>Priority: Normal
>
> In the "[Bootstrap: InProgressSequence, PrepareJoin,
> BootstrapAndJoin|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/tcm/TCM_implementation.md#bootstrap-inprogresssequence-preparejoin-bootstrapandjoin]”
> section of TCM Implementation doc, InProgressSequence transformations are
> mentioned as "{_}InProgressSequence`, holding the three transformations
> (`PrepareJoin`, `MinJoin` `FinishJoin`){_}”. As per
> [PrepareJoin|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/tcm/transformations/PrepareJoin.java#L154],
> these are {*}StartJoin{*}, Mi{*}d{*}Join & FinishJoin. Doc needs to be
> updated.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-19247) Minor corrections to TCM Implementation documentation
n.v.harikrishna created CASSANDRA-19247:
---
Summary: Minor corrections to TCM Implementation documentation
Key: CASSANDRA-19247
URL: https://issues.apache.org/jira/browse/CASSANDRA-19247
Project: Cassandra
Issue Type: Bug
Components: Documentation, Transactional Cluster Metadata
Reporter: n.v.harikrishna
Assignee: n.v.harikrishna
In the "[Bootstrap: InProgressSequence, PrepareJoin,
BootstrapAndJoin|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/tcm/TCM_implementation.md#bootstrap-inprogresssequence-preparejoin-bootstrapandjoin]”
section of TCM Implementation doc, InProgressSequence transformations are
mentioned as "{_}InProgressSequence`, holding the three transformations
(`PrepareJoin`, `MinJoin` `FinishJoin`){_}”. As per
[PrepareJoin|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/tcm/transformations/PrepareJoin.java#L154],
these are {*}StartJoin{*}, Mi{*}d{*}Join & FinishJoin. Doc needs to be updated.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19245) Upgrade Python driver to 3.29.0
[
https://issues.apache.org/jira/browse/CASSANDRA-19245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17803250#comment-17803250
]
Andres de la Peña commented on CASSANDRA-19245:
---
I have updated {{the PR for 5.0|https://github.com/apache/cassandra/pull/3013}}
to require Python 3.8-3.12 for cqlsh.
I have also updated CircleCI cqlsh tests to test the new min and max Python
versions (3.8 and 3.12 instead of 3.7, 3.8 and 3.11). However, I think that to
make this work we need to update the Docker images
({{{}cassandra-testing-ubuntu2004-java11{}}} and
{{{}cassandra-testing-ubuntu2004-java11-w-dependencies{}}}) in Docker Hub,
since the current images don't include Python 3.12. I have updated the file
[.build/ubuntu2004_test.docker|https://github.com/apache/cassandra/blob/07b06fbebe97f7828a9d329e1b9b04818826f05b/.build/docker/ubuntu2004_test.docker]
to install Python 3.12 instead of 3.11. I don't know the procedure to update
the images in Docker Hub. Maybe [~brandon.williams] knows about it?
> Upgrade Python driver to 3.29.0
> ---
>
> Key: CASSANDRA-19245
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19245
> Project: Cassandra
> Issue Type: Task
> Components: Feature/Vector Search, Tool/cqlsh
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The version of the Python driver that is used by cqlsh (3.28.0) doesn't
> correctly support vectors of variable-width types. Wrong deserialization can
> either fail with an exception or silently provide wrong results. For example:
> {code:java}
> cqlsh:k> CREATE TABLE t (k int PRIMARY KEY, v vector);
> cqlsh:k> INSERT INTO t(k, v) VALUES (1,
> [23452352356235654634567437463767365783768, 3]);
> cqlsh:k> SELECT * FROM t;
> k | v
> ---+--
> 1 | [289729430, -1001073214]}}
> {code}
> The most recent driver at the moment (3.29.0) still doesn't support this kind
> of vector, but it always fails with a proper message instead of dangerously
> providing wrong results, thanks to
> [PYTHON-1371|https://datastax-oss.atlassian.net/browse/PYTHON-1371].
--
This message was sent by Atlassian Jira
(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-19245) Upgrade Python driver to 3.29.0
[
https://issues.apache.org/jira/browse/CASSANDRA-19245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17803250#comment-17803250
]
Andres de la Peña edited comment on CASSANDRA-19245 at 1/4/24 5:10 PM:
---
I have updated [the PR for 5.0|https://github.com/apache/cassandra/pull/3013]
to require Python 3.8-3.12 for cqlsh.
I have also updated CircleCI cqlsh tests to test the new min and max Python
versions (3.8 and 3.12 instead of 3.7, 3.8 and 3.11). However, I think that to
make this work we need to update the Docker images
({{{}cassandra-testing-ubuntu2004-java11{}}} and
{{{}cassandra-testing-ubuntu2004-java11-w-dependencies{}}}) in Docker Hub,
since the current images don't include Python 3.12. I have updated the file
[.build/ubuntu2004_test.docker|https://github.com/apache/cassandra/blob/07b06fbebe97f7828a9d329e1b9b04818826f05b/.build/docker/ubuntu2004_test.docker]
to install Python 3.12 instead of 3.11. I don't know the procedure to update
the images in Docker Hub. Maybe [~brandon.williams] knows about it?
was (Author: adelapena):
I have updated {{the PR for 5.0|https://github.com/apache/cassandra/pull/3013}}
to require Python 3.8-3.12 for cqlsh.
I have also updated CircleCI cqlsh tests to test the new min and max Python
versions (3.8 and 3.12 instead of 3.7, 3.8 and 3.11). However, I think that to
make this work we need to update the Docker images
({{{}cassandra-testing-ubuntu2004-java11{}}} and
{{{}cassandra-testing-ubuntu2004-java11-w-dependencies{}}}) in Docker Hub,
since the current images don't include Python 3.12. I have updated the file
[.build/ubuntu2004_test.docker|https://github.com/apache/cassandra/blob/07b06fbebe97f7828a9d329e1b9b04818826f05b/.build/docker/ubuntu2004_test.docker]
to install Python 3.12 instead of 3.11. I don't know the procedure to update
the images in Docker Hub. Maybe [~brandon.williams] knows about it?
> Upgrade Python driver to 3.29.0
> ---
>
> Key: CASSANDRA-19245
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19245
> Project: Cassandra
> Issue Type: Task
> Components: Feature/Vector Search, Tool/cqlsh
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The version of the Python driver that is used by cqlsh (3.28.0) doesn't
> correctly support vectors of variable-width types. Wrong deserialization can
> either fail with an exception or silently provide wrong results. For example:
> {code:java}
> cqlsh:k> CREATE TABLE t (k int PRIMARY KEY, v vector);
> cqlsh:k> INSERT INTO t(k, v) VALUES (1,
> [23452352356235654634567437463767365783768, 3]);
> cqlsh:k> SELECT * FROM t;
> k | v
> ---+--
> 1 | [289729430, -1001073214]}}
> {code}
> The most recent driver at the moment (3.29.0) still doesn't support this kind
> of vector, but it always fails with a proper message instead of dangerously
> providing wrong results, thanks to
> [PYTHON-1371|https://datastax-oss.atlassian.net/browse/PYTHON-1371].
--
This message was sent by Atlassian Jira
(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-18939) Creating a SASI index after creating an SAI index breaks secondary index queries
[
https://issues.apache.org/jira/browse/CASSANDRA-18939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17803216#comment-17803216
]
Caleb Rackliffe commented on CASSANDRA-18939:
-
[~adelapena] Right…I think the only reason we allow them simultaneously is if
we’re replacing a SASI index and the SAI index just hasn’t completed its
initial build.
> Creating a SASI index after creating an SAI index breaks secondary index
> queries
>
>
> Key: CASSANDRA-18939
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18939
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/2i Index
>Reporter: Jon Haddad
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> In the 5.0 branch, HEAD is e45c1092f91edd63591f562b2120ea6a5fd3edd5, I was
> able to break secondary indexes by doing the following:
> {code}
> cqlsh -e "create KEYSPACE test WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': 1};"
> cqlsh -e "create table test.blah (id int primary key, val text);"
> cqlsh -e "create INDEX on test.blah (val) using 'sai';"
> bin/nodetool flush
> ❯ cqlsh -e "SELECT * from test.blah WHERE val = 'something';"
> id | val
> +-
> (0 rows)
> cqlsh -e "create custom INDEX on test.blah (val) using
> 'org.apache.cassandra.index.sasi.SASIIndex';"
> Warnings :
> SASI indexes are experimental and are not recommended for production use.
> cqlsh -e "SELECT * from test.blah WHERE val = 'something';"
> :1:ReadFailure: Error from server: code=1300 [Replica(s) failed to
> execute read] message="Operation failed - received 0 responses and 1
> failures: UNKNOWN from localhost/127.0.0.1:7000" info={'consistency': 'ONE',
> 'required_responses': 1, 'received_responses': 0, 'failures': 1,
> 'error_code_map': {'127.0.0.1': '0x'}}
> {code}
> Server throws an exception:
> {code}
> ERROR [ReadStage-2] 2023-10-18 12:09:42,391 JVMStabilityInspector.java:70 -
> Exception in thread Thread[ReadStage-2,10,SharedPool]
> java.lang.RuntimeException: java.lang.ClassCastException: class
> org.apache.cassandra.index.sai.StorageAttachedIndex cannot be cast to class
> org.apache.cassandra.index.sasi.SASIIndex
> (org.apache.cassandra.index.sai.StorageAttachedIndex and
> org.apache.cassandra.index.sasi.SASIIndex are in unnamed module of loader
> 'app')
> at
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2585)
> at
> org.apache.cassandra.concurrent.ExecutionFailure$2.run(ExecutionFailure.java:163)
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:143)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:829)
> Caused by: java.lang.ClassCastException: class
> org.apache.cassandra.index.sai.StorageAttachedIndex cannot be cast to class
> org.apache.cassandra.index.sasi.SASIIndex
> (org.apache.cassandra.index.sai.StorageAttachedIndex and
> org.apache.cassandra.index.sasi.SASIIndex are in unnamed module of loader
> 'app')
> at
> org.apache.cassandra.index.sasi.plan.QueryController.getIndex(QueryController.java:96)
> at
> org.apache.cassandra.index.sasi.plan.Operation.analyzeGroup(Operation.java:282)
> at
> org.apache.cassandra.index.sasi.plan.Operation$Builder.complete(Operation.java:433)
> at
> org.apache.cassandra.index.sasi.plan.SASIIndexSearcher.analyze(SASIIndexSearcher.java:65)
> at
> org.apache.cassandra.index.sasi.plan.SASIIndexSearcher.search(SASIIndexSearcher.java:77)
> at
> org.apache.cassandra.db.ReadCommand.executeLocally(ReadCommand.java:425)
> at
> org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:2184)
> at org.apache.cassandra.service
> {code}
> Dropping the SASI index restores correct behavior.
--
This message was sent by Atlassian Jira
(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-19018) An SAI-specific mechanism to ensure consistency isn't violated for multi-column (i.e. AND) queries at CL > ONE
[
https://issues.apache.org/jira/browse/CASSANDRA-19018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-19018:
--
Reviewers: Andres de la Peña
> An SAI-specific mechanism to ensure consistency isn't violated for
> multi-column (i.e. AND) queries at CL > ONE
> --
>
> Key: CASSANDRA-19018
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19018
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination, Feature/SAI
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> CASSANDRA-19007 is going to be where we add a guardrail around
> filtering/index queries that use intersection/AND over partially updated
> non-key columns. (ex. Restricting one clustering column and one normal column
> does not cause a consistency problem, as primary keys cannot be partially
> updated.) This issue exists to attempt to fix this specifically for SAI in
> 5.0.x, as Accord will (last I checked) not be available until the 5.1 release.
> The SAI-specific version of the originally reported issue is this:
> {noformat}
> try (Cluster cluster = init(Cluster.build(2).withConfig(config ->
> config.with(GOSSIP).with(NETWORK)).start()))
> {
> cluster.schemaChange(withKeyspace("CREATE TABLE %s.t (k int
> PRIMARY KEY, a int, b int)"));
> cluster.schemaChange(withKeyspace("CREATE INDEX ON %s.t(a) USING
> 'sai'"));
> cluster.schemaChange(withKeyspace("CREATE INDEX ON %s.t(b) USING
> 'sai'"));
> // insert a split row
> cluster.get(1).executeInternal(withKeyspace("INSERT INTO %s.t(k,
> a) VALUES (0, 1)"));
> cluster.get(2).executeInternal(withKeyspace("INSERT INTO %s.t(k,
> b) VALUES (0, 2)"));
> // Uncomment this line and test succeeds w/ partial writes
> completed...
> //cluster.get(1).nodetoolResult("repair",
> KEYSPACE).asserts().success();
> String select = withKeyspace("SELECT * FROM %s.t WHERE a = 1 AND
> b = 2");
> Object[][] initialRows = cluster.coordinator(1).execute(select,
> ConsistencyLevel.ALL);
> assertRows(initialRows, row(0, 1, 2)); // not found!!
> }
> {noformat}
> To make a long story short, the local SAI indexes are hiding local partial
> matches from the coordinator that would combine there to form full matches.
> Simple non-index filtering queries also suffer from this problem, but they
> hide the partial matches in a different way. I'll outline a possible solution
> for this in the comments that takes advantage of replica filtering protection
> and the repaired/unrepaired datasets...and attempts to minimize the amount of
> extra row data sent to the coordinator.
--
This message was sent by Atlassian Jira
(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-18939) Creating a SASI index after creating an SAI index breaks secondary index queries
[
https://issues.apache.org/jira/browse/CASSANDRA-18939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17803136#comment-17803136
]
Stefan Miklosovic edited comment on CASSANDRA-18939 at 1/4/24 12:46 PM:
[5.0
j17|https://app.circleci.com/pipelines/github/instaclustr/cassandra/3704/workflows/38928f0f-7b9f-44ac-9cf5-e779451a69a9]
[5.0
j11|https://app.circleci.com/pipelines/github/instaclustr/cassandra/3704/workflows/dd6a5155-3e34-4187-b2bb-7cb705e68662]
[trunk j17|
https://app.circleci.com/pipelines/github/instaclustr/cassandra/3706/workflows/1f593737-47b9-4d44-b634-da1c0aac1c8d]
[trunk
j11|https://app.circleci.com/pipelines/github/instaclustr/cassandra/3706/workflows/8f0d41cb-792a-4475-ba3a-1f660e77fdb8]
was (Author: smiklosovic):
[5.0
j17|https://app.circleci.com/pipelines/github/instaclustr/cassandra/3704/workflows/38928f0f-7b9f-44ac-9cf5-e779451a69a9]
[5.0
j11|https://app.circleci.com/pipelines/github/instaclustr/cassandra/3704/workflows/dd6a5155-3e34-4187-b2bb-7cb705e68662]
[trunk|j17
https://app.circleci.com/pipelines/github/instaclustr/cassandra/3706/workflows/1f593737-47b9-4d44-b634-da1c0aac1c8d]
[trunk|j11
https://app.circleci.com/pipelines/github/instaclustr/cassandra/3706/workflows/8f0d41cb-792a-4475-ba3a-1f660e77fdb8]
> Creating a SASI index after creating an SAI index breaks secondary index
> queries
>
>
> Key: CASSANDRA-18939
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18939
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/2i Index
>Reporter: Jon Haddad
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> In the 5.0 branch, HEAD is e45c1092f91edd63591f562b2120ea6a5fd3edd5, I was
> able to break secondary indexes by doing the following:
> {code}
> cqlsh -e "create KEYSPACE test WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': 1};"
> cqlsh -e "create table test.blah (id int primary key, val text);"
> cqlsh -e "create INDEX on test.blah (val) using 'sai';"
> bin/nodetool flush
> ❯ cqlsh -e "SELECT * from test.blah WHERE val = 'something';"
> id | val
> +-
> (0 rows)
> cqlsh -e "create custom INDEX on test.blah (val) using
> 'org.apache.cassandra.index.sasi.SASIIndex';"
> Warnings :
> SASI indexes are experimental and are not recommended for production use.
> cqlsh -e "SELECT * from test.blah WHERE val = 'something';"
> :1:ReadFailure: Error from server: code=1300 [Replica(s) failed to
> execute read] message="Operation failed - received 0 responses and 1
> failures: UNKNOWN from localhost/127.0.0.1:7000" info={'consistency': 'ONE',
> 'required_responses': 1, 'received_responses': 0, 'failures': 1,
> 'error_code_map': {'127.0.0.1': '0x'}}
> {code}
> Server throws an exception:
> {code}
> ERROR [ReadStage-2] 2023-10-18 12:09:42,391 JVMStabilityInspector.java:70 -
> Exception in thread Thread[ReadStage-2,10,SharedPool]
> java.lang.RuntimeException: java.lang.ClassCastException: class
> org.apache.cassandra.index.sai.StorageAttachedIndex cannot be cast to class
> org.apache.cassandra.index.sasi.SASIIndex
> (org.apache.cassandra.index.sai.StorageAttachedIndex and
> org.apache.cassandra.index.sasi.SASIIndex are in unnamed module of loader
> 'app')
> at
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2585)
> at
> org.apache.cassandra.concurrent.ExecutionFailure$2.run(ExecutionFailure.java:163)
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:143)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:829)
> Caused by: java.lang.ClassCastException: class
> org.apache.cassandra.index.sai.StorageAttachedIndex cannot be cast to class
> org.apache.cassandra.index.sasi.SASIIndex
> (org.apache.cassandra.index.sai.StorageAttachedIndex and
> org.apache.cassandra.index.sasi.SASIIndex are in unnamed module of loader
> 'app')
> at
> org.apache.cassandra.index.sasi.plan.QueryController.getIndex(QueryController.java:96)
> at
> org.apache.cassandra.index.sasi.plan.Operation.analyzeGroup(Operation.java:282)
> at
> org.apache.cassandra.index.sasi.plan.Operation$Builder.complete(Operation.java:433)
> at
> org.apache.cassandra.index.sasi.plan.SASIIndexSearcher.analyze(SASIIndexSearcher.java:65)
> at
> org.apache.cassandra.index.sasi.plan.SASIIndexSearcher.search(SASIIndexSearcher.java:77)
> at
> org.apache.cassandra.db.ReadCommand.executeLocally(ReadCommand.java:425)
> at
>
[jira] [Commented] (CASSANDRA-18939) Creating a SASI index after creating an SAI index breaks secondary index queries
[
https://issues.apache.org/jira/browse/CASSANDRA-18939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17803136#comment-17803136
]
Stefan Miklosovic commented on CASSANDRA-18939:
---
[5.0
j17|https://app.circleci.com/pipelines/github/instaclustr/cassandra/3704/workflows/38928f0f-7b9f-44ac-9cf5-e779451a69a9]
[5.0
j11|https://app.circleci.com/pipelines/github/instaclustr/cassandra/3704/workflows/dd6a5155-3e34-4187-b2bb-7cb705e68662]
[trunk|j17
https://app.circleci.com/pipelines/github/instaclustr/cassandra/3706/workflows/1f593737-47b9-4d44-b634-da1c0aac1c8d]
[trunk|j11
https://app.circleci.com/pipelines/github/instaclustr/cassandra/3706/workflows/8f0d41cb-792a-4475-ba3a-1f660e77fdb8]
> Creating a SASI index after creating an SAI index breaks secondary index
> queries
>
>
> Key: CASSANDRA-18939
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18939
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/2i Index
>Reporter: Jon Haddad
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> In the 5.0 branch, HEAD is e45c1092f91edd63591f562b2120ea6a5fd3edd5, I was
> able to break secondary indexes by doing the following:
> {code}
> cqlsh -e "create KEYSPACE test WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': 1};"
> cqlsh -e "create table test.blah (id int primary key, val text);"
> cqlsh -e "create INDEX on test.blah (val) using 'sai';"
> bin/nodetool flush
> ❯ cqlsh -e "SELECT * from test.blah WHERE val = 'something';"
> id | val
> +-
> (0 rows)
> cqlsh -e "create custom INDEX on test.blah (val) using
> 'org.apache.cassandra.index.sasi.SASIIndex';"
> Warnings :
> SASI indexes are experimental and are not recommended for production use.
> cqlsh -e "SELECT * from test.blah WHERE val = 'something';"
> :1:ReadFailure: Error from server: code=1300 [Replica(s) failed to
> execute read] message="Operation failed - received 0 responses and 1
> failures: UNKNOWN from localhost/127.0.0.1:7000" info={'consistency': 'ONE',
> 'required_responses': 1, 'received_responses': 0, 'failures': 1,
> 'error_code_map': {'127.0.0.1': '0x'}}
> {code}
> Server throws an exception:
> {code}
> ERROR [ReadStage-2] 2023-10-18 12:09:42,391 JVMStabilityInspector.java:70 -
> Exception in thread Thread[ReadStage-2,10,SharedPool]
> java.lang.RuntimeException: java.lang.ClassCastException: class
> org.apache.cassandra.index.sai.StorageAttachedIndex cannot be cast to class
> org.apache.cassandra.index.sasi.SASIIndex
> (org.apache.cassandra.index.sai.StorageAttachedIndex and
> org.apache.cassandra.index.sasi.SASIIndex are in unnamed module of loader
> 'app')
> at
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2585)
> at
> org.apache.cassandra.concurrent.ExecutionFailure$2.run(ExecutionFailure.java:163)
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:143)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:829)
> Caused by: java.lang.ClassCastException: class
> org.apache.cassandra.index.sai.StorageAttachedIndex cannot be cast to class
> org.apache.cassandra.index.sasi.SASIIndex
> (org.apache.cassandra.index.sai.StorageAttachedIndex and
> org.apache.cassandra.index.sasi.SASIIndex are in unnamed module of loader
> 'app')
> at
> org.apache.cassandra.index.sasi.plan.QueryController.getIndex(QueryController.java:96)
> at
> org.apache.cassandra.index.sasi.plan.Operation.analyzeGroup(Operation.java:282)
> at
> org.apache.cassandra.index.sasi.plan.Operation$Builder.complete(Operation.java:433)
> at
> org.apache.cassandra.index.sasi.plan.SASIIndexSearcher.analyze(SASIIndexSearcher.java:65)
> at
> org.apache.cassandra.index.sasi.plan.SASIIndexSearcher.search(SASIIndexSearcher.java:77)
> at
> org.apache.cassandra.db.ReadCommand.executeLocally(ReadCommand.java:425)
> at
> org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:2184)
> at org.apache.cassandra.service
> {code}
> Dropping the SASI index restores correct behavior.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18824) Backport CASSANDRA-16418: Cleanup behaviour during node decommission caused missing replica
[ https://issues.apache.org/jira/browse/CASSANDRA-18824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17803115#comment-17803115 ] Brandon Williams commented on CASSANDRA-18824: -- [~jlewandowski] sure, I see you committed circle configs, has CI been run? > Backport CASSANDRA-16418: Cleanup behaviour during node decommission caused > missing replica > --- > > Key: CASSANDRA-18824 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18824 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Bootstrap and Decommission >Reporter: Szymon Miezal >Assignee: Szymon Miezal >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.0.x, 5.x > > Time Spent: 1h > Remaining Estimate: 0h > > Node decommission triggers data transfer to other nodes. While this transfer > is in progress, > receiving nodes temporarily hold token ranges in a pending state. However, > the cleanup process currently doesn't consider these pending ranges when > calculating token ownership. > As a consequence, data that is already stored in sstables gets inadvertently > cleaned up. > STR: > * Create two node cluster > * Create keyspace with RF=1 > * Insert sample data (assert data is available when querying both nodes) > * Start decommission process of node 1 > * Start running cleanup in a loop on node 2 until decommission on node 1 > finishes > * Verify of all rows are in the cluster - it will fail as the previous step > removed some of the rows > It seems that the cleanup process does not take into account the pending > ranges, it uses only the local ranges - > [https://github.com/apache/cassandra/blob/caad2f24f95b494d05c6b5d86a8d25fbee58d7c2/src/java/org/apache/cassandra/db/compaction/CompactionManager.java#L466]. > There are two solutions to the problem. > One would be to change the cleanup process in a way that it start taking > pending ranges into account. Even thought it might sound tempting at first it > will require involving changes and a lot of testing effort. > Alternatively we could interrupt/prevent the cleanup process from running > when any pending range on a node is detected. That sounds like a reasonable > alternative to the problem and something that is relatively easy to implement. > The bug has been already fixed in 4.x with CASSANDRA-16418, the goal of this > ticket is to backport it to 3.x. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18939) Creating a SASI index after creating an SAI index breaks secondary index queries
[
https://issues.apache.org/jira/browse/CASSANDRA-18939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17803014#comment-17803014
]
Andres de la Peña commented on CASSANDRA-18939:
---
The last changes look to me. Do we have CI results for them?
As for the SASI/SAI index selection, I think it makes sense to prioritize SAI
over SASI. It be done by making {{SASIIndex#getEstimatedResultRows()}} return
{{Long.MIN_VALUE + 1}}, although we might just check the index class or have a
separate method giving the priority of the implementation in case of having an
identical number of estimated rows, which might be a bit less hacky. In any
case, I think that should be done in a separate ticket since it's not related
to the specific bug that we're fixing here.
I also wondered whether we allow multiple index implementations on the same
column, even when all implementations should return the same results for the
same expression. I think the main reason is allowing transitioning from one
index implementation to another. Is that right? Another more convoluted use
case might be having separate columns with different index implementations, and
then other columns that might be queried combined with either of those
single-indexed columns.
> Creating a SASI index after creating an SAI index breaks secondary index
> queries
>
>
> Key: CASSANDRA-18939
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18939
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/2i Index
>Reporter: Jon Haddad
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> In the 5.0 branch, HEAD is e45c1092f91edd63591f562b2120ea6a5fd3edd5, I was
> able to break secondary indexes by doing the following:
> {code}
> cqlsh -e "create KEYSPACE test WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': 1};"
> cqlsh -e "create table test.blah (id int primary key, val text);"
> cqlsh -e "create INDEX on test.blah (val) using 'sai';"
> bin/nodetool flush
> ❯ cqlsh -e "SELECT * from test.blah WHERE val = 'something';"
> id | val
> +-
> (0 rows)
> cqlsh -e "create custom INDEX on test.blah (val) using
> 'org.apache.cassandra.index.sasi.SASIIndex';"
> Warnings :
> SASI indexes are experimental and are not recommended for production use.
> cqlsh -e "SELECT * from test.blah WHERE val = 'something';"
> :1:ReadFailure: Error from server: code=1300 [Replica(s) failed to
> execute read] message="Operation failed - received 0 responses and 1
> failures: UNKNOWN from localhost/127.0.0.1:7000" info={'consistency': 'ONE',
> 'required_responses': 1, 'received_responses': 0, 'failures': 1,
> 'error_code_map': {'127.0.0.1': '0x'}}
> {code}
> Server throws an exception:
> {code}
> ERROR [ReadStage-2] 2023-10-18 12:09:42,391 JVMStabilityInspector.java:70 -
> Exception in thread Thread[ReadStage-2,10,SharedPool]
> java.lang.RuntimeException: java.lang.ClassCastException: class
> org.apache.cassandra.index.sai.StorageAttachedIndex cannot be cast to class
> org.apache.cassandra.index.sasi.SASIIndex
> (org.apache.cassandra.index.sai.StorageAttachedIndex and
> org.apache.cassandra.index.sasi.SASIIndex are in unnamed module of loader
> 'app')
> at
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2585)
> at
> org.apache.cassandra.concurrent.ExecutionFailure$2.run(ExecutionFailure.java:163)
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:143)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:829)
> Caused by: java.lang.ClassCastException: class
> org.apache.cassandra.index.sai.StorageAttachedIndex cannot be cast to class
> org.apache.cassandra.index.sasi.SASIIndex
> (org.apache.cassandra.index.sai.StorageAttachedIndex and
> org.apache.cassandra.index.sasi.SASIIndex are in unnamed module of loader
> 'app')
> at
> org.apache.cassandra.index.sasi.plan.QueryController.getIndex(QueryController.java:96)
> at
> org.apache.cassandra.index.sasi.plan.Operation.analyzeGroup(Operation.java:282)
> at
> org.apache.cassandra.index.sasi.plan.Operation$Builder.complete(Operation.java:433)
> at
> org.apache.cassandra.index.sasi.plan.SASIIndexSearcher.analyze(SASIIndexSearcher.java:65)
> at
> org.apache.cassandra.index.sasi.plan.SASIIndexSearcher.search(SASIIndexSearcher.java:77)
> at
> org.apache.cassandra.db.ReadCommand.executeLocally(ReadCommand.java:425)
> at
> org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:2184)
> at
[jira] [Commented] (CASSANDRA-18824) Backport CASSANDRA-16418: Cleanup behaviour during node decommission caused missing replica
[ https://issues.apache.org/jira/browse/CASSANDRA-18824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17802896#comment-17802896 ] Jacek Lewandowski commented on CASSANDRA-18824: --- [~brandon.williams] - would you review my PRs? > Backport CASSANDRA-16418: Cleanup behaviour during node decommission caused > missing replica > --- > > Key: CASSANDRA-18824 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18824 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Bootstrap and Decommission >Reporter: Szymon Miezal >Assignee: Szymon Miezal >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.0.x, 5.x > > Time Spent: 1h > Remaining Estimate: 0h > > Node decommission triggers data transfer to other nodes. While this transfer > is in progress, > receiving nodes temporarily hold token ranges in a pending state. However, > the cleanup process currently doesn't consider these pending ranges when > calculating token ownership. > As a consequence, data that is already stored in sstables gets inadvertently > cleaned up. > STR: > * Create two node cluster > * Create keyspace with RF=1 > * Insert sample data (assert data is available when querying both nodes) > * Start decommission process of node 1 > * Start running cleanup in a loop on node 2 until decommission on node 1 > finishes > * Verify of all rows are in the cluster - it will fail as the previous step > removed some of the rows > It seems that the cleanup process does not take into account the pending > ranges, it uses only the local ranges - > [https://github.com/apache/cassandra/blob/caad2f24f95b494d05c6b5d86a8d25fbee58d7c2/src/java/org/apache/cassandra/db/compaction/CompactionManager.java#L466]. > There are two solutions to the problem. > One would be to change the cleanup process in a way that it start taking > pending ranges into account. Even thought it might sound tempting at first it > will require involving changes and a lot of testing effort. > Alternatively we could interrupt/prevent the cleanup process from running > when any pending range on a node is detected. That sounds like a reasonable > alternative to the problem and something that is relatively easy to implement. > The bug has been already fixed in 4.x with CASSANDRA-16418, the goal of this > ticket is to backport it to 3.x. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16565) Remove dependency on sigar
[ https://issues.apache.org/jira/browse/CASSANDRA-16565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-16565: -- Status: Changes Suggested (was: Review In Progress) > Remove dependency on sigar > -- > > Key: CASSANDRA-16565 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16565 > Project: Cassandra > Issue Type: Improvement > Components: Build >Reporter: David Capwell >Assignee: Claude Warren >Priority: Normal > Fix For: 5.x > > > sigar is used to check if the environment has good settings for running C*, > but requires we bundle a lot of native libraries to perform this check (which > can also be done elsewhere). This project also appears to be dead as the > last commit was around 6 years ago. > With the move to resolve artifacts rather than commit them, removing this > dependency would remove majority of the artifacts fetched from GitHub. -- This message was sent by Atlassian Jira (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-16565) Remove dependency on sigar
[ https://issues.apache.org/jira/browse/CASSANDRA-16565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-16565: -- Status: Review In Progress (was: Needs Committer) > Remove dependency on sigar > -- > > Key: CASSANDRA-16565 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16565 > Project: Cassandra > Issue Type: Improvement > Components: Build >Reporter: David Capwell >Assignee: Claude Warren >Priority: Normal > Fix For: 5.x > > > sigar is used to check if the environment has good settings for running C*, > but requires we bundle a lot of native libraries to perform this check (which > can also be done elsewhere). This project also appears to be dead as the > last commit was around 6 years ago. > With the move to resolve artifacts rather than commit them, removing this > dependency would remove majority of the artifacts fetched from GitHub. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18824) Backport CASSANDRA-16418: Cleanup behaviour during node decommission caused missing replica
[ https://issues.apache.org/jira/browse/CASSANDRA-18824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17802776#comment-17802776 ] Jacek Lewandowski commented on CASSANDRA-18824: --- np, I'll handle that in the PRs > Backport CASSANDRA-16418: Cleanup behaviour during node decommission caused > missing replica > --- > > Key: CASSANDRA-18824 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18824 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Bootstrap and Decommission >Reporter: Szymon Miezal >Assignee: Szymon Miezal >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.0.x, 5.x > > Time Spent: 1h > Remaining Estimate: 0h > > Node decommission triggers data transfer to other nodes. While this transfer > is in progress, > receiving nodes temporarily hold token ranges in a pending state. However, > the cleanup process currently doesn't consider these pending ranges when > calculating token ownership. > As a consequence, data that is already stored in sstables gets inadvertently > cleaned up. > STR: > * Create two node cluster > * Create keyspace with RF=1 > * Insert sample data (assert data is available when querying both nodes) > * Start decommission process of node 1 > * Start running cleanup in a loop on node 2 until decommission on node 1 > finishes > * Verify of all rows are in the cluster - it will fail as the previous step > removed some of the rows > It seems that the cleanup process does not take into account the pending > ranges, it uses only the local ranges - > [https://github.com/apache/cassandra/blob/caad2f24f95b494d05c6b5d86a8d25fbee58d7c2/src/java/org/apache/cassandra/db/compaction/CompactionManager.java#L466]. > There are two solutions to the problem. > One would be to change the cleanup process in a way that it start taking > pending ranges into account. Even thought it might sound tempting at first it > will require involving changes and a lot of testing effort. > Alternatively we could interrupt/prevent the cleanup process from running > when any pending range on a node is detected. That sounds like a reasonable > alternative to the problem and something that is relatively easy to implement. > The bug has been already fixed in 4.x with CASSANDRA-16418, the goal of this > ticket is to backport it to 3.x. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18824) Backport CASSANDRA-16418: Cleanup behaviour during node decommission caused missing replica
[ https://issues.apache.org/jira/browse/CASSANDRA-18824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17802730#comment-17802730 ] Szymon Miezal edited comment on CASSANDRA-18824 at 1/4/24 9:01 AM: --- It seems to be failing on 4.x branches. I think I haven't cleared the directory properly when checking out and compiling it locally hence I missed this before sending the patches - my mistake, apologies. [https://github.com/szymon-miezal/cassandra/commit/4cc492bd39dfe3eb173c5d611cf188e7b6961529] seems to be resolving the problem. was (Author: JIRAUSER302037): It seems to be failing on 4.x branches. I think I haven't cleared the directory properly when checking out compiling it locally hence I missed this before sending the patches. [https://github.com/szymon-miezal/cassandra/commit/4cc492bd39dfe3eb173c5d611cf188e7b6961529] seems to be resolving the problem. > Backport CASSANDRA-16418: Cleanup behaviour during node decommission caused > missing replica > --- > > Key: CASSANDRA-18824 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18824 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Bootstrap and Decommission >Reporter: Szymon Miezal >Assignee: Szymon Miezal >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.0.x, 5.x > > Time Spent: 1h > Remaining Estimate: 0h > > Node decommission triggers data transfer to other nodes. While this transfer > is in progress, > receiving nodes temporarily hold token ranges in a pending state. However, > the cleanup process currently doesn't consider these pending ranges when > calculating token ownership. > As a consequence, data that is already stored in sstables gets inadvertently > cleaned up. > STR: > * Create two node cluster > * Create keyspace with RF=1 > * Insert sample data (assert data is available when querying both nodes) > * Start decommission process of node 1 > * Start running cleanup in a loop on node 2 until decommission on node 1 > finishes > * Verify of all rows are in the cluster - it will fail as the previous step > removed some of the rows > It seems that the cleanup process does not take into account the pending > ranges, it uses only the local ranges - > [https://github.com/apache/cassandra/blob/caad2f24f95b494d05c6b5d86a8d25fbee58d7c2/src/java/org/apache/cassandra/db/compaction/CompactionManager.java#L466]. > There are two solutions to the problem. > One would be to change the cleanup process in a way that it start taking > pending ranges into account. Even thought it might sound tempting at first it > will require involving changes and a lot of testing effort. > Alternatively we could interrupt/prevent the cleanup process from running > when any pending range on a node is detected. That sounds like a reasonable > alternative to the problem and something that is relatively easy to implement. > The bug has been already fixed in 4.x with CASSANDRA-16418, the goal of this > ticket is to backport it to 3.x. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18824) Backport CASSANDRA-16418: Cleanup behaviour during node decommission caused missing replica
[ https://issues.apache.org/jira/browse/CASSANDRA-18824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17802730#comment-17802730 ] Szymon Miezal edited comment on CASSANDRA-18824 at 1/4/24 8:56 AM: --- It seems to be failing on 4.x branches. I think I haven't cleared the directory properly when checking out compiling it locally hence I missed this before sending the patches. [https://github.com/szymon-miezal/cassandra/commit/4cc492bd39dfe3eb173c5d611cf188e7b6961529] seems to be resolving the problem. was (Author: JIRAUSER302037): It seems to be failing on 4.x branches. I think I haven't cleared the directory properly when checking out compiling it locally hence I missed this before sending the patches. > Backport CASSANDRA-16418: Cleanup behaviour during node decommission caused > missing replica > --- > > Key: CASSANDRA-18824 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18824 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Bootstrap and Decommission >Reporter: Szymon Miezal >Assignee: Szymon Miezal >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.0.x, 5.x > > Time Spent: 1h > Remaining Estimate: 0h > > Node decommission triggers data transfer to other nodes. While this transfer > is in progress, > receiving nodes temporarily hold token ranges in a pending state. However, > the cleanup process currently doesn't consider these pending ranges when > calculating token ownership. > As a consequence, data that is already stored in sstables gets inadvertently > cleaned up. > STR: > * Create two node cluster > * Create keyspace with RF=1 > * Insert sample data (assert data is available when querying both nodes) > * Start decommission process of node 1 > * Start running cleanup in a loop on node 2 until decommission on node 1 > finishes > * Verify of all rows are in the cluster - it will fail as the previous step > removed some of the rows > It seems that the cleanup process does not take into account the pending > ranges, it uses only the local ranges - > [https://github.com/apache/cassandra/blob/caad2f24f95b494d05c6b5d86a8d25fbee58d7c2/src/java/org/apache/cassandra/db/compaction/CompactionManager.java#L466]. > There are two solutions to the problem. > One would be to change the cleanup process in a way that it start taking > pending ranges into account. Even thought it might sound tempting at first it > will require involving changes and a lot of testing effort. > Alternatively we could interrupt/prevent the cleanup process from running > when any pending range on a node is detected. That sounds like a reasonable > alternative to the problem and something that is relatively easy to implement. > The bug has been already fixed in 4.x with CASSANDRA-16418, the goal of this > ticket is to backport it to 3.x. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18824) Backport CASSANDRA-16418: Cleanup behaviour during node decommission caused missing replica
[ https://issues.apache.org/jira/browse/CASSANDRA-18824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17802730#comment-17802730 ] Szymon Miezal commented on CASSANDRA-18824: --- It seems to be failing on 4.x branches. I think I haven't cleared the directory properly when checking out compiling it locally hence I missed this before sending the patches. > Backport CASSANDRA-16418: Cleanup behaviour during node decommission caused > missing replica > --- > > Key: CASSANDRA-18824 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18824 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Bootstrap and Decommission >Reporter: Szymon Miezal >Assignee: Szymon Miezal >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.0.x, 5.x > > Time Spent: 1h > Remaining Estimate: 0h > > Node decommission triggers data transfer to other nodes. While this transfer > is in progress, > receiving nodes temporarily hold token ranges in a pending state. However, > the cleanup process currently doesn't consider these pending ranges when > calculating token ownership. > As a consequence, data that is already stored in sstables gets inadvertently > cleaned up. > STR: > * Create two node cluster > * Create keyspace with RF=1 > * Insert sample data (assert data is available when querying both nodes) > * Start decommission process of node 1 > * Start running cleanup in a loop on node 2 until decommission on node 1 > finishes > * Verify of all rows are in the cluster - it will fail as the previous step > removed some of the rows > It seems that the cleanup process does not take into account the pending > ranges, it uses only the local ranges - > [https://github.com/apache/cassandra/blob/caad2f24f95b494d05c6b5d86a8d25fbee58d7c2/src/java/org/apache/cassandra/db/compaction/CompactionManager.java#L466]. > There are two solutions to the problem. > One would be to change the cleanup process in a way that it start taking > pending ranges into account. Even thought it might sound tempting at first it > will require involving changes and a lot of testing effort. > Alternatively we could interrupt/prevent the cleanup process from running > when any pending range on a node is detected. That sounds like a reasonable > alternative to the problem and something that is relatively easy to implement. > The bug has been already fixed in 4.x with CASSANDRA-16418, the goal of this > ticket is to backport it to 3.x. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18824) Backport CASSANDRA-16418: Cleanup behaviour during node decommission caused missing replica
[ https://issues.apache.org/jira/browse/CASSANDRA-18824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17802659#comment-17802659 ] Jacek Lewandowski commented on CASSANDRA-18824: --- Compilation fails on some branches - I've created PRs yesterday, they are attached in the links section. I'm applying some fixes on each of them. When ready, I'll rerun the CI > Backport CASSANDRA-16418: Cleanup behaviour during node decommission caused > missing replica > --- > > Key: CASSANDRA-18824 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18824 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Bootstrap and Decommission >Reporter: Szymon Miezal >Assignee: Szymon Miezal >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.0.x, 5.x > > Time Spent: 1h > Remaining Estimate: 0h > > Node decommission triggers data transfer to other nodes. While this transfer > is in progress, > receiving nodes temporarily hold token ranges in a pending state. However, > the cleanup process currently doesn't consider these pending ranges when > calculating token ownership. > As a consequence, data that is already stored in sstables gets inadvertently > cleaned up. > STR: > * Create two node cluster > * Create keyspace with RF=1 > * Insert sample data (assert data is available when querying both nodes) > * Start decommission process of node 1 > * Start running cleanup in a loop on node 2 until decommission on node 1 > finishes > * Verify of all rows are in the cluster - it will fail as the previous step > removed some of the rows > It seems that the cleanup process does not take into account the pending > ranges, it uses only the local ranges - > [https://github.com/apache/cassandra/blob/caad2f24f95b494d05c6b5d86a8d25fbee58d7c2/src/java/org/apache/cassandra/db/compaction/CompactionManager.java#L466]. > There are two solutions to the problem. > One would be to change the cleanup process in a way that it start taking > pending ranges into account. Even thought it might sound tempting at first it > will require involving changes and a lot of testing effort. > Alternatively we could interrupt/prevent the cleanup process from running > when any pending range on a node is detected. That sounds like a reasonable > alternative to the problem and something that is relatively easy to implement. > The bug has been already fixed in 4.x with CASSANDRA-16418, the goal of this > ticket is to backport it to 3.x. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
