You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Yifan Cai (Jira)" <ji...@apache.org> on 2021/03/29 23:10:00 UTC

[jira] [Updated] (CASSANDRA-16545) Cluster topology change may produce false unavailable for queries

     [ https://issues.apache.org/jira/browse/CASSANDRA-16545?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yifan Cai updated CASSANDRA-16545:
----------------------------------
     Bug Category: Parent values: Availability(12983)Level 1 values: Unavailable(12994)
       Complexity: Normal
    Discovered By: Code Inspection
         Severity: Low
           Status: Open  (was: Triage Needed)

> Cluster topology change may produce false unavailable for queries
> -----------------------------------------------------------------
>
>                 Key: CASSANDRA-16545
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-16545
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Consistency/Coordination
>            Reporter: Yifan Cai
>            Assignee: Yifan Cai
>            Priority: Normal
>
> When the coordinator processes a query, it first gets the {{ReplicationStrategy}} (RS) from the keyspace to decide the peers to contact. Again, it gets the RS to perform the liveness check for the requested CL. 
> The RS is a volatile filed in Keyspace, and it is possible that those 2 getter calls return different RS values in the presence of cluster topology changes, e.g. add a node, etc. 
> In such scenario, the check at the second step can throw an unexpected unavailable. From the perspective of the query, the cluster can satisfy the CL. 
> We should use a consistent view of RS during the peer selection and CL liveness check. In other word, both steps should reference to the same RS object. It is also more clear and easier to reason about to the clients. Such queries are made before the topology change. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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