[
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)
