cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michał Matłoka (JIRA) <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-11299) AssertionError when quering by secondary index
Date Fri, 04 Mar 2016 08:00:51 GMT

    [ 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)

Mime
View raw message