cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shawn Kumar (JIRA)" <j...@apache.org>
Subject [jira] [Created] (CASSANDRA-7599) Dtest on low cardinality secondary indexes failing in 2.1
Date Wed, 23 Jul 2014 17:27:38 GMT
Shawn Kumar created CASSANDRA-7599:
--------------------------------------

             Summary: 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: Tests
            Reporter: Shawn Kumar
             Fix For: 2.1.0


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)

Mime
View raw message