cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tyler Hobbs (JIRA)" <>
Subject [jira] [Updated] (CASSANDRA-7599) Dtest on low cardinality secondary indexes failing in 2.1
Date Wed, 23 Jul 2014 22:10:38 GMT


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|]) fixes both
of those issues.

> Dtest on low cardinality secondary indexes failing in 2.1
> ---------------------------------------------------------
>                 Key: CASSANDRA-7599
>                 URL:
>             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 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/", line 213, in wrapped
>     f(obj)
>   File "/home/shawn/git/cstar5/cassandra-dtest/", line 89, in
>     check_request_order()
>   File "/home/shawn/git/cstar5/cassandra-dtest/", line 84, in
>     self.assertTrue('Executing indexed scan' in relevant_events[-1][0], str(relevant_events[-1]))
> AssertionError: (u'Enqueuing request to /', '')
> {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

View raw message