[
https://issues.apache.org/jira/browse/HBASE-13442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14505904#comment-14505904
]
stack commented on HBASE-13442:
-------------------------------
Yeah, purge/deprecate caching and purge/deprecate rpc row limit for reasons you
all give above. I'd go further and purge setting size on a Scan too while we
are at it... Let RPC or server-side figure what is best size to chunk responses
in... Having the Scan setting size is wonky especially when many concurrent
scans going on.
Regard's Daves row limit, suggest that that be done via a filter rather than
sully base Scan API since I think it qualifies as exotic.
> Rename scanner caching to a more semantically correct term such as row limit
> ----------------------------------------------------------------------------
>
> Key: HBASE-13442
> URL: https://issues.apache.org/jira/browse/HBASE-13442
> Project: HBase
> Issue Type: Sub-task
> Reporter: Jonathan Lawlor
> Attachments: HBASE-13442-proposal.diff
>
>
> Caching acts more as a row limit now. By default in branch-1+, a Scan is
> configured with (caching=Integer.MAX_VALUE, maxResultSize=2MB) so that we
> service scans on the basis of buffer size rather than number of rows. As a
> result, caching should now only be configured in instances where the user
> knows that they will only need X rows. Thus, caching should be renamed to
> something that is more semantically correct such as rowLimit.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
