[
https://issues.apache.org/jira/browse/HBASE-11544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14326878#comment-14326878
]
stack commented on HBASE-11544:
-------------------------------
Nice.
A few quick comments.
bq. When the client has defined a filter for their scan that requires the
entire row to be read.
So, even if in excess of the requested size, we'll still return the full row in
this case?
You set some flag on the scanner when it has to do full-row regardless?
Your handling of small scan, not doing partials, makes sense.
bq. When I changed the default value of caching to Integer.MAX_VALUE I was
running into OOME on the server since caching is used to presize the ArrayList
that holds results.
Thats kinda dumb (smile).
Simple solution is fine I'd say. There is no way to know up front how many
Results will be returned.
Otherwise, all sounds great.... let me look at the patch....
> [Ergonomics] hbase.client.scanner.caching is dogged and will try to return
> batch even if it means OOME
> ------------------------------------------------------------------------------------------------------
>
> Key: HBASE-11544
> URL: https://issues.apache.org/jira/browse/HBASE-11544
> Project: HBase
> Issue Type: Bug
> Reporter: stack
> Assignee: Jonathan Lawlor
> Priority: Critical
> Labels: beginner
> Attachments: HBASE-11544-v1.patch
>
>
> Running some tests, I set hbase.client.scanner.caching=1000. Dataset has
> large cells. I kept OOME'ing.
> Serverside, we should measure how much we've accumulated and return to the
> client whatever we've gathered once we pass out a certain size threshold
> rather than keep accumulating till we OOME.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
