[
https://issues.apache.org/jira/browse/CASSANDRA-4833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13479358#comment-13479358
]
Tyler Hobbs commented on CASSANDRA-4833:
----------------------------------------
I tested out the patch, and although the infinite loop isn't hit, the resulting
count numbers are off. For example, the repro script has 3050 columns, and
when run produces these counts (manually edited for clarity):
{noformat}
specified count=1024: 1024 expected, got 1024
specified count=2^31: 3050 expected, got 2047
specified count=4000: 3050 expected, got 2047
specified count=3051: 3050 expected, got 2047
specified count=1025: 1025 expected, got 1024
{noformat}
> 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
