[CASSANDRA-1623] BUG: secondaryIndexes AND multiple index expressions can cause timesouts

• Type: Bug
• Status: Resolved
• Priority: Normal
• Resolution: Fixed
• Fix Version/s: 0.7 beta 3

Environment

centos 5.5

• Severity: Normal
• Assignee: Jonathan Ellis
• Reporter: Jason Tanner

Authors

Jonathan Ellis

Reviewers

Jason Tanner

• Created: 15/Oct/10 19:59
• Updated: 16/Apr/19 09:33
• Resolved: 18/Oct/10 20:42

Description

1. Given this Column Family definition

Column Family Name: Requests
Column Family Type: Standard
Column Sorted By: org.apache.cassandra.db.marshal.UTF8Type
Column Metadata:
Column Name: requested
Validation Class: org.apache.cassandra.db.marshal.UTF8Type
Index Type: KEYS
Column Name: requestor
Validation Class: org.apache.cassandra.db.marshal.UTF8Type
Index Type: KEYS

If I have an entry that has the following column/value pairs:

"request-uuid1" : [

{ "requested","person-uuid1" }

,

{ "requestor","person-uuid2"}

,

{ "is_confirmed","true" }

]

If I do an index lookup (pseudo coded) :

get_index_slices( Connection,
ColumnParent.column_family="Requests",
[

{ "requested","eq", "person-uuid1" }

,

{ "is_confirmed","eq", "false" }

], % Index Expressions
"",100, % StartKey, KeyCount
"","",false,100 % StartCol, EndCol, Reversed, ColCount )

for "requested" = "person-uuid1" and "is_confirmed" = false

then I get the following entries in my log and the request times out along with all other requests on all clients.

DEBUG [pool-1-thread-10] 2010-10-15 19:00:27,878 CassandraServer.java (line 531) scan
DEBUG [pool-1-thread-10] 2010-10-15 19:00:27,897 StorageProxy.java (line 563) restricted single token match for query [0,0]
DEBUG [pool-1-thread-10] 2010-10-15 19:00:27,897 StorageProxy.java (line 649) scan ranges are [0,0]
DEBUG [pool-1-thread-10] 2010-10-15 19:00:27,925 StorageProxy.java (line 669) reading org.apache.cassandra.db.IndexScanCommand@42a6eb from 52@localhost/127.0.0.1
DEBUG [ReadStage:2] 2010-10-15 19:00:27,931 SliceQueryFilter.java (line 121) collecting 0 of 1: null:false:0@1287103291
DEBUG [ReadStage:2] 2010-10-15 19:00:27,933 SliceQueryFilter.java (line 121) collecting 0 of 2147483647: is_confirmed:false:4@1287103291
DEBUG [ReadStage:2] 2010-10-15 19:00:27,934 SliceQueryFilter.java (line 121) collecting 1 of 2147483647: request_type:false:6@1287103291
DEBUG [ReadStage:2] 2010-10-15 19:00:27,935 SliceQueryFilter.java (line 121) collecting 2 of 2147483647: requested:false:58@1287103291
DEBUG [ReadStage:2] 2010-10-15 19:00:27,935 SliceQueryFilter.java (line 121) collecting 3 of 2147483647: requested_network:false:57@1287103291
DEBUG [ReadStage:2] 2010-10-15 19:00:27,936 SliceQueryFilter.java (line 121) collecting 4 of 2147483647: requestor:false:58@1287103291
DEBUG [ReadStage:2] 2010-10-15 19:00:27,937 SliceQueryFilter.java (line 121) collecting 5 of 2147483647: requestor_network:false:57@1287103291
DEBUG [ReadStage:2] 2010-10-15 19:00:27,942 SliceQueryFilter.java (line 121) collecting 0 of 1: null:false:0@1287103291
DEBUG [ReadStage:2] 2010-10-15 19:00:27,943 SliceQueryFilter.java (line 121) collecting 0 of 1: null:false:0@1287103291
DEBUG [ReadStage:2] 2010-10-15 19:00:27,945 SliceQueryFilter.java (line 121) collecting 0 of 1: null:false:0@1287103291
DEBUG [ReadStage:2] 2010-10-15 19:00:27,946 SliceQueryFilter.java (line 121) collecting 0 of 1: null:false:0@1287103291
this last line repeats forever until I stop the server.

If instead I do the lookup where both terms match or just the last term matches then nothing goes wrong, I get a valid (empty or otherwise) result set.

It only seems to happen if the 2nd expression does not match.

I am using the very latest code from trunk.

Jason