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

Stefania commented on CASSANDRA-11225:
--------------------------------------

It seems your observation is correct. StorageProxy has a method, 
{{getLiveSortedEndpoints()}}, which is called by the read executor to determine 
the target replicas to contact. This method, in turn relies on 
{{IEndpointSnitch.sortByProximity(localhost, liveendpoints)}} and 
{{SimpleSnitch}} does not implement this method. So we are not guaranteed the 
coordinator is the first chosen replica in this case. {{SimpleSnitch}} is the 
default snitch in cassandra.yaml and ccm only changes the snitch to 
{{PropertyFileSnitch}} for multi data center tests.

Another interesting thing to point out, when writing counter mutations, is that 
in storage proxy {{mutateCounter()}}, the leader is not necessarily the local 
host because {{findSuitableEndpoint()}} picks a random local endpoint. So we 
are not guaranteed the coordinator is the mutation leader even it is a replica. 
This shouldn't matter though, as long as we write to the requested number of 
replicas, which is what we are trying to test really.

As for reading though, if we cannot read from the replica we have contacted, 
then this test needs to be changed to only validate the strong consistency 
cases,  that is R + W > RF. I've amended the patch so that we use 
{{PropertyFileSnitch}} for the single data center tests as well. If my 
reasoning is correct, the coordinator should always choose itself as the 
preferred replica, and the test should pass all the times. If this is not the 
case however,  then we can change the test to only validate strong consistency, 
since we are not guaranteed to be able to read from a specific replica then I 
am not sure how to test that we have written to a specific number of replicas.

> dtest failure in consistency_test.TestAccuracy.test_simple_strategy_counters
> ----------------------------------------------------------------------------
>
>                 Key: CASSANDRA-11225
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-11225
>             Project: Cassandra
>          Issue Type: Test
>            Reporter: Russ Hatch
>            Assignee: Russ Hatch
>              Labels: dtest
>
> example failure:
> http://cassci.datastax.com/job/cassandra-2.1_novnode_dtest/209/testReport/consistency_test/TestAccuracy/test_simple_strategy_counters
> Failed on CassCI build cassandra-2.1_novnode_dtest #209
> error: "AssertionError: Failed to read value from sufficient number of nodes, 
> required 2 but got 1 - [574, 2]"



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to