[ https://issues.apache.org/jira/browse/CASSANDRA-11473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Tyler Hobbs updated CASSANDRA-11473: ------------------------------------ Summary: Clustering column value is zeroed out in some query results (was: Inconsistent query results) > Clustering column value is zeroed out in some query results > ----------------------------------------------------------- > > Key: CASSANDRA-11473 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11473 > Project: Cassandra > Issue Type: Bug > Environment: debian jessie patch current with Cassandra 3.0.4 > Reporter: Jason Kania > > As per a discussion on the mailing list, > http://www.mail-archive.com/user@cassandra.apache.org/msg46902.html, we are > encountering inconsistent query results when the following query is run: > {noformat} > select "subscriberId","sensorUnitId","sensorId","time" from > "sensorReadingIndex" where "subscriberId"='JASKAN' AND "sensorUnitId"=0 AND > "sensorId"=0 ORDER BY "time" LIMIT 10; > {noformat} > Invalid Query Results > {noformat} > subscriberId sensorUnitId sensorId time > JASKAN 0 0 2015-05-24 2:09 > JASKAN 0 0 1969-12-31 19:00 > JASKAN 0 0 2016-01-21 2:10 > JASKAN 0 0 2016-01-21 2:10 > JASKAN 0 0 2016-01-21 2:10 > JASKAN 0 0 2016-01-21 2:11 > JASKAN 0 0 2016-01-21 2:22 > JASKAN 0 0 2016-01-21 2:22 > JASKAN 0 0 2016-01-21 2:22 > JASKAN 0 0 2016-01-21 2:22 > {noformat} > Valid Query Results > {noformat} > subscriberId sensorUnitId sensorId time > JASKAN 0 0 2015-05-24 2:09 > JASKAN 0 0 2015-05-24 2:09 > JASKAN 0 0 2015-05-24 2:10 > JASKAN 0 0 2015-05-24 2:10 > JASKAN 0 0 2015-05-24 2:10 > JASKAN 0 0 2015-05-24 2:10 > JASKAN 0 0 2015-05-24 2:11 > JASKAN 0 0 2015-05-24 2:13 > JASKAN 0 0 2015-05-24 2:13 > JASKAN 0 0 2015-05-24 2:14 > {noformat} > Running the following yields no rows indicating that the 1969... timestamp is > invalid. > {noformat} > select "subscriberId","sensorUnitId","sensorId","time" FROM > "edgeTransitionIndex" where "subscriberId"='JASKAN' AND "sensorUnitId"=0 AND > "sensorId"=0 and time='1969-12-31 19:00:00-0500'; > {noformat} > The schema is as follows: > {noformat} > CREATE TABLE sensorReading."sensorReadingIndex" ( > "subscriberId" text, > "sensorUnitId" int, > "sensorId" int, > time timestamp, > "classId" int, > correlation float, > PRIMARY KEY (("subscriberId", "sensorUnitId", "sensorId"), time) > ) WITH CLUSTERING ORDER BY (time ASC) > AND bloom_filter_fp_chance = 0.01 > AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'} > AND comment = '' > AND compaction = {'class': > 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy', > 'max_threshold': '32', 'min_threshold': '4'} > AND compression = {'chunk_length_in_kb': '64', 'class': > 'org.apache.cassandra.io.compress.LZ4Compressor'} > AND crc_check_chance = 1.0 > AND dclocal_read_repair_chance = 0.1 > AND default_time_to_live = 0 > AND gc_grace_seconds = 864000 > AND max_index_interval = 2048 > AND memtable_flush_period_in_ms = 0 > AND min_index_interval = 128 > AND read_repair_chance = 0.0 > AND speculative_retry = '99PERCENTILE'; > CREATE INDEX classSecondaryIndex ON sensorReading."sensorReadingIndex" > ("classId"); > {noformat} > We were asked to provide our sstables as well but these are very large and > would require some data obfuscation. We are able to run code or scripts > against the data on our servrers if that is option. -- This message was sent by Atlassian JIRA (v6.3.4#6332)