cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ngoc Minh Vo (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-7041) Select query returns inconsistent result
Date Thu, 17 Apr 2014 12:59:16 GMT

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

Mime
View raw message