[ 
https://issues.apache.org/jira/browse/CASSANDRA-14705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16611857#comment-16611857
 ] 

Alex Petrov commented on CASSANDRA-14705:
-----------------------------------------

bq. I'm not sure we can - this would be a race condition on the Keyspace.

True, I haven't thought of it. We should probably try to make replication 
factor immutable for the time of query and attached to replica plan at some 
point in future.

bq. Not quite sure what you mean here?  That, for an AbstractBounds, we fully 
cover it?

I mostly meant something like 
[this|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/locator/EndpointsForRange.java#L94-L96].
 Maybe it's actually good to fail queries where we have collected half the 
replicas from one token metadata and the other one from other? Not sure.

bq.  I guess we could have a shared method that accepts a boolean indicating if 
we should throw, if you like? 

We could also leave it for later, really. It's rather minor and I'm not very 
worried about it right now, just thought it's worth persisting it.

bq. ReplicaCount can now use the new count method

Sorry, I was thinking about something different, let's leave it as is.

bq.  so a quick check to confirm sufficiency is, well, sufficient. 

Right, agreed. Maybe if we used a boolean for check and threw if it returned 
{{false}}, we could still consolidate those, but this is also not a huge win.

> 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.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

Reply via email to