[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
