cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ariel Weisberg (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-14705) ReplicaLayout follow-up
Date Wed, 12 Sep 2018 21:43:00 GMT


Ariel Weisberg commented on CASSANDRA-14705:

[This is what I was talking about|].
Couldn't this refer to the CL from the parameter ReplicaPlan? Can you remove the TODO?

> ReplicaLayout follow-up
> -----------------------
>                 Key: CASSANDRA-14705
>                 URL:
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Benedict
>            Assignee: Benedict
>            Priority: Major
> Clarify the new {{ReplicaLayout}} code, separating it into ReplicaPlan (for what we want
to do) and {{ReplicaLayout}} (for what we know about the cluster), with well defined semantics
(and comments in the rare cases those semantics are weird)
> Found and fixed some bugs:
>  * {{commitPaxos}} was using only live nodes, when needed to include down
>  * We were not writing to pending transient replicas
>  * On write, we were not hinting to full nodes with transient replication enabled (since
we filtered to {{liveOnly}}, in order to include our transient replicas above {{blockFor}})
>  * If we speculated, in {{maybeSendAdditionalReads}} (in read repair) we would only consult
the same node we had speculated too. This also applied to {{maybeSendAdditionalWrites}} -
and this issue was also true pre-TR.
>  * Transient->Full movements mishandled consistency level upgrade
>  ** While we need to treat a transitioning node as ‘full’ for writes, so that it
can safely begin serving full data requests once it has finished, we cannot maintain it in
the ‘pending’ collection else we will also increase our consistency requirements by a
node that doesn’t exist.

This message was sent by Atlassian JIRA

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message