[
https://issues.apache.org/jira/browse/CASSANDRA-4833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13480532#comment-13480532
]
Tyler Hobbs commented on CASSANDRA-4833:
----------------------------------------
The latest patch fixes the issue and passes all of the pycassa tests.
One comment on this conditional:
{code}
if (requestedCount == 0 || columns.size() < predicate.slice_range.count)
break;
{code}
Since you're no longer decrementing requestedCount, the first half of the
disjunction isn't needed. If the user actually set a requestedCount of 0, the
first column slice would be empty, so we wouldn't get this far.
Other than that, I'm +1 on the changes
> get_count with 'count' param between 1024 and ~actual column count fails
> ------------------------------------------------------------------------
>
> Key: CASSANDRA-4833
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4833
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Affects Versions: 1.1.6, 1.2.0 beta 1
> Reporter: Tyler Hobbs
> Assignee: Yuki Morishita
> Attachments: 4833-1.1.txt, 4833-get-count-repro.py
>
>
> If you run get_count() with the 'count' param of the SliceRange set to a
> number between 1024 and (approximately) the actual number of columns in the
> row, something seems to silently fail internally, resulting in a client side
> timeout. Using a 'count' param outside of this range (lower or much higher)
> works just fine.
> This seems to affect all of 1.1 and 1.2.0-beta1, but not 1.0.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
