[
https://issues.apache.org/jira/browse/CASSANDRA-7041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13970601#comment-13970601
]
Ngoc Minh Vo edited comment on CASSANDRA-7041 at 4/17/14 11:37 AM:
-------------------------------------------------------------------
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)-
This issue appears in multiple tables, not only the simple string_values one.
Thanks in advance for your help.
Best regards,
Minh
was (Author: vongocminh):
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)
