[ https://issues.apache.org/jira/browse/CASSANDRA-7599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Tyler Hobbs updated CASSANDRA-7599: ----------------------------------- Attachment: 7599.txt The solution was to pass the TracingState to the thread pool executor for local range slices. I also noticed that the READ verb was being used for local range slices instead of RANGE_SLICE, so the timeout and dropped message counts were incorrect. 7599.txt (and [branch|https://github.com/thobbs/cassandra/tree/CASSANDRA-7599]) fixes both of those issues. > Dtest on low cardinality secondary indexes failing in 2.1 > --------------------------------------------------------- > > Key: CASSANDRA-7599 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7599 > Project: Cassandra > Issue Type: Bug > Components: Core, Tests > Reporter: Shawn Kumar > Assignee: Tyler Hobbs > Fix For: 2.1.0 > > Attachments: 7599.txt > > > test_low_cardinality_indexes in secondary_indexes_test.py is failing when > tested on the cassandra-2.1 branch. This test has been failing on cassci for > a while (at least the last 10 builds) and can easily be reproduced locally as > well. It appears to still work on 2.0. > {code} > ====================================================================== > FAIL: test_low_cardinality_indexes > (secondary_indexes_test.TestSecondaryIndexes) > ---------------------------------------------------------------------- > Traceback (most recent call last): > File "/home/shawn/git/cstar5/cassandra-dtest/tools.py", line 213, in wrapped > f(obj) > File "/home/shawn/git/cstar5/cassandra-dtest/secondary_indexes_test.py", > line 89, in test_low_cardinality_indexes > check_request_order() > File "/home/shawn/git/cstar5/cassandra-dtest/secondary_indexes_test.py", > line 84, in check_request_order > self.assertTrue('Executing indexed scan' in relevant_events[-1][0], > str(relevant_events[-1])) > AssertionError: (u'Enqueuing request to /127.0.0.2', '127.0.0.1') > {code} > The test checks that a series of messages are found in the trace after a > select query against an index is carried out. It fails to find an 'Executing > indexed scan' from node 1 (which takes the query, note both node2 and node3 > produced this message). Brief investigation seemed to show that whichever > node you create the patient_cql_connection on will not produce this message, > indicating perhaps it does not carry out the scan. Should also note that > changing 'numrows' (rows initially added) or 'b' (value on index column we > query for) does not appear to make a difference. -- This message was sent by Atlassian JIRA (v6.2#6252)