You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hbase.apache.org by "Josh Elser (JIRA)" <ji...@apache.org> on 2015/04/29 17:15:06 UTC

[jira] [Commented] (HBASE-13541) Deprecate Scan caching in 2.0.0

    [ https://issues.apache.org/jira/browse/HBASE-13541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14519520#comment-14519520 ] 

Josh Elser commented on HBASE-13541:
------------------------------------

bq. Seems more like a detail that should be controlled from the server based on the current scan request RPC load.

That's a very interesting thought. Could envision a fixed "pool" of memory across all scans that provides a very clear limit on the "high-level" server-side implementation on Scans. I believe this makes sense.

> Deprecate Scan caching in 2.0.0
> -------------------------------
>
>                 Key: HBASE-13541
>                 URL: https://issues.apache.org/jira/browse/HBASE-13541
>             Project: HBase
>          Issue Type: Sub-task
>            Reporter: Jonathan Lawlor
>
> The public Scan API exposes caching to the application. Caching deals with the number of rows that are transferred per scan RPC request issued to the server. It does not seem like a detail that users of a scan should control and introduces some unneeded complication. Seems more like a detail that should be controlled from the server based on the current scan request RPC load. This issue proposes that we deprecate the caching API in 2.0.0 so that it can be removed later. Of course, if there are any concerns please raise them here.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)