[
https://issues.apache.org/jira/browse/CASSANDRA-14705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16612761#comment-16612761
]
Benedict commented on CASSANDRA-14705:
--------------------------------------
So, my personal view on TODOs is that they can be much more useful left inline
with their context, for when you or somebody else next comes to touch the
surrounding code - whether in the intended JIRA, or another related one.
They're also a bit specific for a JIRA, they're more guidance for what to
consider when shaping your next solution.
They're like documentation, only they document inadequacy, things for the next
author to watch out for, and a suggestion that (if time permits) they resolve
them at the same time.
There are multiple JIRA filed already for these code paths, any of which might
hopefully encompass refactoring / fixing these TODOs.
{quote}If you could remove that one code comment, maybe clean it up to only
refer to the one ReplicaPlan
{quote}
Which one? The one I saw was already missing from the code, hence the comment
being out of date for the PR (and my missing it) on GitHub UI.
> ReplicaLayout follow-up
> -----------------------
>
> Key: CASSANDRA-14705
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14705
> 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
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
