[
https://issues.apache.org/jira/browse/CASSANDRA-6826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13982679#comment-13982679
]
Bill Mitchell commented on CASSANDRA-6826:
------------------------------------------
Thank you for calling my attention to its release; the last time I checked the
DataStax site, I did not yet see it, and once again I forgot to check the
Apache site directly.
Although in my first 2.0.7 tests I saw a failure, I was trying something new,
to use fetchMoreResults now that fetchSize was supposed to be fixed. Further
testing has convinced me that these failures are new issues, different from
this report. The specific test that failed for me above works in 2.0.7, so,
yes, I believe this problem is fixed.
> Query returns different number of results depending on fetchsize
> ----------------------------------------------------------------
>
> Key: CASSANDRA-6826
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6826
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: quad-core Windows 7 x64, single node cluster
> Cassandra 2.0.5
> Reporter: Bill Mitchell
> Assignee: Sylvain Lebresne
>
> I issue a query across the set of partitioned wide rows for one logical row,
> where s, l, and partition specify the composite primary key for the row:
> SELECT ec, ea, rd FROM sr WHERE s = ? and partition IN ? and l = ? ALLOW
> FILTERING;
> If I set fetchSize to only 1000 when the Cluster is configured, the query
> sometimes does not return all the results. In the particular case I am
> chasing, it returns a total of 98586 rows. If I increase the fetchsize to
> 100000, all the 99999 actual rows are returned. This suggests there is some
> problem with fetchsize re-establishing the position on the next segment of
> the result set, at least when multiple partitions are being accessed.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
