[
https://issues.apache.org/jira/browse/HBASE-17647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15865991#comment-15865991
]
Ted Yu commented on HBASE-17647:
--------------------------------
{code}
* Progress towards the size limit has been made. Increment internal
tracking of size progress
*/
- void incrementSizeProgress(long size) {
+ void incrementSizeProgress(long size, long heapSize) {
{code}
We now have two sizes. Please name the existing size parameter so that its
meaning is clear.
Modify javadoc accordingly.
{code}
long getSizeProgress() {
{code}
I think the above method should be renamed to match increment operations (now
that you add getHeapSizeProgress).
> OffheapKeyValue#heapSize() implementation is wrong
> --------------------------------------------------
>
> Key: HBASE-17647
> URL: https://issues.apache.org/jira/browse/HBASE-17647
> Project: HBase
> Issue Type: Sub-task
> Components: regionserver
> Reporter: Anoop Sam John
> Assignee: Anoop Sam John
> Fix For: 2.0.0
>
> Attachments: HBASE-17647.patch
>
>
> We consider the key and data lengths also even though the data is actually in
> off heap area. We should correct it.
> The impact will be at ScannerContext limit tracking where we use heapSize of
> cells to account the result size. So my proposal is to consider the cells
> length and heap size in Limit tracking and accounting. We have a
> maxResultSize which defaults to 2MB. When the sum of all cell's data size
> reaches 'maxResultSize' OR the sum of all cell's heap size reaches
> 'maxResultSize' , we need to send back the RPC response
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
