[
https://issues.apache.org/jira/browse/CASSANDRA-1442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12917645#action_12917645
]
Stu Hood commented on CASSANDRA-1442:
-------------------------------------
> 02 seems like it shouldn't be necessary for a correct solution. thoughts?
I don't see a cleaner alternative... finding the correct place to insert the
minimum token without the support of the iterator implementation would mean
peeking on it to see whether the next token wrapped. This solution is much
shorter, and likely to have applications elsewhere in the codebase.
> Get Range Slices is broken
> --------------------------
>
> Key: CASSANDRA-1442
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1442
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Affects Versions: 0.6.5
> Environment: Linux - CentOs
> Reporter: Moleza Moleza
> Assignee: Jonathan Ellis
> Priority: Critical
> Fix For: 0.6.7, 0.7.0
>
> Attachments:
> 0001-Add-tests-for-StorageProxy.getRestrictedRanges.patch,
> 0002-Allow-ringIterator-to-include-the-minimum-token-and-.patch,
> 0003-Split-the-queryRange-by-ring-and-minimum-tokens.patch,
> 0004-Remove-restrictTo-and-unwrap.patch
>
>
> HI,
> We just recently tried to use 0.6.4 and 0.6.5 in our production environment
> and
> had some serious problem.
> The getRangeSlices functionality is broken.
> We have a cluster of 5 machines.
> We use getRangeSlices to iterate over all of the keys in a cf (2062 keys
> total).
> We are using OrderPreservingPartitioner.
> We use getRangeSlices with KeyRange using keys (not tokens).
> If we set the requestBlockCount (aka: KeyRange.setCount()) to a number
> greater than 2062 we get all keys in one shot (all is good).
> If we try to fetch the keys in smaller blocks (requestBlockCount=100)
> we get BAD RESULTS.
> We get only 800 unique keys back.
> We start with (startKey="" and endKey="") then, after each iteration, we use
> the lastKey to set the startKey for the next page.
> Except on first page, we always skip the first item of the page (knowing that
> it is a repeat, the last one, of the prior page).
> To get the lastKey we tried two strategies: [1] set the lastKey to the last
> item in the page, and [2] use String.compareTo to get the largest ley.
> Neither strategy worked.
> Our keys are strings (obviously the only option in 0.6) that represent
> numbers.
> Some Sample keys are: (in correct lexi order)
> -1
> 11113
> 11457
> 6831
> 7035
> 8060
> 8839
> ------
> This code (without any changes) was working correctly under 0.6.3 (we
> got same response from getRangeSlices if using requestBlockCounts of
> 10,000 or 100).
> We tried it under 0.6.4 and 0.6.5 and it stopped working.
> We reverted back to 0.6.3 and (again, without changing the code) it
> started working again.
> ------
> I tried inserting all the keys into a test cluster of one (1 machine) and it
> worked fine.
> So this must be related to how the page is build in a cluster of more than 1
> nodes.
> We have a cluster of 5 nodes with replication factor of 3.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
