Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Thu, 17 Apr 2014 12:46:17 +0000 (UTC)
From: "Sylvain Lebresne (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12708519.1397570074490.131958.1397738777321@arcas>
In-Reply-To: <JIRA.12708519.1397570074490@arcas>
References: <JIRA.12708519.1397570074490@arcas>
Subject: [jira] [Commented] (CASSANDRA-7041) Select query returns
 inconsistent result
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Sylvain Lebresne commented on CASSANDRA-7041:
---------------------------------------------

I see nothing here that indicates that you're using QUORUM consistency (and you do have 4 nodes, though you didn't indicated your replication factor). cqlsh uses CL.ONE by default in particular. If you don't use QUORUM consistency (and your replication factor is > 1), then what you see is perfectly expected.

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