[jira] [Updated] (CASSANDRA-19472) CEP-15 (C*) Integrate accord with repair
[ https://issues.apache.org/jira/browse/CASSANDRA-19472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Eggleston updated CASSANDRA-19472: Source Control Link: https://github.com/apache/cassandra/commit/d8174c71054ade99b0d5209c3ca81f7300c5899e Resolution: Fixed Status: Resolved (was: Ready to Commit) > CEP-15 (C*) Integrate accord with repair > > > Key: CASSANDRA-19472 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19472 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: Blake Eggleston >Assignee: Blake Eggleston >Priority: Normal > Fix For: 5.x > > Attachments: ci_summary.html > > Time Spent: 3h 40m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (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-19472) CEP-15 (C*) Integrate accord with repair
[ https://issues.apache.org/jira/browse/CASSANDRA-19472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Eggleston updated CASSANDRA-19472: Status: Ready to Commit (was: Review In Progress) > CEP-15 (C*) Integrate accord with repair > > > Key: CASSANDRA-19472 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19472 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: Blake Eggleston >Assignee: Blake Eggleston >Priority: Normal > Fix For: 5.x > > Attachments: ci_summary.html > > Time Spent: 3h 40m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (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-19472) CEP-15 (C*) Integrate accord with repair
[ https://issues.apache.org/jira/browse/CASSANDRA-19472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Eggleston updated CASSANDRA-19472: Attachment: ci_summary.html > CEP-15 (C*) Integrate accord with repair > > > Key: CASSANDRA-19472 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19472 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: Blake Eggleston >Assignee: Blake Eggleston >Priority: Normal > Fix For: 5.x > > Attachments: ci_summary.html > > Time Spent: 3h 40m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (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-19472) CEP-15 (C*) Integrate accord with repair
[ https://issues.apache.org/jira/browse/CASSANDRA-19472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Eggleston updated CASSANDRA-19472: Status: Review In Progress (was: Patch Available) > CEP-15 (C*) Integrate accord with repair > > > Key: CASSANDRA-19472 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19472 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: Blake Eggleston >Assignee: Blake Eggleston >Priority: Normal > Fix For: 5.x > > Attachments: ci_summary.html > > Time Spent: 3h 40m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (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-19588) CEP-15 (C*) - auto consensus repair
Blake Eggleston created CASSANDRA-19588: --- Summary: CEP-15 (C*) - auto consensus repair Key: CASSANDRA-19588 URL: https://issues.apache.org/jira/browse/CASSANDRA-19588 Project: Cassandra Issue Type: Improvement Components: Accord Reporter: Blake Eggleston Since we can have multiple consensus protocols used by a cluster, keyspace, or even table, we should have a "--consensus-only" flag that just does the right thing for the given table/range -- This message was sent by Atlassian Jira (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-19503) (Accord) Cassandra bootstrap no longer using the range txn and instead uses the sync point empty txn for reads
[ https://issues.apache.org/jira/browse/CASSANDRA-19503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Eggleston updated CASSANDRA-19503: Status: Ready to Commit (was: Review In Progress) +1 > (Accord) Cassandra bootstrap no longer using the range txn and instead uses > the sync point empty txn for reads > -- > > Key: CASSANDRA-19503 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19503 > Project: Cassandra > Issue Type: Bug > Components: Accord >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 5.x > > > Ephemeral reads made a change to ReadData which caused Bootstrap to no longer > use the range txn it generates and instead uses the empty txn from the sync > point. This was not detected in Accord due to ListRead supporting ranges, > and failed in Cassandra as we don’t support range reads. -- This message was sent by Atlassian Jira (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-19503) (Accord) Cassandra bootstrap no longer using the range txn and instead uses the sync point empty txn for reads
[ https://issues.apache.org/jira/browse/CASSANDRA-19503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Eggleston updated CASSANDRA-19503: Reviewers: Blake Eggleston, Blake Eggleston (was: Blake Eggleston) Blake Eggleston, Blake Eggleston (was: Blake Eggleston) Status: Review In Progress (was: Patch Available) > (Accord) Cassandra bootstrap no longer using the range txn and instead uses > the sync point empty txn for reads > -- > > Key: CASSANDRA-19503 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19503 > Project: Cassandra > Issue Type: Bug > Components: Accord >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 5.x > > > Ephemeral reads made a change to ReadData which caused Bootstrap to no longer > use the range txn it generates and instead uses the empty txn from the sync > point. This was not detected in Accord due to ListRead supporting ranges, > and failed in Cassandra as we don’t support range reads. -- This message was sent by Atlassian Jira (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-19503) (Accord) Cassandra bootstrap no longer using the range txn and instead uses the sync point empty txn for reads
[ https://issues.apache.org/jira/browse/CASSANDRA-19503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Eggleston updated CASSANDRA-19503: Reviewers: Blake Eggleston > (Accord) Cassandra bootstrap no longer using the range txn and instead uses > the sync point empty txn for reads > -- > > Key: CASSANDRA-19503 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19503 > Project: Cassandra > Issue Type: Bug > Components: Accord >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 5.x > > > Ephemeral reads made a change to ReadData which caused Bootstrap to no longer > use the range txn it generates and instead uses the empty txn from the sync > point. This was not detected in Accord due to ListRead supporting ranges, > and failed in Cassandra as we don’t support range reads. -- This message was sent by Atlassian Jira (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-19042) Repair fuzz tests fail with paxos_variant: v2
[
https://issues.apache.org/jira/browse/CASSANDRA-19042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Blake Eggleston updated CASSANDRA-19042:
Status: Ready to Commit (was: Review In Progress)
LGTM, thanks!
> Repair fuzz tests fail with paxos_variant: v2
> -
>
> Key: CASSANDRA-19042
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19042
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Repair, Feature/Lightweight Transactions,
> Test/fuzz
>Reporter: Branimir Lambov
>Assignee: David Capwell
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
> Time Spent: 2h 10m
> Remaining Estimate: 0h
>
> Adding {{paxos_variant: v2}} to the test yaml causes all fuzz repair tests to
> fail with
> {code}
> java.lang.NullPointerException: null
> at
> org.apache.cassandra.gms.EndpointStateSerializer.serializedSize(EndpointState.java:337)
> at
> org.apache.cassandra.gms.EndpointStateSerializer.serializedSize(EndpointState.java:300)
> at
> org.apache.cassandra.service.paxos.cleanup.PaxosStartPrepareCleanup$RequestSerializer.serializedSize(PaxosStartPrepareCleanup.java:176)
> at
> org.apache.cassandra.service.paxos.cleanup.PaxosStartPrepareCleanup$RequestSerializer.serializedSize(PaxosStartPrepareCleanup.java:147)
> at
> org.apache.cassandra.net.Message$Serializer.payloadSize(Message.java:1067)
> at org.apache.cassandra.net.Message.payloadSize(Message.java:1114)
> at
> org.apache.cassandra.net.Message$Serializer.serializedSize(Message.java:750)
> at org.apache.cassandra.net.Message.serializedSize(Message.java:1094)
> ...
> {code}
> This happens for all three options of {{paxos_state_purging}} and both with
> and without {{storage_compatibility_mode: NONE}}.
> Tests still fail if {{PaxosStartPrepareCleanup}} is changed to use
> {{EndpointState.nullableSerializer}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19016) CEP-15: (C*) per-table transactional configuration
[ https://issues.apache.org/jira/browse/CASSANDRA-19016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Eggleston updated CASSANDRA-19016: Attachment: (was: ci_summary-1.html) > CEP-15: (C*) per-table transactional configuration > -- > > Key: CASSANDRA-19016 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19016 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: Blake Eggleston >Assignee: Blake Eggleston >Priority: Normal > Fix For: 5.x > > Attachments: ci_summary.html, result_details.tar.gz > > > Accord configuration options should be rolled into as few options as > possible, with as few touch points as possible and, with support for > per-table configuration -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19016) CEP-15: (C*) per-table transactional configuration
[ https://issues.apache.org/jira/browse/CASSANDRA-19016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Eggleston updated CASSANDRA-19016: Attachment: ci_summary.html result_details.tar.gz > CEP-15: (C*) per-table transactional configuration > -- > > Key: CASSANDRA-19016 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19016 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: Blake Eggleston >Assignee: Blake Eggleston >Priority: Normal > Fix For: 5.x > > Attachments: ci_summary.html, result_details.tar.gz > > > Accord configuration options should be rolled into as few options as > possible, with as few touch points as possible and, with support for > per-table configuration -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19016) CEP-15: (C*) per-table transactional configuration
[ https://issues.apache.org/jira/browse/CASSANDRA-19016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Eggleston updated CASSANDRA-19016: Attachment: ci_summary-1.html > CEP-15: (C*) per-table transactional configuration > -- > > Key: CASSANDRA-19016 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19016 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: Blake Eggleston >Assignee: Blake Eggleston >Priority: Normal > Fix For: 5.x > > Attachments: ci_summary.html, result_details.tar.gz > > > Accord configuration options should be rolled into as few options as > possible, with as few touch points as possible and, with support for > per-table configuration -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19472) CEP-15 (C*) Integrate accord with repair
[ https://issues.apache.org/jira/browse/CASSANDRA-19472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Eggleston updated CASSANDRA-19472: Test and Documentation Plan: ci Status: Patch Available (was: Open) > CEP-15 (C*) Integrate accord with repair > > > Key: CASSANDRA-19472 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19472 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: Blake Eggleston >Assignee: Blake Eggleston >Priority: Normal > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (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-19472) CEP-15 (C*) Integrate accord with repair
[ https://issues.apache.org/jira/browse/CASSANDRA-19472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Eggleston updated CASSANDRA-19472: Change Category: Operability Complexity: Normal Component/s: Accord Fix Version/s: 5.x Reviewers: Ariel Weisberg, David Capwell Assignee: Blake Eggleston Status: Open (was: Triage Needed) Wires accord repair into the normal repair path and removes the distinction between an accord repair job and a cassandra repair job, this makes both repair types coexist [https://github.com/apache/cassandra/pull/3174] > CEP-15 (C*) Integrate accord with repair > > > Key: CASSANDRA-19472 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19472 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: Blake Eggleston >Assignee: Blake Eggleston >Priority: Normal > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (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-19016) CEP-15: (C*) per-table transactional configuration
[ https://issues.apache.org/jira/browse/CASSANDRA-19016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Eggleston updated CASSANDRA-19016: Status: Ready to Commit (was: Review In Progress) Ariel approved on PR > CEP-15: (C*) per-table transactional configuration > -- > > Key: CASSANDRA-19016 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19016 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: Blake Eggleston >Assignee: Blake Eggleston >Priority: Normal > Fix For: 5.x > > > Accord configuration options should be rolled into as few options as > possible, with as few touch points as possible and, with support for > per-table configuration -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19016) CEP-15: (C*) per-table transactional configuration
[ https://issues.apache.org/jira/browse/CASSANDRA-19016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Eggleston updated CASSANDRA-19016: Source Control Link: https://github.com/apache/cassandra/commit/85411ebcdd94a5b37b668ab16afc69c8443bc42c Resolution: Fixed Status: Resolved (was: Ready to Commit) > CEP-15: (C*) per-table transactional configuration > -- > > Key: CASSANDRA-19016 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19016 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: Blake Eggleston >Assignee: Blake Eggleston >Priority: Normal > Fix For: 5.x > > > Accord configuration options should be rolled into as few options as > possible, with as few touch points as possible and, with support for > per-table configuration -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19016) CEP-15: (C*) per-table transactional configuration
[ https://issues.apache.org/jira/browse/CASSANDRA-19016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Eggleston updated CASSANDRA-19016: Reviewers: Ariel Weisberg (was: Ariel Weisberg, David Capwell) Status: Review In Progress (was: Patch Available) > CEP-15: (C*) per-table transactional configuration > -- > > Key: CASSANDRA-19016 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19016 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: Blake Eggleston >Assignee: Blake Eggleston >Priority: Normal > Fix For: 5.x > > > Accord configuration options should be rolled into as few options as > possible, with as few touch points as possible and, with support for > per-table configuration -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-19472) CEP-15 (C*) Integrate accord with repair
Blake Eggleston created CASSANDRA-19472: --- Summary: CEP-15 (C*) Integrate accord with repair Key: CASSANDRA-19472 URL: https://issues.apache.org/jira/browse/CASSANDRA-19472 Project: Cassandra Issue Type: Improvement Reporter: Blake Eggleston -- This message was sent by Atlassian Jira (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-19042) Repair fuzz tests fail with paxos_variant: v2
[
https://issues.apache.org/jira/browse/CASSANDRA-19042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Blake Eggleston updated CASSANDRA-19042:
Reviewers: Blake Eggleston
sure, I can review it
> Repair fuzz tests fail with paxos_variant: v2
> -
>
> Key: CASSANDRA-19042
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19042
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Repair, Feature/Lightweight Transactions,
> Test/fuzz
>Reporter: Branimir Lambov
>Assignee: David Capwell
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
> Time Spent: 2h 10m
> Remaining Estimate: 0h
>
> Adding {{paxos_variant: v2}} to the test yaml causes all fuzz repair tests to
> fail with
> {code}
> java.lang.NullPointerException: null
> at
> org.apache.cassandra.gms.EndpointStateSerializer.serializedSize(EndpointState.java:337)
> at
> org.apache.cassandra.gms.EndpointStateSerializer.serializedSize(EndpointState.java:300)
> at
> org.apache.cassandra.service.paxos.cleanup.PaxosStartPrepareCleanup$RequestSerializer.serializedSize(PaxosStartPrepareCleanup.java:176)
> at
> org.apache.cassandra.service.paxos.cleanup.PaxosStartPrepareCleanup$RequestSerializer.serializedSize(PaxosStartPrepareCleanup.java:147)
> at
> org.apache.cassandra.net.Message$Serializer.payloadSize(Message.java:1067)
> at org.apache.cassandra.net.Message.payloadSize(Message.java:1114)
> at
> org.apache.cassandra.net.Message$Serializer.serializedSize(Message.java:750)
> at org.apache.cassandra.net.Message.serializedSize(Message.java:1094)
> ...
> {code}
> This happens for all three options of {{paxos_state_purging}} and both with
> and without {{storage_compatibility_mode: NONE}}.
> Tests still fail if {{PaxosStartPrepareCleanup}} is changed to use
> {{EndpointState.nullableSerializer}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19120) local consistencies may get timeout if blocking read repair is sending the read repair mutation to other DC
[ https://issues.apache.org/jira/browse/CASSANDRA-19120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17818902#comment-17818902 ] Blake Eggleston commented on CASSANDRA-19120: - +1 if we know the failing tests were failing/flaky previously > 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-19120) local consistencies may get timeout if blocking read repair is sending the read repair mutation to other DC
[
https://issues.apache.org/jira/browse/CASSANDRA-19120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17815816#comment-17815816
]
Blake Eggleston commented on CASSANDRA-19120:
-
{quote}This is not the case for this bug. This bug is that when there is a
pending node, the writePlan for blocking read repair *may* include a remote DC
node as contact node for write only. While we are expecting one more node to
ack, but the ack is filtered out by the shouldBlockOn logic. Then it caused
timeout because all requests have responded.
{quote}
Yes, you’re right. Reviewing this had raised some suspicion that we could
temporarily break read monotonicity when running a read repair with a pending
node, but I don’t think it’s actually a concern.
Anyway, I left some minor feedback on the PR, I’m +1 on committing after it’s
addressed.
> 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-19120) local consistencies may get timeout if blocking read repair is sending the read repair mutation to other DC
[
https://issues.apache.org/jira/browse/CASSANDRA-19120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17811384#comment-17811384
]
Blake Eggleston commented on CASSANDRA-19120:
-
Thanks for your time on this Runtian and Stefan. Feedback is below,
So after the removal of read_repair_chance/dclocal_read_repair_chance in
CASSANDRA-13910, there should never be a case where a DC local read or read
repairs are talking to remote DCs.
First, replicas from remote dcs should not be making it into the contact list.
If we weren’t correctly disregarding their acks in BlockingReadRepair, we’d
have a violation of monotonic read guarantees. So I’d suggest that we filter
remote DC replicas out when constructing the initial replica plan for the read
repair
Second, if we don’t have to worry about remote DCs making it into
BlockingPartitionRepair, we can remove the shouldBlockOn logic from that class,
though we should add something to the effect of
`Preconditions.checkState(!consistencyLevel.isDatacenterLocal() ||
InOurDcTester.{_}endpoints{_}().contains(participant))` in the ctor as a sanity
check. This would also mean the removal of the blockFor decrementing code you
added.
Third, in some situations (ie: when there is a pending node), the
pendingRepairMap will always have fewer items than blockFor, which will mean
the repair will always speculate. To avoid this, I’d proactively add repairs to
the pendingRepair map when this is the case, though it will mean a little
reworking of maybeSendAdditionalWrites.
Let me know what you think. Also, [~samt] does all that seem reasonable to you?
> 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
[jira] [Commented] (CASSANDRA-19016) CEP-15: (C*) per-table transactional configuration
[ https://issues.apache.org/jira/browse/CASSANDRA-19016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17804417#comment-17804417 ] Blake Eggleston commented on CASSANDRA-19016: - PR: [https://github.com/apache/cassandra/pull/3032] > CEP-15: (C*) per-table transactional configuration > -- > > Key: CASSANDRA-19016 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19016 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: Blake Eggleston >Assignee: Blake Eggleston >Priority: Normal > Fix For: 5.x > > > Accord configuration options should be rolled into as few options as > possible, with as few touch points as possible and, with support for > per-table configuration -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19009) CEP-15: (C*/Accord) Schema based fast path reconfiguration
[ https://issues.apache.org/jira/browse/CASSANDRA-19009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Eggleston updated CASSANDRA-19009: Source Control Link: https://github.com/apache/cassandra/commit/38f355ce7f7d5b4f5ed07744283336bc110d6372 Resolution: Fixed Status: Resolved (was: Ready to Commit) > CEP-15: (C*/Accord) Schema based fast path reconfiguration > --- > > Key: CASSANDRA-19009 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19009 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: Blake Eggleston >Assignee: Blake Eggleston >Priority: Normal > Fix For: 5.0.x > > > This adds availability aware accord fast path reconfiguration, as well as > user configurable fast path settings, which are set at the keyspace level and > (optionally) at the table level for increased granularity. > The major parts are: > *Add availability information to cluster metadata* > Accord topology in C* is not stored in cluster metadata, but is meant to > calculated deterministically from cluster metadata state at a given epoch. > This adds the availability data, as well as the failure detector / gossip > listener and state change deduplication to CMS. > *Move C* accord keys/topology from keyspace prefixes to tableid prefixes* > To support per-table fast path settings, topologies and keys need to include > the table id. Since accord topologies could begin to consume a lot of memory > in clusters with a lot of nodes and tables, topology generation has been > updated to reuse previously allocated shards / shard parts where possible, > which will only increase heap sizes when things actually change. > *Make fast path settings configurable via schema* > There are 2.5 strategies: Simple, Parameterized, and InheritKeyspaceSettings. > Simple will use as many available nodes as possible for the fast path > electorate, this is the default for the keyspace fast path strategy. > Parameterized allows you to set a target size, and preferred datacenters for > the FP electorate. InheritKeyspace tells topology generation to just use the > keyspace fast path settings, and is the default for the table fast path > strategy. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19009) CEP-15: (C*/Accord) Schema based fast path reconfiguration
[
https://issues.apache.org/jira/browse/CASSANDRA-19009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17798720#comment-17798720
]
Blake Eggleston commented on CASSANDRA-19009:
-
{quote} * conf/cassandra.yaml
Shouldn't fast_path_update_delay be under the accord? Its in
src/java/org/apache/cassandra/config/AccordSpec.java, so its accord.
fast_path_update_delay{quote}
Can you take another look, I think it's in the right place there.
{quote} *
src/java/org/apache/cassandra/service/accord/AccordFastPathCoordinator.java
isShutdown returns false if the local node isn't in AccordFastPath, so we won't
add ourselves as NORMAL?{quote}
Yes that's intentional, a node not being in AccordFastPath is interpreted as
NORMAL
> CEP-15: (C*/Accord) Schema based fast path reconfiguration
> ---
>
> Key: CASSANDRA-19009
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19009
> Project: Cassandra
> Issue Type: Improvement
> Components: Accord
>Reporter: Blake Eggleston
>Assignee: Blake Eggleston
>Priority: Normal
> Fix For: 5.0.x
>
>
> This adds availability aware accord fast path reconfiguration, as well as
> user configurable fast path settings, which are set at the keyspace level and
> (optionally) at the table level for increased granularity.
> The major parts are:
> *Add availability information to cluster metadata*
> Accord topology in C* is not stored in cluster metadata, but is meant to
> calculated deterministically from cluster metadata state at a given epoch.
> This adds the availability data, as well as the failure detector / gossip
> listener and state change deduplication to CMS.
> *Move C* accord keys/topology from keyspace prefixes to tableid prefixes*
> To support per-table fast path settings, topologies and keys need to include
> the table id. Since accord topologies could begin to consume a lot of memory
> in clusters with a lot of nodes and tables, topology generation has been
> updated to reuse previously allocated shards / shard parts where possible,
> which will only increase heap sizes when things actually change.
> *Make fast path settings configurable via schema*
> There are 2.5 strategies: Simple, Parameterized, and InheritKeyspaceSettings.
> Simple will use as many available nodes as possible for the fast path
> electorate, this is the default for the keyspace fast path strategy.
> Parameterized allows you to set a target size, and preferred datacenters for
> the FP electorate. InheritKeyspace tells topology generation to just use the
> keyspace fast path settings, and is the default for the table fast path
> strategy.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19016) CEP-15: (C*) per-table transactional configuration
[ https://issues.apache.org/jira/browse/CASSANDRA-19016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Eggleston updated CASSANDRA-19016: Reviewers: Ariel Weisberg, David Capwell > CEP-15: (C*) per-table transactional configuration > -- > > Key: CASSANDRA-19016 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19016 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: Blake Eggleston >Assignee: Blake Eggleston >Priority: Normal > Fix For: 5.x > > > Accord configuration options should be rolled into as few options as > possible, with as few touch points as possible and, with support for > per-table configuration -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19016) CEP-15: (C*) per-table transactional configuration
[ https://issues.apache.org/jira/browse/CASSANDRA-19016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Eggleston updated CASSANDRA-19016: Test and Documentation Plan: CI Status: Patch Available (was: Open) [C*|https://github.com/bdeggleston/cassandra/tree/C19016-accord-table-config] [Accord|https://github.com/bdeggleston/cassandra-accord/tree/C19016-accord-table-config] > CEP-15: (C*) per-table transactional configuration > -- > > Key: CASSANDRA-19016 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19016 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: Blake Eggleston >Assignee: Blake Eggleston >Priority: Normal > Fix For: 5.x > > > Accord configuration options should be rolled into as few options as > possible, with as few touch points as possible and, with support for > per-table configuration -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19016) CEP-15: (C*) per-table transactional configuration
[ https://issues.apache.org/jira/browse/CASSANDRA-19016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Eggleston updated CASSANDRA-19016: Change Category: Operability Complexity: Normal Fix Version/s: 5.x Status: Open (was: Triage Needed) > CEP-15: (C*) per-table transactional configuration > -- > > Key: CASSANDRA-19016 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19016 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: Blake Eggleston >Assignee: Blake Eggleston >Priority: Normal > Fix For: 5.x > > > Accord configuration options should be rolled into as few options as > possible, with as few touch points as possible and, with support for > per-table configuration -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19009) CEP-15: (C*/Accord) Schema based fast path reconfiguration
[ https://issues.apache.org/jira/browse/CASSANDRA-19009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Eggleston updated CASSANDRA-19009: Status: Review In Progress (was: Patch Available) > CEP-15: (C*/Accord) Schema based fast path reconfiguration > --- > > Key: CASSANDRA-19009 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19009 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: Blake Eggleston >Assignee: Blake Eggleston >Priority: Normal > Fix For: 5.0.x > > > This adds availability aware accord fast path reconfiguration, as well as > user configurable fast path settings, which are set at the keyspace level and > (optionally) at the table level for increased granularity. > The major parts are: > *Add availability information to cluster metadata* > Accord topology in C* is not stored in cluster metadata, but is meant to > calculated deterministically from cluster metadata state at a given epoch. > This adds the availability data, as well as the failure detector / gossip > listener and state change deduplication to CMS. > *Move C* accord keys/topology from keyspace prefixes to tableid prefixes* > To support per-table fast path settings, topologies and keys need to include > the table id. Since accord topologies could begin to consume a lot of memory > in clusters with a lot of nodes and tables, topology generation has been > updated to reuse previously allocated shards / shard parts where possible, > which will only increase heap sizes when things actually change. > *Make fast path settings configurable via schema* > There are 2.5 strategies: Simple, Parameterized, and InheritKeyspaceSettings. > Simple will use as many available nodes as possible for the fast path > electorate, this is the default for the keyspace fast path strategy. > Parameterized allows you to set a target size, and preferred datacenters for > the FP electorate. InheritKeyspace tells topology generation to just use the > keyspace fast path settings, and is the default for the table fast path > strategy. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19009) CEP-15: (C*/Accord) Schema based fast path reconfiguration
[ https://issues.apache.org/jira/browse/CASSANDRA-19009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Eggleston updated CASSANDRA-19009: Status: Ready to Commit (was: Review In Progress) > CEP-15: (C*/Accord) Schema based fast path reconfiguration > --- > > Key: CASSANDRA-19009 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19009 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: Blake Eggleston >Assignee: Blake Eggleston >Priority: Normal > Fix For: 5.0.x > > > This adds availability aware accord fast path reconfiguration, as well as > user configurable fast path settings, which are set at the keyspace level and > (optionally) at the table level for increased granularity. > The major parts are: > *Add availability information to cluster metadata* > Accord topology in C* is not stored in cluster metadata, but is meant to > calculated deterministically from cluster metadata state at a given epoch. > This adds the availability data, as well as the failure detector / gossip > listener and state change deduplication to CMS. > *Move C* accord keys/topology from keyspace prefixes to tableid prefixes* > To support per-table fast path settings, topologies and keys need to include > the table id. Since accord topologies could begin to consume a lot of memory > in clusters with a lot of nodes and tables, topology generation has been > updated to reuse previously allocated shards / shard parts where possible, > which will only increase heap sizes when things actually change. > *Make fast path settings configurable via schema* > There are 2.5 strategies: Simple, Parameterized, and InheritKeyspaceSettings. > Simple will use as many available nodes as possible for the fast path > electorate, this is the default for the keyspace fast path strategy. > Parameterized allows you to set a target size, and preferred datacenters for > the FP electorate. InheritKeyspace tells topology generation to just use the > keyspace fast path settings, and is the default for the table fast path > strategy. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-19009) CEP-15: (C*/Accord) Schema based fast path reconfiguration
[
https://issues.apache.org/jira/browse/CASSANDRA-19009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17793813#comment-17793813
]
Blake Eggleston edited comment on CASSANDRA-19009 at 12/6/23 4:08 PM:
--
> I do not understand fully is the intention for {{maintenance}} scheduled task
The maintenance scheduled task is for rapid state changes. For instance, if a
node transitioned to DOWN, then back to UP within the update interval, the
UNAVAILABLE update would be executed, but the NORMAL update would be rejected.
The maintenance task is just so we retry in cases like that
was (Author: bdeggleston):
> I do not understand fully is the intention for {{maintenance}} scheduled task
> CEP-15: (C*/Accord) Schema based fast path reconfiguration
> ---
>
> Key: CASSANDRA-19009
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19009
> Project: Cassandra
> Issue Type: Improvement
> Components: Accord
>Reporter: Blake Eggleston
>Assignee: Blake Eggleston
>Priority: Normal
> Fix For: 5.0.x
>
>
> This adds availability aware accord fast path reconfiguration, as well as
> user configurable fast path settings, which are set at the keyspace level and
> (optionally) at the table level for increased granularity.
> The major parts are:
> *Add availability information to cluster metadata*
> Accord topology in C* is not stored in cluster metadata, but is meant to
> calculated deterministically from cluster metadata state at a given epoch.
> This adds the availability data, as well as the failure detector / gossip
> listener and state change deduplication to CMS.
> *Move C* accord keys/topology from keyspace prefixes to tableid prefixes*
> To support per-table fast path settings, topologies and keys need to include
> the table id. Since accord topologies could begin to consume a lot of memory
> in clusters with a lot of nodes and tables, topology generation has been
> updated to reuse previously allocated shards / shard parts where possible,
> which will only increase heap sizes when things actually change.
> *Make fast path settings configurable via schema*
> There are 2.5 strategies: Simple, Parameterized, and InheritKeyspaceSettings.
> Simple will use as many available nodes as possible for the fast path
> electorate, this is the default for the keyspace fast path strategy.
> Parameterized allows you to set a target size, and preferred datacenters for
> the FP electorate. InheritKeyspace tells topology generation to just use the
> keyspace fast path settings, and is the default for the table fast path
> strategy.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19009) CEP-15: (C*/Accord) Schema based fast path reconfiguration
[
https://issues.apache.org/jira/browse/CASSANDRA-19009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17793813#comment-17793813
]
Blake Eggleston commented on CASSANDRA-19009:
-
> I do not understand fully is the intention for {{maintenance}} scheduled task
> CEP-15: (C*/Accord) Schema based fast path reconfiguration
> ---
>
> Key: CASSANDRA-19009
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19009
> Project: Cassandra
> Issue Type: Improvement
> Components: Accord
>Reporter: Blake Eggleston
>Assignee: Blake Eggleston
>Priority: Normal
> Fix For: 5.0.x
>
>
> This adds availability aware accord fast path reconfiguration, as well as
> user configurable fast path settings, which are set at the keyspace level and
> (optionally) at the table level for increased granularity.
> The major parts are:
> *Add availability information to cluster metadata*
> Accord topology in C* is not stored in cluster metadata, but is meant to
> calculated deterministically from cluster metadata state at a given epoch.
> This adds the availability data, as well as the failure detector / gossip
> listener and state change deduplication to CMS.
> *Move C* accord keys/topology from keyspace prefixes to tableid prefixes*
> To support per-table fast path settings, topologies and keys need to include
> the table id. Since accord topologies could begin to consume a lot of memory
> in clusters with a lot of nodes and tables, topology generation has been
> updated to reuse previously allocated shards / shard parts where possible,
> which will only increase heap sizes when things actually change.
> *Make fast path settings configurable via schema*
> There are 2.5 strategies: Simple, Parameterized, and InheritKeyspaceSettings.
> Simple will use as many available nodes as possible for the fast path
> electorate, this is the default for the keyspace fast path strategy.
> Parameterized allows you to set a target size, and preferred datacenters for
> the FP electorate. InheritKeyspace tells topology generation to just use the
> keyspace fast path settings, and is the default for the table fast path
> strategy.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19009) CEP-15: (C*/Accord) Schema based fast path reconfiguration
[ https://issues.apache.org/jira/browse/CASSANDRA-19009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17793064#comment-17793064 ] Blake Eggleston commented on CASSANDRA-19009: - Thanks Alex, updated the branch to eagerly update the fast path with rejections also handled by TCM and address your nits. WDYT about my schema question? > CEP-15: (C*/Accord) Schema based fast path reconfiguration > --- > > Key: CASSANDRA-19009 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19009 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: Blake Eggleston >Assignee: Blake Eggleston >Priority: Normal > Fix For: 5.0.x > > > This adds availability aware accord fast path reconfiguration, as well as > user configurable fast path settings, which are set at the keyspace level and > (optionally) at the table level for increased granularity. > The major parts are: > *Add availability information to cluster metadata* > Accord topology in C* is not stored in cluster metadata, but is meant to > calculated deterministically from cluster metadata state at a given epoch. > This adds the availability data, as well as the failure detector / gossip > listener and state change deduplication to CMS. > *Move C* accord keys/topology from keyspace prefixes to tableid prefixes* > To support per-table fast path settings, topologies and keys need to include > the table id. Since accord topologies could begin to consume a lot of memory > in clusters with a lot of nodes and tables, topology generation has been > updated to reuse previously allocated shards / shard parts where possible, > which will only increase heap sizes when things actually change. > *Make fast path settings configurable via schema* > There are 2.5 strategies: Simple, Parameterized, and InheritKeyspaceSettings. > Simple will use as many available nodes as possible for the fast path > electorate, this is the default for the keyspace fast path strategy. > Parameterized allows you to set a target size, and preferred datacenters for > the FP electorate. InheritKeyspace tells topology generation to just use the > keyspace fast path settings, and is the default for the table fast path > strategy. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18784) CEP-15: Accord - reduce command deps
[ https://issues.apache.org/jira/browse/CASSANDRA-18784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Eggleston updated CASSANDRA-18784: Fix Version/s: 5.x Source Control Link: https://github.com/apache/cassandra/commit/166bdee9bf0688d70eb03d6156604e1ac0038c4d Resolution: Fixed Status: Resolved (was: Ready to Commit) > CEP-15: Accord - reduce command deps > > > Key: CASSANDRA-18784 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18784 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: Blake Eggleston >Assignee: Blake Eggleston >Priority: Normal > Fix For: 5.x > > Attachments: ci_summary.html, result_details.tar.gz > > > Commands do not need to list every known command as a dependency, by taking > deps on the most recently committed commands, and the chain of deps between > them and any uncommitted commands. -- This message was sent by Atlassian Jira (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-18784) CEP-15: Accord - reduce command deps
[ https://issues.apache.org/jira/browse/CASSANDRA-18784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Eggleston updated CASSANDRA-18784: Attachment: ci_summary.html result_details.tar.gz > CEP-15: Accord - reduce command deps > > > Key: CASSANDRA-18784 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18784 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: Blake Eggleston >Assignee: Blake Eggleston >Priority: Normal > Attachments: ci_summary.html, result_details.tar.gz > > > Commands do not need to list every known command as a dependency, by taking > deps on the most recently committed commands, and the chain of deps between > them and any uncommitted commands. -- This message was sent by Atlassian Jira (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-18784) CEP-15: Accord - reduce command deps
[ https://issues.apache.org/jira/browse/CASSANDRA-18784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Eggleston updated CASSANDRA-18784: Status: Ready to Commit (was: Review In Progress) > CEP-15: Accord - reduce command deps > > > Key: CASSANDRA-18784 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18784 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: Blake Eggleston >Assignee: Blake Eggleston >Priority: Normal > > Commands do not need to list every known command as a dependency, by taking > deps on the most recently committed commands, and the chain of deps between > them and any uncommitted commands. -- This message was sent by Atlassian Jira (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-18784) CEP-15: Accord - reduce command deps
[ https://issues.apache.org/jira/browse/CASSANDRA-18784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Eggleston updated CASSANDRA-18784: Status: Review In Progress (was: Patch Available) > CEP-15: Accord - reduce command deps > > > Key: CASSANDRA-18784 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18784 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: Blake Eggleston >Assignee: Blake Eggleston >Priority: Normal > > Commands do not need to list every known command as a dependency, by taking > deps on the most recently committed commands, and the chain of deps between > them and any uncommitted commands. -- This message was sent by Atlassian Jira (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-18784) CEP-15: Accord - reduce command deps
[ https://issues.apache.org/jira/browse/CASSANDRA-18784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17790831#comment-17790831 ] Blake Eggleston commented on CASSANDRA-18784: - C* integration branch: [https://github.com/bdeggleston/cassandra/tree/C18784-reduce-deps-v2] > CEP-15: Accord - reduce command deps > > > Key: CASSANDRA-18784 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18784 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: Blake Eggleston >Assignee: Blake Eggleston >Priority: Normal > > Commands do not need to list every known command as a dependency, by taking > deps on the most recently committed commands, and the chain of deps between > them and any uncommitted commands. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19009) CEP-15: (C*/Accord) Schema based fast path reconfiguration
[
https://issues.apache.org/jira/browse/CASSANDRA-19009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17787402#comment-17787402
]
Blake Eggleston commented on CASSANDRA-19009:
-
With the exception of the schema migration I ask about below, I've pushed up a
commit that should address all comments.
{quote}Add reject to ReconfigureAccordFastPath if there are no accord-enabled
keyspaces, so we do not populate a log with unnecessary transformations
{quote}
Nodes no longer report availability changes for peers they don't co-replicate
ranges with.
{quote}Add debounce to ReconfigureAccordFastPath, which would allow updating
fast path exclusions only once per X amount of time. Maybe we can hold some
sort of
{quote}
Now debounced in 2 spots. First, we wait a few seconds after receiving an
alive/dead event, and only report if we haven't received another event for the
same node in the meantime. We also reject updates that are superseded by more
recently applied updates, so we don't mark the same node unavailable 3 times in
a row.
{quote}we probably need to create a migration process, since right now
fast_path is simply added to SchemaKeyspace, but unfortunately we will have to
do it through schema evolution, since we can not assume that all clusters will
be fresh. Even if adding a field to a local table works out of the box, we
should be careful because using this column will preclude downgrades.
{quote}
So my understanding is that TCM is effectively the source of truth for schema.
Could this be safely achieved by only storing fast path info in the tcm schema?
{quote}We need a garbage collection process for nodes that are excluded from
fast path, too. Right now, we would add a node to the list, and this is more or
less it, but the node might get permanently decomissioned, and we will carry it
around in this list as well. I think decomission (probably FinishLeave), or
even some earlier step, should make sure the node is not present in this list.
Maybe we should even add an assert that when the node is unregistered, it is
not present here, eihter.
{quote}
Updated so removing a node from the directory will automatically remove it from
the fast path config
> CEP-15: (C*/Accord) Schema based fast path reconfiguration
> ---
>
> Key: CASSANDRA-19009
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19009
> Project: Cassandra
> Issue Type: Improvement
> Components: Accord
>Reporter: Blake Eggleston
>Assignee: Blake Eggleston
>Priority: Normal
> Fix For: 5.0.x
>
>
> This adds availability aware accord fast path reconfiguration, as well as
> user configurable fast path settings, which are set at the keyspace level and
> (optionally) at the table level for increased granularity.
> The major parts are:
> *Add availability information to cluster metadata*
> Accord topology in C* is not stored in cluster metadata, but is meant to
> calculated deterministically from cluster metadata state at a given epoch.
> This adds the availability data, as well as the failure detector / gossip
> listener and state change deduplication to CMS.
> *Move C* accord keys/topology from keyspace prefixes to tableid prefixes*
> To support per-table fast path settings, topologies and keys need to include
> the table id. Since accord topologies could begin to consume a lot of memory
> in clusters with a lot of nodes and tables, topology generation has been
> updated to reuse previously allocated shards / shard parts where possible,
> which will only increase heap sizes when things actually change.
> *Make fast path settings configurable via schema*
> There are 2.5 strategies: Simple, Parameterized, and InheritKeyspaceSettings.
> Simple will use as many available nodes as possible for the fast path
> electorate, this is the default for the keyspace fast path strategy.
> Parameterized allows you to set a target size, and preferred datacenters for
> the FP electorate. InheritKeyspace tells topology generation to just use the
> keyspace fast path settings, and is the default for the table fast path
> strategy.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18129) Live migration from Paxos to Accord
[ https://issues.apache.org/jira/browse/CASSANDRA-18129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Eggleston updated CASSANDRA-18129: Change Category: Operability Complexity: Challenging Component/s: Accord Fix Version/s: 5.x Status: Open (was: Triage Needed) > Live migration from Paxos to Accord > --- > > Key: CASSANDRA-18129 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18129 > Project: Cassandra > Issue Type: Sub-task > Components: Accord >Reporter: Ariel Weisberg >Assignee: Ariel Weisberg >Priority: Normal > Labels: pull-request-available > Fix For: 5.x > > Time Spent: 7h 40m > Remaining Estimate: 0h > > This excludes the work necessary to migrate from Accord back to Paxos. > It encompasses the associated nodetool commands to manage migration, state > management to track which tables are migrated for which ranges (and to which > consensus protocol), running repair to complete migration of a range, and on > demand key migration to Accord for keys that are accessed during a range > migration. -- This message was sent by Atlassian Jira (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-18129) Live migration from Paxos to Accord
[ https://issues.apache.org/jira/browse/CASSANDRA-18129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Eggleston updated CASSANDRA-18129: Status: Ready to Commit (was: Review In Progress) +1 > Live migration from Paxos to Accord > --- > > Key: CASSANDRA-18129 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18129 > Project: Cassandra > Issue Type: Sub-task > Components: Accord >Reporter: Ariel Weisberg >Assignee: Ariel Weisberg >Priority: Normal > Labels: pull-request-available > Fix For: 5.x > > Time Spent: 7h 40m > Remaining Estimate: 0h > > This excludes the work necessary to migrate from Accord back to Paxos. > It encompasses the associated nodetool commands to manage migration, state > management to track which tables are migrated for which ranges (and to which > consensus protocol), running repair to complete migration of a range, and on > demand key migration to Accord for keys that are accessed during a range > migration. -- This message was sent by Atlassian Jira (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-18129) Live migration from Paxos to Accord
[ https://issues.apache.org/jira/browse/CASSANDRA-18129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Eggleston updated CASSANDRA-18129: Test and Documentation Plan: ci Status: Patch Available (was: Open) > Live migration from Paxos to Accord > --- > > Key: CASSANDRA-18129 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18129 > Project: Cassandra > Issue Type: Sub-task > Components: Accord >Reporter: Ariel Weisberg >Assignee: Ariel Weisberg >Priority: Normal > Labels: pull-request-available > Fix For: 5.x > > Time Spent: 7h 40m > Remaining Estimate: 0h > > This excludes the work necessary to migrate from Accord back to Paxos. > It encompasses the associated nodetool commands to manage migration, state > management to track which tables are migrated for which ranges (and to which > consensus protocol), running repair to complete migration of a range, and on > demand key migration to Accord for keys that are accessed during a range > migration. -- This message was sent by Atlassian Jira (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-18129) Live migration from Paxos to Accord
[ https://issues.apache.org/jira/browse/CASSANDRA-18129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Eggleston updated CASSANDRA-18129: Status: Review In Progress (was: Patch Available) > Live migration from Paxos to Accord > --- > > Key: CASSANDRA-18129 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18129 > Project: Cassandra > Issue Type: Sub-task > Components: Accord >Reporter: Ariel Weisberg >Assignee: Ariel Weisberg >Priority: Normal > Labels: pull-request-available > Fix For: 5.x > > Time Spent: 7h 40m > Remaining Estimate: 0h > > This excludes the work necessary to migrate from Accord back to Paxos. > It encompasses the associated nodetool commands to manage migration, state > management to track which tables are migrated for which ranges (and to which > consensus protocol), running repair to complete migration of a range, and on > demand key migration to Accord for keys that are accessed during a range > migration. -- This message was sent by Atlassian Jira (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-19016) CEP-15: (C*) per-table transactional configuration
[ https://issues.apache.org/jira/browse/CASSANDRA-19016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Eggleston updated CASSANDRA-19016: Summary: CEP-15: (C*) per-table transactional configuration (was: CEP-15: (C*) add support for per-table configuration) > CEP-15: (C*) per-table transactional configuration > -- > > Key: CASSANDRA-19016 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19016 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: Blake Eggleston >Assignee: Blake Eggleston >Priority: Normal > > Accord configuration options should be rolled into as few options as > possible, with as few touch points as possible and, with support for > per-table configuration -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-19016) CEP-15: (C*) add support for per-table configuration
Blake Eggleston created CASSANDRA-19016: --- Summary: CEP-15: (C*) add support for per-table configuration Key: CASSANDRA-19016 URL: https://issues.apache.org/jira/browse/CASSANDRA-19016 Project: Cassandra Issue Type: Improvement Components: Accord Reporter: Blake Eggleston Assignee: Blake Eggleston Accord configuration options should be rolled into as few options as possible, with as few touch points as possible and, with support for per-table configuration -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-19009) CEP-15: (C*/Accord) Schema based fast path reconfiguration
[ https://issues.apache.org/jira/browse/CASSANDRA-19009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17783833#comment-17783833 ] Blake Eggleston edited comment on CASSANDRA-19009 at 11/8/23 6:00 PM: -- [C*|https://github.com/bdeggleston/cassandra/tree/C19009-accord-fpconfig] [Accord|https://github.com/bdeggleston/cassandra-accord/tree/accord-fp-reconfigure-2] was (Author: bdeggleston): [C*|[https://github.com/bdeggleston/cassandra/tree/C19009-accord-fpconfig]] [Accord|[https://github.com/bdeggleston/cassandra-accord/tree/accord-fp-reconfigure-2]] [CI|[https://app.circleci.com/pipelines/github/bdeggleston/cassandra/345/workflows/227bccbd-255e-4a90-a8d8-d2765e746dd1]] > CEP-15: (C*/Accord) Schema based fast path reconfiguration > --- > > Key: CASSANDRA-19009 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19009 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: Blake Eggleston >Assignee: Blake Eggleston >Priority: Normal > Fix For: 5.0.x > > > This adds availability aware accord fast path reconfiguration, as well as > user configurable fast path settings, which are set at the keyspace level and > (optionally) at the table level for increased granularity. > The major parts are: > *Add availability information to cluster metadata* > Accord topology in C* is not stored in cluster metadata, but is meant to > calculated deterministically from cluster metadata state at a given epoch. > This adds the availability data, as well as the failure detector / gossip > listener and state change deduplication to CMS. > *Move C* accord keys/topology from keyspace prefixes to tableid prefixes* > To support per-table fast path settings, topologies and keys need to include > the table id. Since accord topologies could begin to consume a lot of memory > in clusters with a lot of nodes and tables, topology generation has been > updated to reuse previously allocated shards / shard parts where possible, > which will only increase heap sizes when things actually change. > *Make fast path settings configurable via schema* > There are 2.5 strategies: Simple, Parameterized, and InheritKeyspaceSettings. > Simple will use as many available nodes as possible for the fast path > electorate, this is the default for the keyspace fast path strategy. > Parameterized allows you to set a target size, and preferred datacenters for > the FP electorate. InheritKeyspace tells topology generation to just use the > keyspace fast path settings, and is the default for the table fast path > strategy. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19009) CEP-15: (C*/Accord) Schema based fast path reconfiguration
[ https://issues.apache.org/jira/browse/CASSANDRA-19009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17783833#comment-17783833 ] Blake Eggleston commented on CASSANDRA-19009: - [C*|[https://github.com/bdeggleston/cassandra/tree/C19009-accord-fpconfig]] [Accord|[https://github.com/bdeggleston/cassandra-accord/tree/accord-fp-reconfigure-2]] [CI|[https://app.circleci.com/pipelines/github/bdeggleston/cassandra/345/workflows/227bccbd-255e-4a90-a8d8-d2765e746dd1]] > CEP-15: (C*/Accord) Schema based fast path reconfiguration > --- > > Key: CASSANDRA-19009 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19009 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: Blake Eggleston >Assignee: Blake Eggleston >Priority: Normal > Fix For: 5.0.x > > > This adds availability aware accord fast path reconfiguration, as well as > user configurable fast path settings, which are set at the keyspace level and > (optionally) at the table level for increased granularity. > The major parts are: > *Add availability information to cluster metadata* > Accord topology in C* is not stored in cluster metadata, but is meant to > calculated deterministically from cluster metadata state at a given epoch. > This adds the availability data, as well as the failure detector / gossip > listener and state change deduplication to CMS. > *Move C* accord keys/topology from keyspace prefixes to tableid prefixes* > To support per-table fast path settings, topologies and keys need to include > the table id. Since accord topologies could begin to consume a lot of memory > in clusters with a lot of nodes and tables, topology generation has been > updated to reuse previously allocated shards / shard parts where possible, > which will only increase heap sizes when things actually change. > *Make fast path settings configurable via schema* > There are 2.5 strategies: Simple, Parameterized, and InheritKeyspaceSettings. > Simple will use as many available nodes as possible for the fast path > electorate, this is the default for the keyspace fast path strategy. > Parameterized allows you to set a target size, and preferred datacenters for > the FP electorate. InheritKeyspace tells topology generation to just use the > keyspace fast path settings, and is the default for the table fast path > strategy. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19009) CEP-15: (C*/Accord) Schema based fast path reconfiguration
[ https://issues.apache.org/jira/browse/CASSANDRA-19009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Eggleston updated CASSANDRA-19009: Test and Documentation Plan: ci Status: Patch Available (was: Open) > CEP-15: (C*/Accord) Schema based fast path reconfiguration > --- > > Key: CASSANDRA-19009 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19009 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: Blake Eggleston >Assignee: Blake Eggleston >Priority: Normal > Fix For: 5.0.x > > > This adds availability aware accord fast path reconfiguration, as well as > user configurable fast path settings, which are set at the keyspace level and > (optionally) at the table level for increased granularity. > The major parts are: > *Add availability information to cluster metadata* > Accord topology in C* is not stored in cluster metadata, but is meant to > calculated deterministically from cluster metadata state at a given epoch. > This adds the availability data, as well as the failure detector / gossip > listener and state change deduplication to CMS. > *Move C* accord keys/topology from keyspace prefixes to tableid prefixes* > To support per-table fast path settings, topologies and keys need to include > the table id. Since accord topologies could begin to consume a lot of memory > in clusters with a lot of nodes and tables, topology generation has been > updated to reuse previously allocated shards / shard parts where possible, > which will only increase heap sizes when things actually change. > *Make fast path settings configurable via schema* > There are 2.5 strategies: Simple, Parameterized, and InheritKeyspaceSettings. > Simple will use as many available nodes as possible for the fast path > electorate, this is the default for the keyspace fast path strategy. > Parameterized allows you to set a target size, and preferred datacenters for > the FP electorate. InheritKeyspace tells topology generation to just use the > keyspace fast path settings, and is the default for the table fast path > strategy. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19009) CEP-15: (C*/Accord) Schema based fast path reconfiguration
[ https://issues.apache.org/jira/browse/CASSANDRA-19009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Eggleston updated CASSANDRA-19009: Change Category: Operability Complexity: Normal Fix Version/s: 5.0.x Reviewers: David Capwell Assignee: Blake Eggleston Status: Open (was: Triage Needed) > CEP-15: (C*/Accord) Schema based fast path reconfiguration > --- > > Key: CASSANDRA-19009 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19009 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: Blake Eggleston >Assignee: Blake Eggleston >Priority: Normal > Fix For: 5.0.x > > > This adds availability aware accord fast path reconfiguration, as well as > user configurable fast path settings, which are set at the keyspace level and > (optionally) at the table level for increased granularity. > The major parts are: > *Add availability information to cluster metadata* > Accord topology in C* is not stored in cluster metadata, but is meant to > calculated deterministically from cluster metadata state at a given epoch. > This adds the availability data, as well as the failure detector / gossip > listener and state change deduplication to CMS. > *Move C* accord keys/topology from keyspace prefixes to tableid prefixes* > To support per-table fast path settings, topologies and keys need to include > the table id. Since accord topologies could begin to consume a lot of memory > in clusters with a lot of nodes and tables, topology generation has been > updated to reuse previously allocated shards / shard parts where possible, > which will only increase heap sizes when things actually change. > *Make fast path settings configurable via schema* > There are 2.5 strategies: Simple, Parameterized, and InheritKeyspaceSettings. > Simple will use as many available nodes as possible for the fast path > electorate, this is the default for the keyspace fast path strategy. > Parameterized allows you to set a target size, and preferred datacenters for > the FP electorate. InheritKeyspace tells topology generation to just use the > keyspace fast path settings, and is the default for the table fast path > strategy. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-19009) CEP-15: (C*/Accord) Schema based fast path reconfiguration
Blake Eggleston created CASSANDRA-19009: --- Summary: CEP-15: (C*/Accord) Schema based fast path reconfiguration Key: CASSANDRA-19009 URL: https://issues.apache.org/jira/browse/CASSANDRA-19009 Project: Cassandra Issue Type: Improvement Components: Accord Reporter: Blake Eggleston This adds availability aware accord fast path reconfiguration, as well as user configurable fast path settings, which are set at the keyspace level and (optionally) at the table level for increased granularity. The major parts are: *Add availability information to cluster metadata* Accord topology in C* is not stored in cluster metadata, but is meant to calculated deterministically from cluster metadata state at a given epoch. This adds the availability data, as well as the failure detector / gossip listener and state change deduplication to CMS. *Move C* accord keys/topology from keyspace prefixes to tableid prefixes* To support per-table fast path settings, topologies and keys need to include the table id. Since accord topologies could begin to consume a lot of memory in clusters with a lot of nodes and tables, topology generation has been updated to reuse previously allocated shards / shard parts where possible, which will only increase heap sizes when things actually change. *Make fast path settings configurable via schema* There are 2.5 strategies: Simple, Parameterized, and InheritKeyspaceSettings. Simple will use as many available nodes as possible for the fast path electorate, this is the default for the keyspace fast path strategy. Parameterized allows you to set a target size, and preferred datacenters for the FP electorate. InheritKeyspace tells topology generation to just use the keyspace fast path settings, and is the default for the table fast path strategy. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18929) CEP-15: (C*) Implement TopologySorter to prioritise hosts based on DynamicSnitch and/or topology layout
[ https://issues.apache.org/jira/browse/CASSANDRA-18929?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Eggleston updated CASSANDRA-18929: Status: Ready to Commit (was: Review In Progress) +1 > CEP-15: (C*) Implement TopologySorter to prioritise hosts based on > DynamicSnitch and/or topology layout > --- > > Key: CASSANDRA-18929 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18929 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > Implement TopologySorter to prioritise hosts based on DynamicSnitch and/or > topology layout -- This message was sent by Atlassian Jira (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-18929) CEP-15: (C*) Implement TopologySorter to prioritise hosts based on DynamicSnitch and/or topology layout
[ https://issues.apache.org/jira/browse/CASSANDRA-18929?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Eggleston updated CASSANDRA-18929: Reviewers: Blake Eggleston Status: Review In Progress (was: Patch Available) > CEP-15: (C*) Implement TopologySorter to prioritise hosts based on > DynamicSnitch and/or topology layout > --- > > Key: CASSANDRA-18929 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18929 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > Implement TopologySorter to prioritise hosts based on DynamicSnitch and/or > topology layout -- This message was sent by Atlassian Jira (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-18885) Remove paxos uncommitted data for dropped tables
[ https://issues.apache.org/jira/browse/CASSANDRA-18885?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Eggleston updated CASSANDRA-18885: Test and Documentation Plan: circle Status: Patch Available (was: Open) | [4.1|https://github.com/bdeggleston/cassandra/tree/C18885-dropped-table-paxos-data-4.1] | [circle|https://app.circleci.com/pipelines/github/bdeggleston/cassandra?branch=C18885-dropped-table-paxos-data-4.1] | | [5.0|https://github.com/bdeggleston/cassandra/tree/C18885-dropped-table-paxos-data-5.0] | [circle|https://app.circleci.com/pipelines/github/bdeggleston/cassandra?branch=C18885-dropped-table-paxos-data-5.0] | | [trunk|https://github.com/bdeggleston/cassandra/tree/C18885-dropped-table-paxos-data-trunk] | [circle|https://app.circleci.com/pipelines/github/bdeggleston/cassandra?branch=C18885-dropped-table-paxos-data-trunk] | > Remove paxos uncommitted data for dropped tables > > > Key: CASSANDRA-18885 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18885 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Lightweight Transactions >Reporter: Blake Eggleston >Assignee: Blake Eggleston >Priority: Normal > Fix For: 4.1.x > > > Paxos uncommitted data is not removed once a table has been dropped -- This message was sent by Atlassian Jira (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-18784) CEP-15: Accord - reduce command deps
[ https://issues.apache.org/jira/browse/CASSANDRA-18784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17769726#comment-17769726 ] Blake Eggleston commented on CASSANDRA-18784: - After some discussion with Benedict, I've rewritten the previously posted patch here: https://github.com/belliottsmith/cassandra-accord/pull/7 This complements eviction by actively removing commands from CommandsForKeys so they don't have to be loaded, which should improve loading times and allocations significantly in workloads with high contention. Most of this patch is refactoring commands for keys into a small TimestampsForKey object and 2 sets of CommandsForKey. One that includes all unevicted commands, for use with recovery, and another containing only the commands needed to calculate deps for new operations. PreLoadContext has been updated to support specifying which command timeseries, if any, needs to be loaded for an operation. The command timeseries component is no longer directly updateable, but is updated via a CommandsForKey updater, which can target one or both subsets. On the Cassandra side, this will enable caching blind updates from the CFK listener and flushing to disk when appropriate, without having to first load them into memory. > CEP-15: Accord - reduce command deps > > > Key: CASSANDRA-18784 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18784 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: Blake Eggleston >Assignee: Blake Eggleston >Priority: Normal > > Commands do not need to list every known command as a dependency, by taking > deps on the most recently committed commands, and the chain of deps between > them and any uncommitted commands. -- This message was sent by Atlassian Jira (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-18885) Remove paxos uncommitted data for dropped tables
[ https://issues.apache.org/jira/browse/CASSANDRA-18885?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Eggleston updated CASSANDRA-18885: Change Category: Operability Complexity: Low Hanging Fruit Component/s: Feature/Lightweight Transactions Fix Version/s: 4.1.x Reviewers: Benedict Elliott Smith Status: Open (was: Triage Needed) > Remove paxos uncommitted data for dropped tables > > > Key: CASSANDRA-18885 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18885 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Lightweight Transactions >Reporter: Blake Eggleston >Assignee: Blake Eggleston >Priority: Normal > Fix For: 4.1.x > > > Paxos uncommitted data is not removed once a table has been dropped -- This message was sent by Atlassian Jira (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-18885) Remove paxos uncommitted data for dropped tables
Blake Eggleston created CASSANDRA-18885: --- Summary: Remove paxos uncommitted data for dropped tables Key: CASSANDRA-18885 URL: https://issues.apache.org/jira/browse/CASSANDRA-18885 Project: Cassandra Issue Type: Improvement Reporter: Blake Eggleston Assignee: Blake Eggleston Paxos uncommitted data is not removed once a table has been dropped -- This message was sent by Atlassian Jira (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-18784) CEP-15: Accord - reduce command deps
[ https://issues.apache.org/jira/browse/CASSANDRA-18784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Eggleston updated CASSANDRA-18784: Change Category: Performance Complexity: Normal Component/s: Accord Reviewers: Benedict Elliott Smith Status: Open (was: Triage Needed) > CEP-15: Accord - reduce command deps > > > Key: CASSANDRA-18784 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18784 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: Blake Eggleston >Assignee: Blake Eggleston >Priority: Normal > > Commands do not need to list every known command as a dependency, by taking > deps on the most recently committed commands, and the chain of deps between > them and any uncommitted commands. -- This message was sent by Atlassian Jira (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-18784) CEP-15: Accord - reduce command deps
[ https://issues.apache.org/jira/browse/CASSANDRA-18784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Eggleston updated CASSANDRA-18784: Test and Documentation Plan: circle Status: Patch Available (was: Open) [accord|https://github.com/bdeggleston/cassandra-accord/tree/C18784-reduce-deps] > CEP-15: Accord - reduce command deps > > > Key: CASSANDRA-18784 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18784 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: Blake Eggleston >Assignee: Blake Eggleston >Priority: Normal > > Commands do not need to list every known command as a dependency, by taking > deps on the most recently committed commands, and the chain of deps between > them and any uncommitted commands. -- This message was sent by Atlassian Jira (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-18784) CEP-15: Accord - reduce command deps
Blake Eggleston created CASSANDRA-18784: --- Summary: CEP-15: Accord - reduce command deps Key: CASSANDRA-18784 URL: https://issues.apache.org/jira/browse/CASSANDRA-18784 Project: Cassandra Issue Type: Improvement Reporter: Blake Eggleston Assignee: Blake Eggleston Commands do not need to list every known command as a dependency, by taking deps on the most recently committed commands, and the chain of deps between them and any uncommitted commands. -- This message was sent by Atlassian Jira (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-18663) Fix paxos repair wrap around range handling
[ https://issues.apache.org/jira/browse/CASSANDRA-18663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17742949#comment-17742949 ] Blake Eggleston commented on CASSANDRA-18663: - trunk: https://github.com/bdeggleston/cassandra/tree/C18663-paxos-repair-wrap-around-range-trunk CI: https://app.circleci.com/pipelines/github/bdeggleston/cassandra?branch=C18663-paxos-repair-wrap-around-range-trunk > Fix paxos repair wrap around range handling > --- > > Key: CASSANDRA-18663 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18663 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Repair, Feature/Lightweight Transactions >Reporter: Blake Eggleston >Assignee: Blake Eggleston >Priority: Normal > Fix For: 4.1.x > > > There’s a bug in the paxos repair uncommitted state iterator that causes it > to skip repairing replicated ranges if it encounters keys that are not > covered by the active range, and the active range ends on the minimum token. -- This message was sent by Atlassian Jira (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-18663) Fix paxos repair wrap around range handling
[ https://issues.apache.org/jira/browse/CASSANDRA-18663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17742213#comment-17742213 ] Blake Eggleston edited comment on CASSANDRA-18663 at 7/11/23 11:03 PM: --- branch: https://github.com/bdeggleston/cassandra/tree/C18663-paxos-repair-wrap-around-range CI: https://app.circleci.com/pipelines/github/bdeggleston/cassandra?branch=C18663-paxos-repair-wrap-around-range was (Author: bdeggleston): branch: https://github.com/bdeggleston/cassandra/tree/C18663-paxos-repair-wrap-around-range CI: https://app.circleci.com/pipelines/github/bdeggleston/cassandra?branch=C18663-paxos-repair-wrap-around-range > Fix paxos repair wrap around range handling > --- > > Key: CASSANDRA-18663 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18663 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Repair, Feature/Lightweight Transactions >Reporter: Blake Eggleston >Assignee: Blake Eggleston >Priority: Normal > Fix For: 4.1.x > > > There’s a bug in the paxos repair uncommitted state iterator that causes it > to skip repairing replicated ranges if it encounters keys that are not > covered by the active range, and the active range ends on the minimum token. -- This message was sent by Atlassian Jira (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-18663) Fix paxos repair wrap around range handling
[ https://issues.apache.org/jira/browse/CASSANDRA-18663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Eggleston updated CASSANDRA-18663: Test and Documentation Plan: circle ci Status: Patch Available (was: Open) branch: https://github.com/bdeggleston/cassandra/tree/C18663-paxos-repair-wrap-around-range CI: https://app.circleci.com/pipelines/github/bdeggleston/cassandra?branch=C18663-paxos-repair-wrap-around-range > Fix paxos repair wrap around range handling > --- > > Key: CASSANDRA-18663 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18663 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Repair, Feature/Lightweight Transactions >Reporter: Blake Eggleston >Assignee: Blake Eggleston >Priority: Normal > Fix For: 4.1.x > > > There’s a bug in the paxos repair uncommitted state iterator that causes it > to skip repairing replicated ranges if it encounters keys that are not > covered by the active range, and the active range ends on the minimum token. -- This message was sent by Atlassian Jira (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-18663) Fix paxos repair wrap around range handling
[ https://issues.apache.org/jira/browse/CASSANDRA-18663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Eggleston updated CASSANDRA-18663: Severity: Normal Status: Open (was: Triage Needed) > Fix paxos repair wrap around range handling > --- > > Key: CASSANDRA-18663 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18663 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Repair, Feature/Lightweight Transactions >Reporter: Blake Eggleston >Assignee: Blake Eggleston >Priority: Normal > Fix For: 4.1.x > > > There’s a bug in the paxos repair uncommitted state iterator that causes it > to skip repairing replicated ranges if it encounters keys that are not > covered by the active range, and the active range ends on the minimum token. -- This message was sent by Atlassian Jira (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-18663) Fix paxos repair wrap around range handling
[ https://issues.apache.org/jira/browse/CASSANDRA-18663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Eggleston updated CASSANDRA-18663: Bug Category: Parent values: Correctness(12982) Complexity: Normal Discovered By: Fuzz Test Fix Version/s: 4.1.x Reviewers: Benedict Elliott Smith Since Version: 4.1.0 > Fix paxos repair wrap around range handling > --- > > Key: CASSANDRA-18663 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18663 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Repair, Feature/Lightweight Transactions >Reporter: Blake Eggleston >Assignee: Blake Eggleston >Priority: Normal > Fix For: 4.1.x > > > There’s a bug in the paxos repair uncommitted state iterator that causes it > to skip repairing replicated ranges if it encounters keys that are not > covered by the active range, and the active range ends on the minimum token. -- This message was sent by Atlassian Jira (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-18663) Fix paxos repair wrap around range handling
Blake Eggleston created CASSANDRA-18663: --- Summary: Fix paxos repair wrap around range handling Key: CASSANDRA-18663 URL: https://issues.apache.org/jira/browse/CASSANDRA-18663 Project: Cassandra Issue Type: Bug Components: Consistency/Repair, Feature/Lightweight Transactions Reporter: Blake Eggleston Assignee: Blake Eggleston There’s a bug in the paxos repair uncommitted state iterator that causes it to skip repairing replicated ranges if it encounters keys that are not covered by the active range, and the active range ends on the minimum token. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-17101) CEP-15: (C*) Topology integration
[ https://issues.apache.org/jira/browse/CASSANDRA-17101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Eggleston reassigned CASSANDRA-17101: --- Assignee: Blake Eggleston > CEP-15: (C*) Topology integration > - > > Key: CASSANDRA-17101 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17101 > Project: Cassandra > Issue Type: New Feature > Components: Accord >Reporter: Benedict Elliott Smith >Assignee: Blake Eggleston >Priority: Normal > > Integrate Accord with Cassandra’s topology system: translate the ring to an > Accord topology, and integrate Accord with Bootstrap, Replace and Unbootstrap. -- This message was sent by Atlassian Jira (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-18444) CEP-15: (C*) Transactional Metadata Integration
[ https://issues.apache.org/jira/browse/CASSANDRA-18444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17725509#comment-17725509 ] Blake Eggleston commented on CASSANDRA-18444: - with bootstrap integration: [C*|https://github.com/bdeggleston/cassandra/tree/bootstrap-integration] [accord|https://github.com/bdeggleston/cassandra-accord/tree/bootstrap-integration] > CEP-15: (C*) Transactional Metadata Integration > --- > > Key: CASSANDRA-18444 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18444 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: Blake Eggleston >Assignee: Blake Eggleston >Priority: Normal > Fix For: 5.0 > > > Integration transactional metadata with accord. TCM should update Accord > topology and schema, and Accord epochs should map to tcm epochs -- This message was sent by Atlassian Jira (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-18047) fix flaky o.a.c.distributed.test.PaxosRepair2Test.paxosRepairHistoryIsntUpdatedInForcedRepair
[
https://issues.apache.org/jira/browse/CASSANDRA-18047?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Blake Eggleston updated CASSANDRA-18047:
Status: Ready to Commit (was: Review In Progress)
LGTM, thanks
> fix flaky
> o.a.c.distributed.test.PaxosRepair2Test.paxosRepairHistoryIsntUpdatedInForcedRepair
> -
>
> Key: CASSANDRA-18047
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18047
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Stefan Miklosovic
>Assignee: Jon Meredith
>Priority: Normal
> Fix For: 4.1.x, 5.x
>
>
> This test was introduced by CASSANDRA-18029
>
> {code:java}
> junit.framework.AssertionFailedError: Repair failed with errors: [Repair
> session 864c53d0-61fe-11ed-935f-5103a8e332f7 for range
> [(-3074457345618258603,3074457345618258601],
> (9223372036854775805,-3074457345618258603],
> (3074457345618258601,9223372036854775805]] failed with error UNKNOWN failure
> response from /127.0.0.3:7012, Repair command #1 finished with error] at
> org.apache.cassandra.distributed.test.PaxosRepair2Test.lambda$repair$54f7d7c2$1(PaxosRepair2Test.java:186)
> at org.apache.cassandra.concurrent.FutureTask$1.call(FutureTask.java:96) at
> org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:61) at
> org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:71) at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> different error:
> {code:java}
> junit.framework.AssertionFailedError: Repair failed with errors: [Endpoint
> not alive: /127.0.0.3:7012, Repair command #1 finished with error]
> at
> org.apache.cassandra.distributed.test.PaxosRepair2Test.lambda$repair$54f7d7c2$1(PaxosRepair2Test.java:186)
> at org.apache.cassandra.concurrent.FutureTask$1.call(FutureTask.java:96)
> at org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:61)
> at org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:71)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> {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-18047) fix flaky o.a.c.distributed.test.PaxosRepair2Test.paxosRepairHistoryIsntUpdatedInForcedRepair
[
https://issues.apache.org/jira/browse/CASSANDRA-18047?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Blake Eggleston updated CASSANDRA-18047:
Test and Documentation Plan: circle
Status: Patch Available (was: In Progress)
> fix flaky
> o.a.c.distributed.test.PaxosRepair2Test.paxosRepairHistoryIsntUpdatedInForcedRepair
> -
>
> Key: CASSANDRA-18047
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18047
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Stefan Miklosovic
>Assignee: Jon Meredith
>Priority: Normal
> Fix For: 4.1.x, 5.x
>
>
> This test was introduced by CASSANDRA-18029
>
> {code:java}
> junit.framework.AssertionFailedError: Repair failed with errors: [Repair
> session 864c53d0-61fe-11ed-935f-5103a8e332f7 for range
> [(-3074457345618258603,3074457345618258601],
> (9223372036854775805,-3074457345618258603],
> (3074457345618258601,9223372036854775805]] failed with error UNKNOWN failure
> response from /127.0.0.3:7012, Repair command #1 finished with error] at
> org.apache.cassandra.distributed.test.PaxosRepair2Test.lambda$repair$54f7d7c2$1(PaxosRepair2Test.java:186)
> at org.apache.cassandra.concurrent.FutureTask$1.call(FutureTask.java:96) at
> org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:61) at
> org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:71) at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> different error:
> {code:java}
> junit.framework.AssertionFailedError: Repair failed with errors: [Endpoint
> not alive: /127.0.0.3:7012, Repair command #1 finished with error]
> at
> org.apache.cassandra.distributed.test.PaxosRepair2Test.lambda$repair$54f7d7c2$1(PaxosRepair2Test.java:186)
> at org.apache.cassandra.concurrent.FutureTask$1.call(FutureTask.java:96)
> at org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:61)
> at org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:71)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> {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-18047) fix flaky o.a.c.distributed.test.PaxosRepair2Test.paxosRepairHistoryIsntUpdatedInForcedRepair
[
https://issues.apache.org/jira/browse/CASSANDRA-18047?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Blake Eggleston updated CASSANDRA-18047:
Reviewers: Blake Eggleston, Blake Eggleston (was: Caleb Rackliffe)
Blake Eggleston, Blake Eggleston (was: Blake Eggleston)
Status: Review In Progress (was: Patch Available)
> fix flaky
> o.a.c.distributed.test.PaxosRepair2Test.paxosRepairHistoryIsntUpdatedInForcedRepair
> -
>
> Key: CASSANDRA-18047
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18047
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Stefan Miklosovic
>Assignee: Jon Meredith
>Priority: Normal
> Fix For: 4.1.x, 5.x
>
>
> This test was introduced by CASSANDRA-18029
>
> {code:java}
> junit.framework.AssertionFailedError: Repair failed with errors: [Repair
> session 864c53d0-61fe-11ed-935f-5103a8e332f7 for range
> [(-3074457345618258603,3074457345618258601],
> (9223372036854775805,-3074457345618258603],
> (3074457345618258601,9223372036854775805]] failed with error UNKNOWN failure
> response from /127.0.0.3:7012, Repair command #1 finished with error] at
> org.apache.cassandra.distributed.test.PaxosRepair2Test.lambda$repair$54f7d7c2$1(PaxosRepair2Test.java:186)
> at org.apache.cassandra.concurrent.FutureTask$1.call(FutureTask.java:96) at
> org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:61) at
> org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:71) at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> different error:
> {code:java}
> junit.framework.AssertionFailedError: Repair failed with errors: [Endpoint
> not alive: /127.0.0.3:7012, Repair command #1 finished with error]
> at
> org.apache.cassandra.distributed.test.PaxosRepair2Test.lambda$repair$54f7d7c2$1(PaxosRepair2Test.java:186)
> at org.apache.cassandra.concurrent.FutureTask$1.call(FutureTask.java:96)
> at org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:61)
> at org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:71)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> {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-18444) CEP-15: (C*) Transactional Metadata Integration
[ https://issues.apache.org/jira/browse/CASSANDRA-18444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Eggleston updated CASSANDRA-18444: Test and Documentation Plan: circle Status: Patch Available (was: Open) [C*|https://github.com/bdeggleston/cassandra/tree/C18444-tcm-integration] [accord|https://github.com/bdeggleston/cassandra-accord/tree/C18444-tcm-integration] > CEP-15: (C*) Transactional Metadata Integration > --- > > Key: CASSANDRA-18444 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18444 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: Blake Eggleston >Assignee: Blake Eggleston >Priority: Normal > Fix For: 5.0 > > > Integration transactional metadata with accord. TCM should update Accord > topology and schema, and Accord epochs should map to tcm epochs -- This message was sent by Atlassian Jira (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-18444) CEP-15: (C*) Transactional Metadata Integration
[ https://issues.apache.org/jira/browse/CASSANDRA-18444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Eggleston updated CASSANDRA-18444: Change Category: Operability Complexity: Challenging Fix Version/s: 5.0 Status: Open (was: Triage Needed) > CEP-15: (C*) Transactional Metadata Integration > --- > > Key: CASSANDRA-18444 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18444 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: Blake Eggleston >Assignee: Blake Eggleston >Priority: Normal > Fix For: 5.0 > > > Integration transactional metadata with accord. TCM should update Accord > topology and schema, and Accord epochs should map to tcm epochs -- This message was sent by Atlassian Jira (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-18444) CEP-15: (C*) Transactional Metadata Integration
Blake Eggleston created CASSANDRA-18444: --- Summary: CEP-15: (C*) Transactional Metadata Integration Key: CASSANDRA-18444 URL: https://issues.apache.org/jira/browse/CASSANDRA-18444 Project: Cassandra Issue Type: Improvement Components: Accord Reporter: Blake Eggleston Assignee: Blake Eggleston Integration transactional metadata with accord. TCM should update Accord topology and schema, and Accord epochs should map to tcm epochs -- This message was sent by Atlassian Jira (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-18364) CEP-15: (C*) Accord message processing should avoid being passed on to a Stage and run directly in the messageing handler
[ https://issues.apache.org/jira/browse/CASSANDRA-18364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Eggleston updated CASSANDRA-18364: Reviewers: Ariel Weisberg, Benedict Elliott Smith > CEP-15: (C*) Accord message processing should avoid being passed on to a > Stage and run directly in the messageing handler > - > > Key: CASSANDRA-18364 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18364 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Labels: pull-request-available > Fix For: 5.x > > Time Spent: 1h 10m > Remaining Estimate: 0h > > Accord message processing should avoid being passed on to a Stage and run > directly in the messageing handler. This logic should validate that all > messages are non-blocking and async handle replies. -- This message was sent by Atlassian Jira (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-18324) CEP-15: (C*) Head of line blocking of Txn causes large latencies and some Txn to no longer make progress
[ https://issues.apache.org/jira/browse/CASSANDRA-18324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Eggleston updated CASSANDRA-18324: Change Category: Performance Complexity: Normal Fix Version/s: 5.0 Status: Open (was: Triage Needed) > CEP-15: (C*) Head of line blocking of Txn causes large latencies and some Txn > to no longer make progress > > > Key: CASSANDRA-18324 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18324 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: Blake Eggleston >Assignee: Blake Eggleston >Priority: Normal > Fix For: 5.0 > > > Accord perf tests discovered an issue where a command becomes stuck in the > Preaccept phase and dependent operations aren't able to make progress -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-18324) CEP-15: (C*) Head of line blocking of Txn causes large latencies and some Txn to no longer make progress
Blake Eggleston created CASSANDRA-18324: --- Summary: CEP-15: (C*) Head of line blocking of Txn causes large latencies and some Txn to no longer make progress Key: CASSANDRA-18324 URL: https://issues.apache.org/jira/browse/CASSANDRA-18324 Project: Cassandra Issue Type: Improvement Components: Accord Reporter: Blake Eggleston Assignee: Blake Eggleston Accord perf tests discovered an issue where a command becomes stuck in the Preaccept phase and dependent operations aren't able to make progress -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17412) CEP-15: (Accord) Initial Cassandra Integration
[ https://issues.apache.org/jira/browse/CASSANDRA-17412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Eggleston updated CASSANDRA-17412: Fix Version/s: 5.x Source Control Link: https://github.com/apache/cassandra/commit/f7fb5325925754a627694ba5e0c03c9432a5c3d6 Resolution: Fixed Status: Resolved (was: Ready to Commit) > CEP-15: (Accord) Initial Cassandra Integration > -- > > Key: CASSANDRA-17412 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17412 > Project: Cassandra > Issue Type: New Feature > Components: Accord >Reporter: Blake Eggleston >Assignee: Blake Eggleston >Priority: Normal > Fix For: 5.x > > > Integrate the accord messages into Cassandra and implement a basic Cassandra > to accord topology mapping. -- This message was sent by Atlassian Jira (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-17412) CEP-15: (Accord) Initial Cassandra Integration
[ https://issues.apache.org/jira/browse/CASSANDRA-17412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Eggleston updated CASSANDRA-17412: Status: Ready to Commit (was: Review In Progress) > CEP-15: (Accord) Initial Cassandra Integration > -- > > Key: CASSANDRA-17412 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17412 > Project: Cassandra > Issue Type: New Feature > Components: Accord >Reporter: Blake Eggleston >Assignee: Blake Eggleston >Priority: Normal > > Integrate the accord messages into Cassandra and implement a basic Cassandra > to accord topology mapping. -- This message was sent by Atlassian Jira (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-17412) CEP-15: (Accord) Initial Cassandra Integration
[ https://issues.apache.org/jira/browse/CASSANDRA-17412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Eggleston updated CASSANDRA-17412: Reviewers: Benedict Elliott Smith, David Capwell (was: Benedict Elliott Smith) Status: Review In Progress (was: Patch Available) > CEP-15: (Accord) Initial Cassandra Integration > -- > > Key: CASSANDRA-17412 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17412 > Project: Cassandra > Issue Type: New Feature > Components: Accord >Reporter: Blake Eggleston >Assignee: Blake Eggleston >Priority: Normal > > Integrate the accord messages into Cassandra and implement a basic Cassandra > to accord topology mapping. -- This message was sent by Atlassian Jira (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-18192) Accord - refactor transaction state storage
[ https://issues.apache.org/jira/browse/CASSANDRA-18192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Eggleston updated CASSANDRA-18192: Source Control Link: https://github.com/apache/cassandra/commit/3374d91c4a86bb7a77e65e67c6c45d074512fbc4 Resolution: Fixed Status: Resolved (was: Ready to Commit) > Accord - refactor transaction state storage > --- > > Key: CASSANDRA-18192 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18192 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: Blake Eggleston >Assignee: Blake Eggleston >Priority: Normal > Fix For: 5.x > > > Refactor accord state to be immutable with explicit transitions between each > state. This should also address the occasional errors encountered during > field updates -- This message was sent by Atlassian Jira (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-18004) CEP-15: (C*/Accord) - remove futures
[ https://issues.apache.org/jira/browse/CASSANDRA-18004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Eggleston updated CASSANDRA-18004: Fix Version/s: 5.0 Source Control Link: https://github.com/apache/cassandra/commit/fa10af834e750887be53c33d3eebb6d7d3606c1b Resolution: Fixed Status: Resolved (was: Ready to Commit) > CEP-15: (C*/Accord) - remove futures > > > Key: CASSANDRA-18004 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18004 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: Blake Eggleston >Assignee: Blake Eggleston >Priority: Normal > Fix For: 5.0 > > > Remove futures in favor of async chain -- This message was sent by Atlassian Jira (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-18192) Accord - refactor transaction state storage
[ https://issues.apache.org/jira/browse/CASSANDRA-18192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Eggleston updated CASSANDRA-18192: Status: Ready to Commit (was: Review In Progress) > Accord - refactor transaction state storage > --- > > Key: CASSANDRA-18192 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18192 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: Blake Eggleston >Assignee: Blake Eggleston >Priority: Normal > Fix For: 5.x > > > Refactor accord state to be immutable with explicit transitions between each > state. This should also address the occasional errors encountered during > field updates -- This message was sent by Atlassian Jira (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-18004) CEP-15: (C*/Accord) - remove futures
[ https://issues.apache.org/jira/browse/CASSANDRA-18004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Eggleston updated CASSANDRA-18004: Reviewers: Benedict Elliott Smith, David Capwell (was: Benedict Elliott Smith) Status: Review In Progress (was: Patch Available) > CEP-15: (C*/Accord) - remove futures > > > Key: CASSANDRA-18004 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18004 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: Blake Eggleston >Assignee: Blake Eggleston >Priority: Normal > > Remove futures in favor of async chain -- This message was sent by Atlassian Jira (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-18004) CEP-15: (C*/Accord) - remove futures
[ https://issues.apache.org/jira/browse/CASSANDRA-18004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Eggleston updated CASSANDRA-18004: Status: Ready to Commit (was: Review In Progress) > CEP-15: (C*/Accord) - remove futures > > > Key: CASSANDRA-18004 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18004 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: Blake Eggleston >Assignee: Blake Eggleston >Priority: Normal > > Remove futures in favor of async chain -- This message was sent by Atlassian Jira (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-18258) Add test conf for JDK17
[
https://issues.apache.org/jira/browse/CASSANDRA-18258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17691242#comment-17691242
]
Blake Eggleston commented on CASSANDRA-18258:
-
{quote}I just don't see the purpose of having a separate IDE profile for the
higher JDK{quote}
That was added because the java 11 needed --add-exports etc, and those weren't
compatible with java 8. Agree it would be best if we didn't need separate
profiles
> Add test conf for JDK17
> ---
>
> Key: CASSANDRA-18258
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18258
> Project: Cassandra
> Issue Type: Task
> Components: Local/Config
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.x
>
>
> Post CASSANDRA-18252 and CASSANDRA-18179 we will be able to compile current
> trunk with JDK17 but in order to start Cassandra and test it we will need
> also our conf files updated with some preliminary conf for test purposes.
> This ticket will be used to add those to current trunk
--
This message was sent by Atlassian Jira
(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-18194) PaxosPrepare may add instances to the Electorate that are not in gossip
[ https://issues.apache.org/jira/browse/CASSANDRA-18194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Eggleston updated CASSANDRA-18194: Reviewers: Blake Eggleston, Blake Eggleston Blake Eggleston, Blake Eggleston (was: Blake Eggleston) Status: Review In Progress (was: Patch Available) > PaxosPrepare may add instances to the Electorate that are not in gossip > --- > > Key: CASSANDRA-18194 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18194 > Project: Cassandra > Issue Type: Bug > Components: Feature/Lightweight Transactions >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 4.1.x > > > org.apache.cassandra.service.paxos.PaxosPrepare.RequestHandler#execute is > given a list of electorate from the peer and attempts to compute its own, > then replies back with this set. > On the peer side, we then have the set we sent and the set from the other > instance... we then fetch the EndpointState from Gossiper and store into a > Map, a map we later attempt to inject into Gossip. > It is possible that Gossiper does not know about the instance yet, so returns > a null; causing a NullPointerException in downstream 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-18194) PaxosPrepare may add instances to the Electorate that are not in gossip
[ https://issues.apache.org/jira/browse/CASSANDRA-18194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Eggleston updated CASSANDRA-18194: Status: Ready to Commit (was: Review In Progress) +1 thanks > PaxosPrepare may add instances to the Electorate that are not in gossip > --- > > Key: CASSANDRA-18194 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18194 > Project: Cassandra > Issue Type: Bug > Components: Feature/Lightweight Transactions >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 4.1.x > > > org.apache.cassandra.service.paxos.PaxosPrepare.RequestHandler#execute is > given a list of electorate from the peer and attempts to compute its own, > then replies back with this set. > On the peer side, we then have the set we sent and the set from the other > instance... we then fetch the EndpointState from Gossiper and store into a > Map, a map we later attempt to inject into Gossip. > It is possible that Gossiper does not know about the instance yet, so returns > a null; causing a NullPointerException in downstream 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] [Created] (CASSANDRA-18192) Accord - refactor transaction state storage
Blake Eggleston created CASSANDRA-18192: --- Summary: Accord - refactor transaction state storage Key: CASSANDRA-18192 URL: https://issues.apache.org/jira/browse/CASSANDRA-18192 Project: Cassandra Issue Type: Improvement Reporter: Blake Eggleston Assignee: Blake Eggleston Refactor accord state to be immutable with explicit transitions between each state. This should also address the occasional errors encountered during field updates -- This message was sent by Atlassian Jira (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-18086) Bug fix for 'wait' time to be in nanoseconds for consistency instead of microseconds
[ https://issues.apache.org/jira/browse/CASSANDRA-18086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17644075#comment-17644075 ] Blake Eggleston commented on CASSANDRA-18086: - LGTM, thanks > Bug fix for 'wait' time to be in nanoseconds for consistency instead of > microseconds > > > Key: CASSANDRA-18086 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18086 > Project: Cassandra > Issue Type: Bug > Components: Feature/Lightweight Transactions >Reporter: Marianne Lyne Manaog >Assignee: Marianne Lyne Manaog >Priority: Normal > Fix For: 4.1.x, 4.x > > Time Spent: 20m > Remaining Estimate: 0h > > While working on benchmarking Paxos improvements in OSS Cassandra, > [~benedict] was asked to review the work and thus found that the wait time > was input in microseconds but then output incorrectly in the > ContentionStrategy.java file, i.e., by summing up a wait time in nanoseconds > with another wait time in microseconds (two different units used mistakenly). > So, Benedict suggested the fix whereby the output wait time was then enforced > to be consistently in nanoseconds. -- This message was sent by Atlassian Jira (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-18086) Bug fix for 'wait' time to be in nanoseconds for consistency instead of microseconds
[ https://issues.apache.org/jira/browse/CASSANDRA-18086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Eggleston updated CASSANDRA-18086: Reviewers: Ariel Weisberg, Blake Eggleston, Josh McKenzie, Blake Eggleston (was: Ariel Weisberg, Blake Eggleston, Josh McKenzie) Ariel Weisberg, Blake Eggleston, Josh McKenzie, Blake Eggleston (was: Ariel Weisberg, Blake Eggleston, Josh McKenzie) Status: Review In Progress (was: Patch Available) > Bug fix for 'wait' time to be in nanoseconds for consistency instead of > microseconds > > > Key: CASSANDRA-18086 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18086 > Project: Cassandra > Issue Type: Bug > Components: Feature/Lightweight Transactions >Reporter: Marianne Lyne Manaog >Assignee: Marianne Lyne Manaog >Priority: Normal > Fix For: 4.1.x, 4.x > > Time Spent: 20m > Remaining Estimate: 0h > > While working on benchmarking Paxos improvements in OSS Cassandra, > [~benedict] was asked to review the work and thus found that the wait time > was input in microseconds but then output incorrectly in the > ContentionStrategy.java file, i.e., by summing up a wait time in nanoseconds > with another wait time in microseconds (two different units used mistakenly). > So, Benedict suggested the fix whereby the output wait time was then enforced > to be consistently in nanoseconds. -- This message was sent by Atlassian Jira (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-18004) CEP-15: (C*/Accord) - remove futures
[ https://issues.apache.org/jira/browse/CASSANDRA-18004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Eggleston updated CASSANDRA-18004: Reviewers: Benedict Elliott Smith > CEP-15: (C*/Accord) - remove futures > > > Key: CASSANDRA-18004 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18004 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: Blake Eggleston >Assignee: Blake Eggleston >Priority: Normal > > Remove futures in favor of async chain -- This message was sent by Atlassian Jira (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-18004) CEP-15: (C*/Accord) - remove futures
[ https://issues.apache.org/jira/browse/CASSANDRA-18004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Eggleston updated CASSANDRA-18004: Test and Documentation Plan: circle Status: Patch Available (was: Open) [accord|https://github.com/bdeggleston/cassandra-accord/tree/async-chain] [cassandra|https://github.com/bdeggleston/cassandra/tree/async-chain] As agreed in another PR, this replaces the single consumer uses of future with AsyncChain. This saves some work, and requires callbacks are supplied _before_ starting an async computation, but still offers the safeguards provided by futures. The initial AsyncChain implementation was suggested and supplied by [~benedict], and is mostly intact here, with some additional bells and whistles. There were some places where async chain didn't make sense, specifically places where we didn't know all of the listeners up front and/or there were multiple listeners. Since we still don't need everything offered by Future in those cases, and In the interest of removing accord's dependency on C*, I added AsyncNotifier, which supports subscribing to notifications from an async process after it's been started, like a future, but without cancellation or blocking get, etc. C* integration of AsyncChain was pretty minimal, but for consistency I'l also updated the integration to use AsyncNotifier, which touched a lot more. The functional changes and member/method renaming are in 2 commits to make reviewing a bit easier. > CEP-15: (C*/Accord) - remove futures > > > Key: CASSANDRA-18004 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18004 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: Blake Eggleston >Assignee: Blake Eggleston >Priority: Normal > > Remove futures in favor of async chain -- This message was sent by Atlassian Jira (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-18004) CEP-15: (C*/Accord) - remove futures
[ https://issues.apache.org/jira/browse/CASSANDRA-18004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Eggleston updated CASSANDRA-18004: Change Category: Semantic Complexity: Normal Status: Open (was: Triage Needed) > CEP-15: (C*/Accord) - remove futures > > > Key: CASSANDRA-18004 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18004 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: Blake Eggleston >Assignee: Blake Eggleston >Priority: Normal > > Remove futures in favor of async chain -- This message was sent by Atlassian Jira (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-18004) CEP-15: (C*/Accord) - remove futures
Blake Eggleston created CASSANDRA-18004: --- Summary: CEP-15: (C*/Accord) - remove futures Key: CASSANDRA-18004 URL: https://issues.apache.org/jira/browse/CASSANDRA-18004 Project: Cassandra Issue Type: Improvement Components: Accord Reporter: Blake Eggleston Assignee: Blake Eggleston Remove futures in favor of async chain -- This message was sent by Atlassian Jira (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-17908) IllegalArgumentException in Gossiper#order due to concurrent mutations to elements being applied
[
https://issues.apache.org/jira/browse/CASSANDRA-17908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Blake Eggleston updated CASSANDRA-17908:
Status: Ready to Commit (was: Review In Progress)
+1
> IllegalArgumentException in Gossiper#order due to concurrent mutations to
> elements being applied
>
>
> Key: CASSANDRA-17908
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17908
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Gossip
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: 4.1.x
>
>
> org.apache.cassandra.gms.Gossiper#order was added due to sub-systems
> depending on a happens-before relationship of events even though Gossip does
> not provide such ordering… to help out we “order” the events discovered by
> gossip so we apply them in a predictable order… This has been found to have
> issues where we add the elements into the global state and under some
> conditions they get mutated causing ordering to fail
> {code}
> ERROR 2022-09-01T19:04:24,789 [GossipStage:1]
> org.apache.cassandra.service.CassandraDaemon:234 - Exception in thread
> Thread[GossipStage:1,5,main]
> java.lang.IllegalArgumentException: Comparison method violates its general
> contract!
> at java.util.TimSort.mergeLo(TimSort.java:777)
> at java.util.TimSort.mergeAt(TimSort.java:514)
> at java.util.TimSort.mergeForceCollapse(TimSort.java:457)
> at java.util.TimSort.sort(TimSort.java:254)
> at java.util.Arrays.sort(Arrays.java:1512)
> at java.util.ArrayList.sort(ArrayList.java:1464)
> at java.util.Collections.sort(Collections.java:177)
> at org.apache.cassandra.gms.Gossiper.order(Gossiper.java:1327)
> at org.apache.cassandra.gms.Gossiper.applyStateLocally(Gossiper.java:1334)
> at
> org.apache.cassandra.gms.GossipDigestAck2VerbHandler.doVerb(GossipDigestAck2VerbHandler.java:49)
>
> at
> org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:70)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>
> at
> org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:116)
>
> at java.lang.Thread.run(Thread.java:750) [?:1.8.0_345]
> {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-17908) IllegalArgumentException in Gossiper#order due to concurrent mutations to elements being applied
[
https://issues.apache.org/jira/browse/CASSANDRA-17908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Blake Eggleston updated CASSANDRA-17908:
Reviewers: Blake Eggleston
> IllegalArgumentException in Gossiper#order due to concurrent mutations to
> elements being applied
>
>
> Key: CASSANDRA-17908
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17908
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Gossip
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: 4.1.x
>
>
> org.apache.cassandra.gms.Gossiper#order was added due to sub-systems
> depending on a happens-before relationship of events even though Gossip does
> not provide such ordering… to help out we “order” the events discovered by
> gossip so we apply them in a predictable order… This has been found to have
> issues where we add the elements into the global state and under some
> conditions they get mutated causing ordering to fail
> {code}
> ERROR 2022-09-01T19:04:24,789 [GossipStage:1]
> org.apache.cassandra.service.CassandraDaemon:234 - Exception in thread
> Thread[GossipStage:1,5,main]
> java.lang.IllegalArgumentException: Comparison method violates its general
> contract!
> at java.util.TimSort.mergeLo(TimSort.java:777)
> at java.util.TimSort.mergeAt(TimSort.java:514)
> at java.util.TimSort.mergeForceCollapse(TimSort.java:457)
> at java.util.TimSort.sort(TimSort.java:254)
> at java.util.Arrays.sort(Arrays.java:1512)
> at java.util.ArrayList.sort(ArrayList.java:1464)
> at java.util.Collections.sort(Collections.java:177)
> at org.apache.cassandra.gms.Gossiper.order(Gossiper.java:1327)
> at org.apache.cassandra.gms.Gossiper.applyStateLocally(Gossiper.java:1334)
> at
> org.apache.cassandra.gms.GossipDigestAck2VerbHandler.doVerb(GossipDigestAck2VerbHandler.java:49)
>
> at
> org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:70)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>
> at
> org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:116)
>
> at java.lang.Thread.run(Thread.java:750) [?:1.8.0_345]
> {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-17908) IllegalArgumentException in Gossiper#order due to concurrent mutations to elements being applied
[
https://issues.apache.org/jira/browse/CASSANDRA-17908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Blake Eggleston updated CASSANDRA-17908:
Reviewers: Blake Eggleston, Blake Eggleston (was: Blake Eggleston)
Blake Eggleston, Blake Eggleston (was: Blake Eggleston)
Status: Review In Progress (was: Patch Available)
> IllegalArgumentException in Gossiper#order due to concurrent mutations to
> elements being applied
>
>
> Key: CASSANDRA-17908
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17908
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Gossip
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: 4.1.x
>
>
> org.apache.cassandra.gms.Gossiper#order was added due to sub-systems
> depending on a happens-before relationship of events even though Gossip does
> not provide such ordering… to help out we “order” the events discovered by
> gossip so we apply them in a predictable order… This has been found to have
> issues where we add the elements into the global state and under some
> conditions they get mutated causing ordering to fail
> {code}
> ERROR 2022-09-01T19:04:24,789 [GossipStage:1]
> org.apache.cassandra.service.CassandraDaemon:234 - Exception in thread
> Thread[GossipStage:1,5,main]
> java.lang.IllegalArgumentException: Comparison method violates its general
> contract!
> at java.util.TimSort.mergeLo(TimSort.java:777)
> at java.util.TimSort.mergeAt(TimSort.java:514)
> at java.util.TimSort.mergeForceCollapse(TimSort.java:457)
> at java.util.TimSort.sort(TimSort.java:254)
> at java.util.Arrays.sort(Arrays.java:1512)
> at java.util.ArrayList.sort(ArrayList.java:1464)
> at java.util.Collections.sort(Collections.java:177)
> at org.apache.cassandra.gms.Gossiper.order(Gossiper.java:1327)
> at org.apache.cassandra.gms.Gossiper.applyStateLocally(Gossiper.java:1334)
> at
> org.apache.cassandra.gms.GossipDigestAck2VerbHandler.doVerb(GossipDigestAck2VerbHandler.java:49)
>
> at
> org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:70)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>
> at
> org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:116)
>
> at java.lang.Thread.run(Thread.java:750) [?:1.8.0_345]
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17947) Remove test-memory target
[
https://issues.apache.org/jira/browse/CASSANDRA-17947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17612440#comment-17612440
]
Blake Eggleston edited comment on CASSANDRA-17947 at 10/3/22 9:20 PM:
--
I'd prefer we keep this around for now if it's not causing any issues for us. I
do intend to come back to allocation optimization at some point, and even have
some unfinished work removing most allocation from the read path that I'd like
to get back to after accord has shipped.
was (Author: bdeggleston):
I'd prefer we keep this around for now if it's now causing any issues for us. I
do intend to come back to allocation optimization at some point, and even have
some unfinished work removing most allocation from the read path that I'd like
to get back to after accord has shipped.
> Remove test-memory target
> -
>
> Key: CASSANDRA-17947
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17947
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Ekaterina Dimitrova
>Priority: Low
> Fix For: 4.0.x, 4.1.x, 4.x
>
>
> I noticed the {{test-memory}} target which seems to have been added in
> CASSANDRA-15388. Unfortunately, since then _java-allocation-instrumenter_
> which was added as a dependency was not really maintained by the authors. I
> think this is the official repo -
> [https://github.com/google/allocation-instrumenter] and last commit was to
> support Java 8 in 2020. The test itself was also not added to CI.
> Confirmed with [~dcapwell] in Slack
> CC [~bdeggleston] and [~benedict]
--
This message was sent by Atlassian Jira
(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-17947) Remove test-memory target
[
https://issues.apache.org/jira/browse/CASSANDRA-17947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17612440#comment-17612440
]
Blake Eggleston commented on CASSANDRA-17947:
-
I'd prefer we keep this around for now if it's now causing any issues for us. I
do intend to come back to allocation optimization at some point, and even have
some unfinished work removing most allocation from the read path that I'd like
to get back to after accord has shipped.
> Remove test-memory target
> -
>
> Key: CASSANDRA-17947
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17947
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Ekaterina Dimitrova
>Priority: Low
> Fix For: 4.0.x, 4.1.x, 4.x
>
>
> I noticed the {{test-memory}} target which seems to have been added in
> CASSANDRA-15388. Unfortunately, since then _java-allocation-instrumenter_
> which was added as a dependency was not really maintained by the authors. I
> think this is the official repo -
> [https://github.com/google/allocation-instrumenter] and last commit was to
> support Java 8 in 2020. The test itself was also not added to CI.
> Confirmed with [~dcapwell] in Slack
> CC [~bdeggleston] and [~benedict]
--
This message was sent by Atlassian Jira
(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-17461) Test Failure: org.apache.cassandra.distributed.test.CASTest.testConflictingWritesWithStaleRingInformation
[
https://issues.apache.org/jira/browse/CASSANDRA-17461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Blake Eggleston updated CASSANDRA-17461:
Status: Ready to Commit (was: Review In Progress)
> Test Failure:
> org.apache.cassandra.distributed.test.CASTest.testConflictingWritesWithStaleRingInformation
> -
>
> Key: CASSANDRA-17461
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17461
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: Andres de la Peña
>Assignee: Blake Eggleston
>Priority: Normal
> Fix For: 4.1-beta, 4.x
>
>
> Intermittent failures on {{org.apache.cassandra.distributed.test.CASTest}}
> for trunk:
> *
> [testConflictingWritesWithStaleRingInformation|https://ci-cassandra.apache.org/job/Cassandra-trunk/1024/testReport/org.apache.cassandra.distributed.test/CASTest/testConflictingWritesWithStaleRingInformation_3/]
> *
> [testSuccessfulWriteBeforeRangeMovement|https://ci-cassandra.apache.org/job/Cassandra-trunk/1025/testReport/org.apache.cassandra.distributed.test/CASTest/testSuccessfulWriteBeforeRangeMovement/]
> *
> [testSuccessfulWriteDuringRangeMovementFollowedByConflicting|https://ci-cassandra.apache.org/job/Cassandra-trunk/1020/testReport/org.apache.cassandra.distributed.test/CASTest/testSuccessfulWriteDuringRangeMovementFollowedByConflicting/]
> *
> [testSucccessfulWriteDuringRangeMovementFollowedByRead|https://ci-cassandra.apache.org/job/Cassandra-trunk/1020/testReport/org.apache.cassandra.distributed.test/CASTest/testSucccessfulWriteDuringRangeMovementFollowedByRead/]
> All four seem to have the same aspect:
> {code}
> Failed 2 times in the last 5 runs. Flakiness: 50%, Stability: 60%
> Error Message
> CAS operation timed out: received 1 of 2 required responses after 0
> contention retries
> Stacktrace
> org.apache.cassandra.exceptions.CasWriteTimeoutException: CAS operation timed
> out: received 1 of 2 required responses after 0 contention retries
> at
> org.apache.cassandra.service.paxos.Paxos$MaybeFailure.markAndThrowAsTimeoutOrFailure(Paxos.java:547)
> at org.apache.cassandra.service.paxos.Paxos.begin(Paxos.java:1048)
> at org.apache.cassandra.service.paxos.Paxos.cas(Paxos.java:659)
> at org.apache.cassandra.service.paxos.Paxos.cas(Paxos.java:618)
> at org.apache.cassandra.service.StorageProxy.cas(StorageProxy.java:307)
> at
> org.apache.cassandra.cql3.statements.ModificationStatement.executeWithCondition(ModificationStatement.java:500)
> at
> org.apache.cassandra.cql3.statements.ModificationStatement.execute(ModificationStatement.java:467)
> at
> org.apache.cassandra.distributed.impl.Coordinator.unsafeExecuteInternal(Coordinator.java:122)
> at
> org.apache.cassandra.distributed.impl.Coordinator.unsafeExecuteInternal(Coordinator.java:103)
> at
> org.apache.cassandra.distributed.impl.Coordinator.lambda$executeWithResult$0(Coordinator.java:66)
> at org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:47)
> at org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:57)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:829)
> Standard Output
> DEBUG [main] 2022-03-19 16:20:42,868 Reflections.java:198 - going to scan
> these urls:
> [jar:file:/home/cassandra/cassandra/build/apache-cassandra-4.1-SNAPSHOT.jar!/,
>
> jar:file:/home/cassandra/cassandra/build/test/lib/jars/simulator-bootstrap.jar!/,
>
> jar:file:/home/cassandra/cassandra/build/test/lib/jars/dtest-api-0.0.12.jar!/,
> file:/home/cassandra/cassandra/build/classes/fqltool/,
> file:/home/cassandra/cassandra/build/test/classes/,
> file:/home/cassandra/cassandra/build/classes/main/, file:/home/cass
> ...[truncated 4929659 chars]...
> gService.java:519 - Waiting for messaging service to quiesce
> INFO [node1_isolatedExecutor:10] 2022-03-19 16:21:55,223
> SubstituteLogger.java:169 - INFO [node1_isolatedExecutor:10] node1
> 2022-03-19 16:21:55,221 MessagingService.java:519 - Waiting for messaging
> service to quiesce
> INFO [node2_isolatedExecutor:8] 2022-03-19 16:21:55,223
> SubstituteLogger.java:169 - INFO [node2_isolatedExecutor:8] node2 2022-03-19
> 16:21:55,222 MessagingService.java:519 - Waiting for messaging service to
> quiesce
> {code}
> Failures can also be repeatedly hit with CircleCI test multiplexer:
>
