[ 
https://issues.apache.org/jira/browse/CASSANDRA-11299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15179530#comment-15179530
 ] 

Michał Matłoka commented on CASSANDRA-11299:
--------------------------------------------

{code}
CREATE TABLE mykeyspace.mytable (
    id text PRIMARY KEY,
    attributes map<text, text>,
    someflag boolean,
    sometimestamp1 timestamp,
    sometimestamp2 timestamp,
    sometimestamp3 timestamp,
    sometimestamp4 timestamp,
    sometimestamp5 timestamp,
    someotherflag boolean,
    systemotherattributes map<text, text>
) WITH 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 mytable_sometimestamp1_idx ON mykeyspace.mytable (sometimestamp1);
CREATE INDEX mytable_someflag_idx ON mykeyspace.mytable (someflag);
CREATE INDEX mytable_systemotherattributes_idx ON mykeyspace.mytable 
(keys(systemotherattributes));
{code}
so using those column names the problematic queries were e.g.:
{code}
select * from table where someflag = true;
{code}
{code}
select * from table where systemotherattributes contains key 'Sth';
{code}
{code}
select * from table where someflag = true and sometimestamp1 > '2016....';
{code}

> AssertionError when quering by secondary index
> ----------------------------------------------
>
>                 Key: CASSANDRA-11299
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-11299
>             Project: Cassandra
>          Issue Type: Bug
>         Environment: Cassandra 3.3
>            Reporter: Michał Matłoka
>
> Hi,
> Recently we have upgraded from Cassandra 2.2.4 to 3.3. I have issues with one 
> table. When I try to query using any secondary index I get e.g. in cqlsh
> {code}
> Traceback (most recent call last):
>   File "/usr/bin/cqlsh.py", line 1249, in perform_simple_statement
>     result = future.result()
>   File 
> "/usr/share/cassandra/lib/cassandra-driver-internal-only-3.0.0-6af642d.zip/cassandra-driver-3.0.0-6af642d/cassandra/cluster.py",
>  line 3122, in result
>     raise self._final_exception
> ReadFailure: code=1300 [Replica(s) failed to execute read] message="Operation 
> failed - received 0 responses and 1 failures" info={'failures': 1, 
> 'received_responses': 0, 'required_responses': 1, 'consistency': 'ONE'}
> {code}
> Node logs shows then:
> {code}
> [[AWARN  [SharedPool-Worker-2] 2016-03-03 00:47:01,679 
> AbstractLocalAwareExecutorService.java:169 - Uncaught exception on thread 
> Thread[SharedPool-Worker-2,5,main]: {}
> java.lang.AssertionError: null
>         at 
> org.apache.cassandra.index.internal.composites.CompositesSearcher$1Transform.findEntry(CompositesSearcher.java:225)
>  ~[apache-cassandra-3.3.0.jar:3.3.0]
>         at 
> org.apache.cassandra.index.internal.composites.CompositesSearcher$1Transform.applyToRow(CompositesSearcher.java:215)
>  ~[apache-cassandra-3.3.0.jar:3.3.0]
>         at 
> org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:116) 
> ~[apache-cassandra-3.3.0.jar:3.3.0]
>         at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:133)
>  ~[apache-cassandra-3.3.0.jar:3.3.0]
>         at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:89)
>  ~[apache-cassandra-3.3.0.jar:3.3.0]
>         at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:79)
>  ~[apache-cassandra-3.3.0.jar:3.3.0]
>         at 
> org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$Serializer.serialize(UnfilteredPartitionIterators.java:294)
>  ~[apache-cassandra-3.3.0.jar:3.3.0]
>         at 
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.build(ReadResponse.java:134)
>  ~[apache-cassandra-3.3.0.jar:3.3.0]
>         at 
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.<init>(ReadResponse.java:127)
>  ~[apache-cassandra-3.3.0.jar:3.3.0]
>         at 
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.<init>(ReadResponse.java:123)
>  ~[apache-cassandra-3.3.0.jar:3.3.0]
>         at 
> org.apache.cassandra.db.ReadResponse.createDataResponse(ReadResponse.java:65) 
> ~[apache-cassandra-3.3.0.jar:3.3.0]
>         at 
> org.apache.cassandra.db.ReadCommand.createResponse(ReadCommand.java:292) 
> ~[apache-cassandra-3.3.0.jar:3.3.0]
>         at 
> org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:1789)
>  ~[apache-cassandra-3.3.0.jar:3.3.0]
>         at 
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2457)
>  ~[apache-cassandra-3.3.0.jar:3.3.0]
>         at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> ~[na:1.8.0_66]
>         at 
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:164)
>  ~[apache-cassandra-3.3.0.jar:3.3.0]
>         at 
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:136)
>  [apache-cassandra-3.3.0.jar:3.3.0]
>         at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105) 
> [apache-cassandra-3.3.0.jar:3.3.0]
>         at java.lang.Thread.run(Thread.java:745) [na:1.8.0_66]
> {code}
> SStables are upgraded, I have tried repair and scrub. I have tried to rebuild 
> indexes, and even remove them and re-add them.It occurs on every cluster node.
> Additionally I had seen in this table case where PRIMARY KEY was 
> duplicated!!! (there were two rows with same primary key, by seeing what 
> columns were set I can say one was older, and second was from newer query 
> which sets only a subset of columns)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to