You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Ngoc Minh Vo (JIRA)" <ji...@apache.org> on 2014/04/16 11:20:17 UTC

[jira] [Commented] (CASSANDRA-7041) Select query returns inconsistent result

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

Ngoc Minh Vo commented on CASSANDRA-7041:
-----------------------------------------

We implemented a test method in Java client to estimate the number of attempts required, for a failing query, to get a expected/non-empty result.
The number of attempts is between 2 and ~40 and it very random...

No issue detected in other column families having more complicated schemas.
Hence, it might relate to CF without "data" columns? (i.e. all columns are part of Primary Key)

Thanks in advance for your help.
Best regards,
Minh

> Select query returns inconsistent result
> ----------------------------------------
>
>                 Key: CASSANDRA-7041
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-7041
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>         Environment: Cassandra v2.0.6 (upgraded from v2.0.3)
> 4-node cluster: Windows7, 12GB JVM
>            Reporter: Ngoc Minh Vo
>            Priority: Critical
>
> Hello,
> We are running in an issue with C* v2.0.x: CQL queries randomly return empty result.
> Here is the scenario:
> 1. Schema:
> {noformat}
> CREATE TABLE string_values (
>   date int,
>   field text,
>   value text,
>   PRIMARY KEY ((date, field), value)
> ) WITH
>   bloom_filter_fp_chance=0.100000 AND
>   caching='KEYS_ONLY' AND
>   comment='' AND
>   dclocal_read_repair_chance=0.000000 AND
>   gc_grace_seconds=864000 AND
>   index_interval=128 AND
>   read_repair_chance=0.100000 AND
>   replicate_on_write='true' AND
>   populate_io_cache_on_flush='false' AND
>   default_time_to_live=0 AND
>   speculative_retry='99.0PERCENTILE' AND
>   memtable_flush_period_in_ms=0 AND
>   compaction={'class': 'LeveledCompactionStrategy'} AND
>   compression={'sstable_compression': 'LZ4Compressor'};
> {noformat}
> 2. There is no new data imported to the cluster during the test.
> 3. CQL query:
> {noformat}
> select * from string_values where date=20140122 and field='SCONYKSP1';
> {noformat}
> 4. In Cqlsh, the same query has been executed several times during a short interval (~1-2 seconds). The first query results are empty and then we got the data. And from that point, we always get the correct result:
> {noformat}
> cqlsh:titan_test> select * from string_values where date=20140122 and field='SCONYKSP1';
> (0 rows)
> cqlsh:titan_test> select * from string_values where date=20140122 and field='SCONYKSP1';
> (0 rows)
> ... ...
> cqlsh:titan_test> select * from string_values where date=20140122 and field='SCONYKSP1';
> (0 rows)
> cqlsh:titan_test> select * from string_values where date=20140122 and field='SCONYKSP1';
> (0 rows)
> cqlsh:titan_test> select * from string_values where date=20140122 and field='SCONYKSP1';
>  date     | field     | value
> ----------+-----------+-------------------------
>  20140122 | SCONYKSP1 | 201401220251826297a_0_3
> (1 rows)
> cqlsh:titan_test> select * from string_values where date=20140122 and field='SCONYKSP1';
>  date     | field     | value
> ----------+-----------+-------------------------
>  20140122 | SCONYKSP1 | 201401220251826297a_0_3
> (1 rows)
> {noformat}
> 5. It might relate to some kind of "warmup" process. We tried to disable key/data caching but it does not help.
> Upgrading cluster from v2.0.3 to v2.0.6 does not fix the issue (hence, not related to CASSANDRA-6555).
> Long time ago, we posted a report on Java Driver JIRA: https://datastax-oss.atlassian.net/browse/JAVA-217. But it seems that the issue is in the server side.
> Best regards,
> Minh



--
This message was sent by Atlassian JIRA
(v6.2#6252)