[jira] [Commented] (CASSANDRA-17164) CEP-14: Paxos Improvements
[ https://issues.apache.org/jira/browse/CASSANDRA-17164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17476253#comment-17476253 ] Branimir Lambov commented on CASSANDRA-17164: - Is there any location where the algorithm is described in detail? I find it pretty hard to follow the algorithm steps and decision points, as they are spread among a multitude of classes and files. There are quite a few non-trivial differences with the basic Paxos algorithm which need to be laid out and have some explanation of why they are safe: - the use of voting quorum that is not selected only among the replicas that accepted a ballot - the use of "most recent commit" as a voting session identifier - the sharing of ballot numbers between sessions and rejection/acceptance based solely on ballot numbers which may belong to a different voting session - advancing voting sessions without committing empty proposals - replicas skipping voting sessions because of stale participant refresh - read vs write promises - the handling of range movements - state expiration I think this piece of work will benefit tremendously from in-tree markdown documentation that describes the above. > CEP-14: Paxos Improvements > -- > > Key: CASSANDRA-17164 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17164 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Coordination, Consistency/Repair >Reporter: Benedict Elliott Smith >Assignee: Benedict Elliott Smith >Priority: Normal > Fix For: 4.1 > > > This ticket encompasses work for [CEP-14| > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-14%3A+Paxos+Improvements]. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17164) CEP-14: Paxos Improvements
[ https://issues.apache.org/jira/browse/CASSANDRA-17164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17476269#comment-17476269 ] Branimir Lambov commented on CASSANDRA-17164: - Most of this is inherited from the earlier implementation, but I still can't find a description that explains why we can trust these modifications. CASSANDRA-5062 discusses some of them, but still leaves quite a bit of doubt about their correctness (to me at least). > CEP-14: Paxos Improvements > -- > > Key: CASSANDRA-17164 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17164 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Coordination, Consistency/Repair >Reporter: Benedict Elliott Smith >Assignee: Benedict Elliott Smith >Priority: Normal > Fix For: 4.1 > > > This ticket encompasses work for [CEP-14| > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-14%3A+Paxos+Improvements]. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17164) CEP-14: Paxos Improvements
[ https://issues.apache.org/jira/browse/CASSANDRA-17164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17476301#comment-17476301 ] Benedict Elliott Smith commented on CASSANDRA-17164: {quote}Is there any location where the algorithm is described in detail? {quote} The documentation that is present sort of assumes you are familiar with the prior implementation of Paxos, and we pepper in justifications at each place where a novel approach is taken. I will try to put together some overview markdown documentation over the coming week. In the meantime: {quote}the use of voting quorum that is not selected only among the replicas that accepted a ballot {quote} I think this is actually the typical way of implementing Classic Paxos, even though Lamport's paper seems to suggest you must only contact the nodes that responded to the prepare (there may be something else specific about his formulation that necessitates this, I forget, as I dislike his writings on the topic). This is corroborated by [Heidi Howard's dissertation|https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-935.pdf], which was the easiest place I could find a straight-forward formulation of Classic Paxos besides that of Lamport. See Algorithm 3 on Page 30. {quote}the use of "most recent commit" as a voting session identifier {quote} I don't quite follow what you mean by this, as this is not limited to "most recent commit", but a ballot directly maps to the instance id of classic paxos, it just avoids pre-splitting the range of integers. {quote}the sharing of ballot numbers between sessions and rejection/acceptance based solely on ballot numbers which may belong to a different voting session {quote} Could you explain what you are referring to here? I think this is all standard stuff for Paxos, we're again just recording the most recently used instance number for each register. {quote}advancing voting sessions without committing empty proposals {quote} The final commit phase is only required to ensure any "decree" (decision) is disseminated. If we have proposed that no decree be made, there is nothing to disseminate, and nothing to complete if another transaction encounters it. This is in some ways an artefact of the feature of Cassandra's implementation, that we initiate a paxos round without knowing if it will do anything, though this feature would I suppose be present for read-only operations anyway. {quote}replicas skipping voting sessions because of stale participant refresh {quote} There's two possible things you mean by this. I think you are referring to the situation where we send a commit and then continue with the ballot we have already prepared? In which case I'm not sure this is really in conflict with any formulation I've seen, which tends to gloss over handling of {_}commit{_}, and I think may arise solely from the particulars of Cassandra - we are not updating a register, but are agreeing a delta, and only disseminate this to any majority (that may be different from the one that received any prior delta), and so we must ensure that each _Commit_ is witnessed by a majority so that the complete register state may be constructed from any majority. In normal formulations the register is overwritten, so I don't think the _Commit_ even needs to be received if it is superseded by another {_}Commit{_}, and I think many formulations ignore it entirely as a result. Anyway to justify it seems pretty straightforward: if any other command were to supersede us we would fail the _Accept_ phase, and if not then by updating the _MostRecentCommit_ register we know precisely what the register state is on the node, and it is equivalent to having received this response in the first place, so we may proceed safely. {quote}read vs write promises {quote} This is just a very simple formulation of operation commutativity. We linearise writes with writes and reads, but we do not linearise reads with each other since they are commutative. So any read operation only consults the write registers, but updates the read registers, whereas writes update the write registers and consult both. {quote}the handling of range movements {quote} Fair, this is quite complex, and we should have already put in an overview here. In simple terms, each node tracks those operations that have been witnessed but are not known to have committed. Each node is able to coordinate the completion of these operations, either by invalidating them, committing them, or witnessing something newer. By performing this on a majority of nodes we are able to ensure that all operations that may have reached a decision prior to this mechanism being invoked are now committed to a majority of nodes in their base table. By performing this after a node becomes pending but before streaming begins we ensure that a new node was either already participating in any o
[jira] [Commented] (CASSANDRA-17164) CEP-14: Paxos Improvements
[ https://issues.apache.org/jira/browse/CASSANDRA-17164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17479167#comment-17479167 ] Branimir Lambov commented on CASSANDRA-17164: - bq. I think this is actually the typical way of implementing Classic Paxos, even though Lamport's paper seems to suggest you must only contact the nodes that responded to the prepare (there may be something else specific about his formulation that necessitates this, I forget, as I dislike his writings on the topic). This is corroborated by Heidi Howard's dissertation, which was the easiest place I could find a straight-forward formulation of Classic Paxos besides that of Lamport. See Algorithm 3 on Page 30. This is an excellent pointer, thank you. Lamport's proof also works with separate proposal quorum -- my only request here is that this should be stated somewhere as other contributors might start with Lamport's original definition too. bq. I don't quite follow what you mean by this, as this is not limited to "most recent commit", but a ballot directly maps to the instance id of classic paxos, it just avoids pre-splitting the range of integers. Well, I don't follow this one. A ballot id is something one replica selects and sends it as a prepare message to everyone. At this point some nodes may have committed a proposal, others may have accepted it, and yet others may have never heard of it. From the point of view of a sequence of paxos instances, the first two will definitely make promises for different instances, and likely the third one will be promising for yet another one. The fact that we tie accepting a promise to a majority with matching "most recent commit" means that we effectively treat it as the identifier of the current session. More interestingly, we can then send a proposal to nodes with older most recent commit (i.e. nodes that are effectively working on a previous paxos instance), that proposal will be accepted (overwriting the decided value but not advancing the most recent commit), and this might lead to a decision using just a small number of participants with the right "most recent commit". Specifically, what stops the following from happening? {code} A mrcA acceptedA promised B mrc B accepted B promised C mrcC accepted C promised prepare(1) -> ABC- -1- - 1 - -1 propose(1, X) -> ABC - 1,X1- 1,X 1 - 1,X 1 commit(1, X) -> AB 1,X -1 1,X - 1 - -1 prepare(2) -> AB1,X -2 1,X - 2 - 1,X 1 majority AB, no refresh propose(2, Y) -> BC 1,X -2 1,X 2,Y 2 - 2,Y 2 returns successful Y prepare(3) -> AC1,X1,X3 1,X 2,Y 2 1,X -3 refresh stale, then forms majority AC propose(3, Z) -> ABC1,X3,Z3 1,X 3,Z 3 1,X3,Z 3 returns successful Z {code} If this is permitted, there's a further error possibility if B is partitioned after the 2,Y proposal succeeds and a commit is executed in B. Then the committed value can be read from B, and later wiped with a conflicting decision. In LWT terms, if X: {{column = X if not exists}}, Y: {{column = Y if column == X}} and Z: {{column = Z if column == X}}, we may be able to read both Y and Z. bq. Could you explain what you are referring to here? I think this is all standard stuff for Paxos, we're again just recording the most recently used instance number for each register. Judging from the above, this may be insufficient. I'm likely missing something here -- that something needs to be documented. bq. The final commit phase is only required to ensure any "decree" (decision) is disseminated. If we have proposed that no decree be made, there is nothing to disseminate, and nothing to complete if another transaction encounters it. This is in some ways an artefact of the feature of Cassandra's implementation, that we initiate a paxos round without knowing if it will do anything, though this feature would I suppose be present for read-only operations anyway. This is also hard to read from the code: {{Paxos.cas}} does not issue a commit for an empty proposal, but it seems the next {{prepare}} will return {{FOUND_
[jira] [Commented] (CASSANDRA-17164) CEP-14: Paxos Improvements
[ https://issues.apache.org/jira/browse/CASSANDRA-17164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17479183#comment-17479183 ] Benedict Elliott Smith commented on CASSANDRA-17164: {quote}Specifically, what stops the following from happening?{quote} In this example, I believe (3) would not yield {{FOUND_INCOMPLETE_COMMIT}} but {{FOUND_INCOMPLETE_ACCEPTED}} and so would correctly re-propose (2), expending its ballot? {quote}It seems the next prepare will return FOUND_INCOMPLETE_ACCEPTED and trigger reproposal and commit{quote} {{hasInProgressProposal}} first checks if {{latestAccepted.update.isEmpty()}} and if so, returns false, i.e. this would not be considered an incomplete proposal. The fast read optimisation does however leave an incomplete _promise_ that we might want to change to asynchronously send an empty proposal. > CEP-14: Paxos Improvements > -- > > Key: CASSANDRA-17164 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17164 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Coordination, Consistency/Repair >Reporter: Benedict Elliott Smith >Assignee: Benedict Elliott Smith >Priority: Normal > Fix For: 4.1 > > > This ticket encompasses work for [CEP-14| > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-14%3A+Paxos+Improvements]. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17164) CEP-14: Paxos Improvements
[ https://issues.apache.org/jira/browse/CASSANDRA-17164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17479406#comment-17479406 ] Benedict Elliott Smith commented on CASSANDRA-17164: I have pushed a documentation commit, adding javadoc to the {{Paxos}} class. It might turn out to be inadequate, but it is hopefully a starting point to help further discussion. > CEP-14: Paxos Improvements > -- > > Key: CASSANDRA-17164 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17164 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Coordination, Consistency/Repair >Reporter: Benedict Elliott Smith >Assignee: Benedict Elliott Smith >Priority: Normal > Fix For: 4.1 > > > This ticket encompasses work for [CEP-14| > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-14%3A+Paxos+Improvements]. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17164) CEP-14: Paxos Improvements
[ https://issues.apache.org/jira/browse/CASSANDRA-17164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17480292#comment-17480292 ] Blake Eggleston commented on CASSANDRA-17164: - So this looks pretty good for the most part, I don’t have any high level concerns about the patch. I have a branch here with some minor changes: [https://github.com/bdeggleston/cassandra/tree/17164-trunk-review] Other feedback / questions: * Config ** additional comments around some of the config options would be useful * DatabaseDescriptor ** Why did you remove the logged warning about non linearizable reads? * QueryProcessor ** Why did you change {{type.decompose}} to {{type.decomposeUntyped}} in {{makeInternalOptionsWithNowInSec}}?? * AbstractBTreePartition / PartitionUpdate ** this equals method is going to cause confusion and possibly bugs in the future. I’d opt for a standard equals/hashCode implementation either here or in PartitionUpdate, and if you need something more specific for tests, I’d write an assert method for those tests, especially since it’s not checking for the partition key or static row * PaxosCleanup ** should we log out of range requests in {{isInRangeAndShouldProcess}}? * PaxosCleanupScheduler ** Doesn’t seem to be used outside of tests * PaxosState ** I’d prefer we use {{.equals}} instead of checking pointer equality here. {{.equals}} should check for pointer equality, but will also guard against unintended behavior if logically identical but different objects end up in these fields. * UncommittedTableData ** Regarding your TODO in {{CFSFilterFactory,getReplicatedRanges}}, WDYT about returning an empty collection if we don’t know about the table? * Ballot/TimeUUID ** WDYT about renaming {{rawTimestamp}} to {{uuidTimestamp}}? Raw is ambiguous * BufferPool ** These changes seem like they may have been for debugging purposes, are they something that should be committed? In addition to more docs around the config options, we should include docs explaining what v2 is, and when/why you’d want to use it. A description and explanation of the upgrade procedure should also be included, as well as an entry in NEWS.txt. > CEP-14: Paxos Improvements > -- > > Key: CASSANDRA-17164 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17164 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Coordination, Consistency/Repair >Reporter: Benedict Elliott Smith >Assignee: Benedict Elliott Smith >Priority: Normal > Fix For: 4.1 > > > This ticket encompasses work for [CEP-14| > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-14%3A+Paxos+Improvements]. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17164) CEP-14: Paxos Improvements
[ https://issues.apache.org/jira/browse/CASSANDRA-17164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17480311#comment-17480311 ] Benedict Elliott Smith commented on CASSANDRA-17164: {quote}Why did you remove the logged warning about non linearizable reads?{quote} Hopefully unintentionally... {quote} Why did you change type.decompose to type.decomposeUntyped in makeInternalOptionsWithNowInSec? {quote} I think because dtest-api uses UUID and so a full migration to TimeUUID in all places was kind of tricky, particularly for e.g. upgrade tests? It's hazy after so long. {quote}especially since it’s not checking for the partition key or static row{quote} I'm sure this is an oversight that's just not important for the use case - which unfortunately I forget, so I'll just fix up this oversight. {quote}should we log out of range requests in isInRangeAndShouldProcess?{quote} I think this is something that still hasn't taken full shape in OSS, so I'm not sure what the right course of action is. Happy to do whatever you feel is appropriate until a broader strategy is sorted out. {quote}I’d prefer we use .equals instead of checking pointer equality here. .equals should check for pointer equality, but will also guard against unintended behavior{quote} For the assert? That would be fine, but it makes enforcing the identity constraint harder with automated testing. In the other case, it's a pure optimisation so better to keep IMO (else the benefit is likely lost) {quote}WDYT about returning an empty collection if we don’t know about the table?{quote} I'll have a ponder over the weekend. {quote}WDYT about renaming rawTimestamp to uuidTimestamp? Raw is ambiguous{quote} WFM {quote}These changes seem like they may have been for debugging purposes, are they something that should be committed?{quote} Oops, yep. Thanks! > CEP-14: Paxos Improvements > -- > > Key: CASSANDRA-17164 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17164 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Coordination, Consistency/Repair >Reporter: Benedict Elliott Smith >Assignee: Benedict Elliott Smith >Priority: Normal > Fix For: 4.1 > > > This ticket encompasses work for [CEP-14| > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-14%3A+Paxos+Improvements]. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17164) CEP-14: Paxos Improvements
[ https://issues.apache.org/jira/browse/CASSANDRA-17164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17481962#comment-17481962 ] Blake Eggleston commented on CASSANDRA-17164: - {quote} should we log out of range requests in isInRangeAndShouldProcess? I think this is something that still hasn't taken full shape in OSS, so I'm not sure what the right course of action is. Happy to do whatever you feel is appropriate until a broader strategy is sorted out. {quote} I don’t think there’s a scenario where that’s not a problem, and we’re checking, so we may as well log a warning. {quote} I’d prefer we use .equals instead of checking pointer equality here. .equals should check for pointer equality, but will also guard against unintended behavior For the assert? That would be fine, but it makes enforcing the identity constraint harder with automated testing. In the other case, it's a pure optimisation so better to keep IMO (else the benefit is likely lost) {quote} Sorry, I meant for the {{latestWitnessedOrLowBound}} method > CEP-14: Paxos Improvements > -- > > Key: CASSANDRA-17164 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17164 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Coordination, Consistency/Repair >Reporter: Benedict Elliott Smith >Assignee: Benedict Elliott Smith >Priority: Normal > Fix For: 4.1 > > > This ticket encompasses work for [CEP-14| > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-14%3A+Paxos+Improvements]. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17164) CEP-14: Paxos Improvements
[ https://issues.apache.org/jira/browse/CASSANDRA-17164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17481966#comment-17481966 ] Benedict Elliott Smith commented on CASSANDRA-17164: bq. I don’t think there’s a scenario where that’s not a problem, and we’re checking, so we may as well log a warning. I think it's likely that log messages for out of range operations will be configurable in the future, but you're right that there's no harm in logging warnings in the meantime. > CEP-14: Paxos Improvements > -- > > Key: CASSANDRA-17164 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17164 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Coordination, Consistency/Repair >Reporter: Benedict Elliott Smith >Assignee: Benedict Elliott Smith >Priority: Normal > Fix For: 4.1 > > > This ticket encompasses work for [CEP-14| > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-14%3A+Paxos+Improvements]. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17164) CEP-14: Paxos Improvements
[ https://issues.apache.org/jira/browse/CASSANDRA-17164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17481973#comment-17481973 ] Blake Eggleston commented on CASSANDRA-17164: - Actually, if we're asserting identity in the ctor, I think it would preferable to use {{.equals}} in {{latestWitnessedOrLowBound}}? That way if someone comes along and removes that behavior and requirement, the method will still work if they miss that check. > CEP-14: Paxos Improvements > -- > > Key: CASSANDRA-17164 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17164 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Coordination, Consistency/Repair >Reporter: Benedict Elliott Smith >Assignee: Benedict Elliott Smith >Priority: Normal > Fix For: 4.1 > > > This ticket encompasses work for [CEP-14| > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-14%3A+Paxos+Improvements]. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17164) CEP-14: Paxos Improvements
[ https://issues.apache.org/jira/browse/CASSANDRA-17164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17481981#comment-17481981 ] Benedict Elliott Smith commented on CASSANDRA-17164: But this is only an optimisation, I think that would be equivalent to just removing the condition and ternary operator entirely, and saying {{latest(promised, latestWriteOrLowBound)}}? i.e. {{latestWriteOrLowBound}} already is greater than or equal to {{promisedWrite}} so this is just a single instruction short-circuit permitting us to avoid evaluating {{Ballot#compareTo}} > CEP-14: Paxos Improvements > -- > > Key: CASSANDRA-17164 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17164 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Coordination, Consistency/Repair >Reporter: Benedict Elliott Smith >Assignee: Benedict Elliott Smith >Priority: Normal > Fix For: 4.1 > > > This ticket encompasses work for [CEP-14| > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-14%3A+Paxos+Improvements]. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17164) CEP-14: Paxos Improvements
[ https://issues.apache.org/jira/browse/CASSANDRA-17164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17482028#comment-17482028 ] Blake Eggleston commented on CASSANDRA-17164: - Ok I think I see the intention here. In that case I think the issue is with {{latestWriteOrLowBound}}, shouldn't line 207 ({{latest = latest(latest, promised);}}) be {{latest = latest(latest, promisedWrite);}}? > CEP-14: Paxos Improvements > -- > > Key: CASSANDRA-17164 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17164 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Coordination, Consistency/Repair >Reporter: Benedict Elliott Smith >Assignee: Benedict Elliott Smith >Priority: Normal > Fix For: 4.1 > > > This ticket encompasses work for [CEP-14| > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-14%3A+Paxos+Improvements]. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17164) CEP-14: Paxos Improvements
[ https://issues.apache.org/jira/browse/CASSANDRA-17164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17482034#comment-17482034 ] Benedict Elliott Smith commented on CASSANDRA-17164: Ah, yes. You're right. So this would have been disabling the read-only permissions. I will add a dtest to ensure the read-only optimisation is in operation, and organise some more simulation burn tests. > CEP-14: Paxos Improvements > -- > > Key: CASSANDRA-17164 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17164 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Coordination, Consistency/Repair >Reporter: Benedict Elliott Smith >Assignee: Benedict Elliott Smith >Priority: Normal > Fix For: 4.1 > > > This ticket encompasses work for [CEP-14| > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-14%3A+Paxos+Improvements]. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17164) CEP-14: Paxos Improvements
[ https://issues.apache.org/jira/browse/CASSANDRA-17164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17482504#comment-17482504 ] Branimir Lambov commented on CASSANDRA-17164: - What do you think of applying the following simplifications: - The {{promised}} ballot number to be updated whenever a proposal or commit with higher ballot number is received by a replica. Every time we use the promised number we compute it as the max of the three values – why not just store that instead? - Storing and sending only the higher-ballot value of the "committed" and "accepted" registers, with a flag that identifies if the value has been committed or only accepted. The decisions that a proposer makes are taken based on the maximum ballot number among "committed" and "accepted", and we only proceed using the newer of the two (except in the case of newer empty accepted proposal, where we may decide to distribute a commit which can already be shown to have been committed to a quorum of replicas). > CEP-14: Paxos Improvements > -- > > Key: CASSANDRA-17164 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17164 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Coordination, Consistency/Repair >Reporter: Benedict Elliott Smith >Assignee: Benedict Elliott Smith >Priority: Normal > Fix For: 4.1 > > > This ticket encompasses work for [CEP-14| > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-14%3A+Paxos+Improvements]. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17164) CEP-14: Paxos Improvements
[ https://issues.apache.org/jira/browse/CASSANDRA-17164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17482510#comment-17482510 ] Benedict Elliott Smith commented on CASSANDRA-17164: I think this would be fine, I need to think through why I did not do this originally, as I did consider it. It may simply have been to minimise the change in semantics to {{system.paxos}}, without there having been any particularly good reason. Perhaps also for debugging purposes, it helps to be able to see whether something had been promised before it was accepted/committed. I think there is perhaps also some additional complexity when a replica has promised a ballot with the same timestamp, and then proceed to accept it. I don't think we would resolve these reliably, so we might not actually overwrite it anyway, and I don't think there is a trivial solution to this problem in the storage layer. > CEP-14: Paxos Improvements > -- > > Key: CASSANDRA-17164 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17164 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Coordination, Consistency/Repair >Reporter: Benedict Elliott Smith >Assignee: Benedict Elliott Smith >Priority: Normal > Fix For: 4.1 > > > This ticket encompasses work for [CEP-14| > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-14%3A+Paxos+Improvements]. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17164) CEP-14: Paxos Improvements
[ https://issues.apache.org/jira/browse/CASSANDRA-17164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17482511#comment-17482511 ] Benedict Elliott Smith commented on CASSANDRA-17164: So, if we _Commit_ a record with a different ballot to one we have previously _Promised_ with the same timestamp, we won't be guaranteed to update the _Promised_ register on disk (it should happen 50% of the time). Which may or may not be a problem. > CEP-14: Paxos Improvements > -- > > Key: CASSANDRA-17164 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17164 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Coordination, Consistency/Repair >Reporter: Benedict Elliott Smith >Assignee: Benedict Elliott Smith >Priority: Normal > Fix For: 4.1 > > > This ticket encompasses work for [CEP-14| > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-14%3A+Paxos+Improvements]. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17164) CEP-14: Paxos Improvements
[ https://issues.apache.org/jira/browse/CASSANDRA-17164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17482995#comment-17482995 ] Benedict Elliott Smith commented on CASSANDRA-17164: 1) To persist to the {{promised}} (actually {{promisedWrite}}) register safely we would need to modify the timestamp behaviour, i.e. writing promises with a lower timestamp than accepts or commits, which harms seamless downgrades and backwards compatibility. Not doing so safely obviates any benefit, as we still need to perform this comparison in memory to resolve the equal timestamp case. 2) Separate {{accept}} and {{commit}} registers are used for essentially the same reason - I agree it would be simpler to maintain just one register here for both the mutation and the ballot, but the current representation is 100% downgradeable, and any modification to persistence would not be. We _could_ front-load these changes to the loading from disk phase, and modify the {{Snapshot}}, however, if that works for you? This could also modify the network representation. I think these changes would be fine, although I think they result in only a modest clarity improvement. > CEP-14: Paxos Improvements > -- > > Key: CASSANDRA-17164 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17164 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Coordination, Consistency/Repair >Reporter: Benedict Elliott Smith >Assignee: Benedict Elliott Smith >Priority: Normal > Fix For: 4.1 > > > This ticket encompasses work for [CEP-14| > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-14%3A+Paxos+Improvements]. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17164) CEP-14: Paxos Improvements
[ https://issues.apache.org/jira/browse/CASSANDRA-17164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17483827#comment-17483827 ] Branimir Lambov commented on CASSANDRA-17164: - This is okay. I'm writing documentation with proofs, and having them separated makes things a little harder to prove. However, it's not hard to map what we actually do to the proof's definitions, so I added an explanation instead. I've reached this far: [https://github.com/blambov/cassandra/blob/17164-trunk/src/java/org/apache/cassandra/service/paxos/Paxos.md] I need some clarification on read commutativity/concurrent reads. It looks like we use "promised" (i.e. the read promise) when we decide acceptance of a proposal (the JavaDoc description also says so). This is sensible and correct and appears necessary, but does this not mean that no reads can actually execute concurrently? In other words, do we really gain anything by storing read promises separately? If we do skip proposing on a "safe" read, this is not a problem, but this optimization does not appear to require the commutativity. > CEP-14: Paxos Improvements > -- > > Key: CASSANDRA-17164 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17164 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Coordination, Consistency/Repair >Reporter: Benedict Elliott Smith >Assignee: Benedict Elliott Smith >Priority: Normal > Fix For: 4.1 > > > This ticket encompasses work for [CEP-14| > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-14%3A+Paxos+Improvements]. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17164) CEP-14: Paxos Improvements
[ https://issues.apache.org/jira/browse/CASSANDRA-17164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17483834#comment-17483834 ] Benedict Elliott Smith commented on CASSANDRA-17164: bq. If we do skip proposing on a "safe" read, this is not a problem, but this is a separate optimization that does not appear to require read promises. This separate optimisation is made more powerful with the separate read register, as an in progress read does not make another read unsafe, so we can have as many "safe" parallel reads as we might like, but once there is an in progress write then we may have only one concurrent read or write. For example, we could safely have the following: R1: promised=1, safe=true (at all replicas) R2: promised=2, safe=true (at all replicas) R3: promised=3, safe=true (at all replicas) W4: promisedWrite=4 (at some majority of replicas) R5: promised=5, safe=false (at some replica in the quorum) So R1, R2 and R3 would all complete successfully in one round-trip, but R5 would require a proposal and take two round-trips. If there were no separate register then only one safe read operation could occur concurrently, as we would not know if any proposal might yet be made, and as such would need to consider any concurrent reads unsafe, force a proposal, and as such reduce our concurrency to one. Does that make sense? > CEP-14: Paxos Improvements > -- > > Key: CASSANDRA-17164 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17164 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Coordination, Consistency/Repair >Reporter: Benedict Elliott Smith >Assignee: Benedict Elliott Smith >Priority: Normal > Fix For: 4.1 > > > This ticket encompasses work for [CEP-14| > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-14%3A+Paxos+Improvements]. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17164) CEP-14: Paxos Improvements
[ https://issues.apache.org/jira/browse/CASSANDRA-17164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17483895#comment-17483895 ] Branimir Lambov commented on CASSANDRA-17164: - In other words the "promisedWrite" value is a parameter that's used to decide if a read is safe as part of the fast reads optimization. Makes sense. We probably want to reorder and/or rephrase the doc in Paxos.java as it confused me that it is something we want to do as a standalone optimization too. > CEP-14: Paxos Improvements > -- > > Key: CASSANDRA-17164 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17164 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Coordination, Consistency/Repair >Reporter: Benedict Elliott Smith >Assignee: Benedict Elliott Smith >Priority: Normal > Fix For: 4.1 > > > This ticket encompasses work for [CEP-14| > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-14%3A+Paxos+Improvements]. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17164) CEP-14: Paxos Improvements
[ https://issues.apache.org/jira/browse/CASSANDRA-17164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17484777#comment-17484777 ] Benedict Elliott Smith commented on CASSANDRA-17164: Yep, I'll make a suitable change. Regarding your sketch, it looks to be a welcome piece of documentation. A couple of notes: # We collect a quorum of reads for computing the result, which depending how you view this formulation is either a material or immaterial difference. # We don't currently use a unique node identifier for each ballot, but a 64-bit random integer. I anticipate improving this as part of CEP-15, but to all intents and purposes this is probably fine given the exceptionally low probability of a simultaneous timestamp and random part clash on the same partition key. It might be worth noting as an immaterial difference though. I've only briefly read the proof but it looks roughly correct to me, I'll try to find time to fully digest it. It might be nice to define "will be witnessed by at least one member of the quorum" in terms of reads and prior commits and also tidy up (1) above. > CEP-14: Paxos Improvements > -- > > Key: CASSANDRA-17164 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17164 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Coordination, Consistency/Repair >Reporter: Benedict Elliott Smith >Assignee: Benedict Elliott Smith >Priority: Normal > Fix For: 4.1 > > > This ticket encompasses work for [CEP-14| > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-14%3A+Paxos+Improvements]. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17164) CEP-14: Paxos Improvements
[ https://issues.apache.org/jira/browse/CASSANDRA-17164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17485381#comment-17485381 ] Benedict Elliott Smith commented on CASSANDRA-17164: I've pushed updates addressing all of the review comments I think. Notably, fixing the issue with the concurrent fast read optimisation surfaced a couple of other issues with it that I have also addressed. I will be soak testing the current code with the simulator over the coming week. > CEP-14: Paxos Improvements > -- > > Key: CASSANDRA-17164 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17164 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Coordination, Consistency/Repair >Reporter: Benedict Elliott Smith >Assignee: Benedict Elliott Smith >Priority: Normal > Fix For: 4.1 > > > This ticket encompasses work for [CEP-14| > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-14%3A+Paxos+Improvements]. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17164) CEP-14: Paxos Improvements
[ https://issues.apache.org/jira/browse/CASSANDRA-17164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17487366#comment-17487366 ] Blake Eggleston commented on CASSANDRA-17164: - [~benedict] could you also take a look at the minor fixes branch I linked in my earlier comment? ([https://github.com/bdeggleston/cassandra/tree/17164-trunk-review]) > CEP-14: Paxos Improvements > -- > > Key: CASSANDRA-17164 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17164 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Coordination, Consistency/Repair >Reporter: Benedict Elliott Smith >Assignee: Benedict Elliott Smith >Priority: Normal > Fix For: 4.1 > > > This ticket encompasses work for [CEP-14| > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-14%3A+Paxos+Improvements]. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17164) CEP-14: Paxos Improvements
[ https://issues.apache.org/jira/browse/CASSANDRA-17164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17490198#comment-17490198 ] Benedict Elliott Smith commented on CASSANDRA-17164: Quick update: the burn tests unfortunately shook out some remaining teething issues with simulation of Paxos v2, that I am still working through. I have incorporated [~bdeggleston]'s suggestions, with one minor change to the refactor of {{sizeOfConsensusQuorum}}. I can see [~blambov] is still making good progress on a very comprehensive piece of documentation with semi-formal proofs. I haven't had time to properly digest it but it looks great. One comment I would perhaps make, more generally than specifically to modify this documentation, is that I think it would be quite possible to use Multi-Paxos without burdensome state maintenance (e.g. by using token ranges for leader election, perhaps with per-key leaders in some rare circumstances). This would have trade-offs, however, in that the fast-read optimisation would be excluded and we would have heterogenous read performance between regions. This is probably a desirable trade-off particularly for write-heavy workloads and the _main_ reason we haven't done this is because we wanted to pursue _Accord_ and its superior semantics, as multi-key transactions are highly desirable, as are global 1RT reads (and global 1RT writes under realistic scenarios). It was my belief that pursuing Multi-Paxos in the near term would be a mis-investment of project resources. I think it is entirely possible we may loop back to provide Multi-Paxos eventually, as I do not think it is a hugely challenging proposition in itself and there may be some workloads that prefer it even once _Accord_ is delivered. The main difficulty would be the additional logic for routing operations to the correct command leader (perhaps involving client integration) and robust failure detection (currently much too poor in Cassandra). If somebody else wants to pursue this, I would be more than happy to help shepherd it, as it is certainly achievable. > CEP-14: Paxos Improvements > -- > > Key: CASSANDRA-17164 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17164 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Coordination, Consistency/Repair >Reporter: Benedict Elliott Smith >Assignee: Benedict Elliott Smith >Priority: Normal > Fix For: 4.1 > > > This ticket encompasses work for [CEP-14| > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-14%3A+Paxos+Improvements]. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17164) CEP-14: Paxos Improvements
[ https://issues.apache.org/jira/browse/CASSANDRA-17164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17491985#comment-17491985 ] Branimir Lambov commented on CASSANDRA-17164: - I am ready with my high-level review. The new version looks good to me and I am convinced of its correctness. It is a great improvement on both the performance and a number of issues of the older solution. I tried to [document|https://github.com/blambov/cassandra/blob/17164-trunk/src/java/org/apache/cassandra/service/paxos/Paxos.md] everything I found non-trivial to find and/or understand. This text will hopefully help all others looking at this code to understand the implementation's logic and should be included in the patch (with any corrections and additions you may want to add). > CEP-14: Paxos Improvements > -- > > Key: CASSANDRA-17164 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17164 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Coordination, Consistency/Repair >Reporter: Benedict Elliott Smith >Assignee: Benedict Elliott Smith >Priority: Normal > Fix For: 4.1 > > > This ticket encompasses work for [CEP-14| > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-14%3A+Paxos+Improvements]. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17164) CEP-14: Paxos Improvements
[ https://issues.apache.org/jira/browse/CASSANDRA-17164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17504438#comment-17504438 ] Benedict Elliott Smith commented on CASSANDRA-17164: I'm about to commit. FYI, this patch appears to break {{write_failures_test.py::TestMultiDCWriteFailures::test_oversized_mutation}} however this is a broken test. I have opted not to fix it as part of this work, but will file a follow-up ticket to decide how to proceed. The test believed it was checking whether hints were written, but since hints are written only at expiration of the callback it was simply not witnessing them - introducing a {{sleep(10)}} breaks the test on trunk. It may be that this is actually broken behaviour in Cassandra that the test failed to detect. > CEP-14: Paxos Improvements > -- > > Key: CASSANDRA-17164 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17164 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Coordination, Consistency/Repair >Reporter: Benedict Elliott Smith >Assignee: Benedict Elliott Smith >Priority: Normal > Fix For: 4.1 > > > This ticket encompasses work for [CEP-14| > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-14%3A+Paxos+Improvements]. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17164) CEP-14: Paxos Improvements
[ https://issues.apache.org/jira/browse/CASSANDRA-17164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17504677#comment-17504677 ] Ekaterina Dimitrova commented on CASSANDRA-17164: - This commit broke all unit tests - compression and cdc. I believe because of removed empty line is the tests cassandra.yaml. I will test now and if I am write I will ninja fix it... https://jenkins-cm4.apache.org/job/Cassandra-trunk/1002/ > CEP-14: Paxos Improvements > -- > > Key: CASSANDRA-17164 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17164 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Coordination, Consistency/Repair >Reporter: Benedict Elliott Smith >Assignee: Benedict Elliott Smith >Priority: Normal > Fix For: 4.1 > > > This ticket encompasses work for [CEP-14| > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-14%3A+Paxos+Improvements]. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17164) CEP-14: Paxos Improvements
[ https://issues.apache.org/jira/browse/CASSANDRA-17164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17504687#comment-17504687 ] Ekaterina Dimitrova commented on CASSANDRA-17164: - [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1429/workflows/a624c555-0417-4664-b10e-23f043854213/jobs/9359] Those finished fine. I will pushed the ninja fix, please, check CI tomorrow if there is anything else that needs attention as now there are thousands of tests failing so It is hard to say whether this will be the only issue. Thanks > CEP-14: Paxos Improvements > -- > > Key: CASSANDRA-17164 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17164 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Coordination, Consistency/Repair >Reporter: Benedict Elliott Smith >Assignee: Benedict Elliott Smith >Priority: Normal > Fix For: 4.1 > > > This ticket encompasses work for [CEP-14| > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-14%3A+Paxos+Improvements]. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17164) CEP-14: Paxos Improvements
[ https://issues.apache.org/jira/browse/CASSANDRA-17164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17504936#comment-17504936 ] Benedict Elliott Smith commented on CASSANDRA-17164: CI Links [j11|https://app.circleci.com/pipelines/github/belliottsmith/cassandra/276/workflows/3d6a7a75-50ba-4a5b-bb32-aa3c57fccc27] [j8|https://app.circleci.com/pipelines/github/belliottsmith/cassandra/276/workflows/eddb0904-a99e-4adb-abe5-75ea3529b3d3] > CEP-14: Paxos Improvements > -- > > Key: CASSANDRA-17164 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17164 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Coordination, Consistency/Repair >Reporter: Benedict Elliott Smith >Assignee: Benedict Elliott Smith >Priority: Normal > Fix For: 4.1 > > > This ticket encompasses work for [CEP-14| > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-14%3A+Paxos+Improvements]. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17164) CEP-14: Paxos Improvements
[ https://issues.apache.org/jira/browse/CASSANDRA-17164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17507180#comment-17507180 ] Brandon Williams commented on CASSANDRA-17164: -- This also broke the oversized mutation test https://ci-cassandra.apache.org/job/Cassandra-trunk/1002/testReport/dtest-offheap.write_failures_test/TestMultiDCWriteFailures/ > CEP-14: Paxos Improvements > -- > > Key: CASSANDRA-17164 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17164 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Coordination, Consistency/Repair >Reporter: Benedict Elliott Smith >Assignee: Benedict Elliott Smith >Priority: Normal > Fix For: 4.1 > > > This ticket encompasses work for [CEP-14| > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-14%3A+Paxos+Improvements]. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17164) CEP-14: Paxos Improvements
[ https://issues.apache.org/jira/browse/CASSANDRA-17164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17507183#comment-17507183 ] Benedict Elliott Smith commented on CASSANDRA-17164: See [this comment|https://issues.apache.org/jira/browse/CASSANDRA-17164?focusedCommentId=17504438&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17504438] > CEP-14: Paxos Improvements > -- > > Key: CASSANDRA-17164 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17164 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Coordination, Consistency/Repair >Reporter: Benedict Elliott Smith >Assignee: Benedict Elliott Smith >Priority: Normal > Fix For: 4.1 > > > This ticket encompasses work for [CEP-14| > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-14%3A+Paxos+Improvements]. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17164) CEP-14: Paxos Improvements
[ https://issues.apache.org/jira/browse/CASSANDRA-17164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17509053#comment-17509053 ] Ekaterina Dimitrova commented on CASSANDRA-17164: - I didn't find a ticket for this one and it is consistently failing. Is there a plan? Or a ticket for it? CC our build lead this week [~stefan.miklosovic] > CEP-14: Paxos Improvements > -- > > Key: CASSANDRA-17164 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17164 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Coordination, Consistency/Repair >Reporter: Benedict Elliott Smith >Assignee: Benedict Elliott Smith >Priority: Normal > Fix For: 4.1 > > > This ticket encompasses work for [CEP-14| > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-14%3A+Paxos+Improvements]. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17164) CEP-14: Paxos Improvements
[ https://issues.apache.org/jira/browse/CASSANDRA-17164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17509055#comment-17509055 ] Stefan Miklosovic commented on CASSANDRA-17164: --- [~adelapena] would you cover me here mate? I am out, filled other tickets and this one just slipped through. > CEP-14: Paxos Improvements > -- > > Key: CASSANDRA-17164 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17164 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Coordination, Consistency/Repair >Reporter: Benedict Elliott Smith >Assignee: Benedict Elliott Smith >Priority: Normal > Fix For: 4.1 > > > This ticket encompasses work for [CEP-14| > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-14%3A+Paxos+Improvements]. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17164) CEP-14: Paxos Improvements
[ https://issues.apache.org/jira/browse/CASSANDRA-17164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17509056#comment-17509056 ] Ekaterina Dimitrova commented on CASSANDRA-17164: - I will open a ticket. Thanks for the quick response > CEP-14: Paxos Improvements > -- > > Key: CASSANDRA-17164 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17164 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Coordination, Consistency/Repair >Reporter: Benedict Elliott Smith >Assignee: Benedict Elliott Smith >Priority: Normal > Fix For: 4.1 > > > This ticket encompasses work for [CEP-14| > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-14%3A+Paxos+Improvements]. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17164) CEP-14: Paxos Improvements
[ https://issues.apache.org/jira/browse/CASSANDRA-17164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17509064#comment-17509064 ] Ekaterina Dimitrova commented on CASSANDRA-17164: - CASSANDRA-17456 opened. I will link it to this one > CEP-14: Paxos Improvements > -- > > Key: CASSANDRA-17164 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17164 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Coordination, Consistency/Repair >Reporter: Benedict Elliott Smith >Assignee: Benedict Elliott Smith >Priority: Normal > Fix For: 4.1 > > > This ticket encompasses work for [CEP-14| > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-14%3A+Paxos+Improvements]. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org