[ https://issues.apache.org/jira/browse/CASSANDRA-3531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13157266#comment-13157266 ]
Jonathan Ellis commented on CASSANDRA-3531: ------------------------------------------- I did some minimal-necessary work to get CLT to pass in trunk, but it sounds like you have deeper changes in mind. > Fix crack-smoking in ConsistencyLevelTest > ------------------------------------------ > > Key: CASSANDRA-3531 > URL: https://issues.apache.org/jira/browse/CASSANDRA-3531 > Project: Cassandra > Issue Type: Bug > Components: Tests > Affects Versions: 1.0.4 > Reporter: Sylvain Lebresne > Priority: Minor > Fix For: 1.0.5 > > > First, let's note that this test fails in current 1.0 branch. It was "broken" > (emphasis on the quotes) by CASSANDRA-3529. But it's not CASSANDRA-3529 > fault, it's only that the use of NonBlockingHashMap changed the order of the > tables returned by Schema.instance.getNonSystemTables(). *And*, it turns out > that ConsistencyLevelTest bails out as soon as it has found one keyspace with > rf >= 2 due to a misplaced return. So it use to be that ConsistencyLevelTest > was only ran for Keyspace5 (whose RF is 2) for which the test work. But for > any RF > 2, the test fails. > The reason of this failing is that the test creates a 3 node cluster for whom > only 1 node is alive as far as the failure detector is concerned. So for RF=3 > and CL=QUORUM, the writes are unavailable (the failure detector is queried), > while for reads we "pretend" two nodes are alive so we end up with a case > where isWriteUnavailable != isReadUnavailable. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira