[
https://issues.apache.org/jira/browse/CASSANDRA-7041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13972901#comment-13972901
]
Ngoc Minh Vo commented on CASSANDRA-7041:
-----------------------------------------
Hello Sylvain,
Thanks for your prompt answer.
Indeed, the issue is related to discrepancies in our data on date 20140122.
Queries on other dates worked fine.
Change CL to QUORUM solved the issue!
Do we need to set CL to QUORUM on write queries as well?
With the default setting (ONE), we didn't get any error during data import.
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)
