[
https://issues.apache.org/jira/browse/HBASE-15414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15803028#comment-15803028
]
Enis Soztutar commented on HBASE-15414:
---
Thinking about this in the context of HBASE-17408, we still need to protect the
server from a single get result returning a huge row, thus causing OOM. It
happened in a couple of instances where the application without knowing whether
the row grew too large or not does a standard get. Plus since there is no
protection for how large a row can get, and no way to know without actually
doing the get, applications cannot know or recover easily from the situation.
Even with HBASE-14946, the heap size checks are done between Get requests, not
internally like we do with Scans. Returning partial results from multi-get
seems a big complication, but at least we can look into protecting the server
by hooking into the scan limits and throwing an exception back to the
application.
> Bound the size of multi request returns and/or allow return of partial result
> up to client
> --
>
> Key: HBASE-15414
> URL: https://issues.apache.org/jira/browse/HBASE-15414
> Project: HBase
> Issue Type: Improvement
> Components: Client, rpc
>Reporter: stack
>
> Some knowledgeable hbase users note that while Scanning now allows you return
> results in 'chunks' for assembly client-side as a whole result (or the
> application can see the partials as they come out of the cluster), this
> ability is absent if you do a multi-get; you might get back more than you
> bargained for and just as chunking when Scanning makes sense because it makes
> hbase 'regular', we need the same for multiget.
> Parking an issue here for discussion.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
