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

Bill Mitchell commented on CASSANDRA-6826:
------------------------------------------

Much as I found Sylvain's suggestion plausible, no, it does not explain this 
problem.  After installing the Apache Cassandra 2.0.6 build, the first time I 
tried this, it still failed.  

Unfortunately, the problem is data or timing dependent.  After seeing the 
failure on 2.0.6, I changed the test case to write all the rows into one 
partition, and that worked, so I changed it back to distributing the rows over 
6 partitions, and this time that worked, too.  So we were "lucky" that the 
first time I tried this, the failure did appear.  

(I should have noticed that CASSANDRA-6748 appeared only when a column was 
explicitly set to null.  That was the behavior of my code about two weeks ago, 
before I discovered the issues around having a large number of tombstones in a 
wide row.)  

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

Reply via email to