[
https://issues.apache.org/jira/browse/CASSANDRA-4833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yuki Morishita updated CASSANDRA-4833:
--------------------------------------
Attachment: 4833-1.1.txt
You are right.
New version attached. I also modified test to match yours.
get_count pages when requesting count more than page size (determined by
average column size but max at 1024). Paging starts with the last column of
previously fetched page, so newly fetched page may contains one overlapped
column.
When page size is 1024, and we have more than 1024 columns in a row, counting
with limit of 1025 columns always fails because we fetch 1 (1025 - 1024 page
size) column on 2nd page and it contains only already fetched column. Same
thing can happen around the actual number of columns in a row.
Attached patch modified so that paging will fetch at least two columns.
> 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
