[
https://issues.apache.org/jira/browse/HBASE-13362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14391907#comment-14391907
]
Andrew Purtell commented on HBASE-13362:
----------------------------------------
bq. Now, that would not be 100% backwards compatible? OK to change in
0.98/1.0.x?
A change in 0.98 and 1.0 that protects servers against outrageous max result
size values would be a semantic change but I'd argue not having a cap would be
a bug, so this isn't a compat issue as much as a safety/security issue and
let's go ahead and bring it back.
> set max result size from client only (like caching)?
> ----------------------------------------------------
>
> Key: HBASE-13362
> URL: https://issues.apache.org/jira/browse/HBASE-13362
> Project: HBase
> Issue Type: Brainstorming
> Reporter: Lars Hofhansl
>
> With the recent problems we've been seeing client/server result size
> mismatch, I was thinking: Why was this not a problem with scanner caching?
> There are two reasons:
> # number of rows is easy to calculate (and we did it correctly)
> # caching is only controlled from the client, never set on the server alone
> We did fix both #1 and #2 in HBASE-13262.
> Still, I'd like to discuss the following:
> * default the client sent max result size to 2mb
> * remove any server only result sizing
> * continue to use hbase.client.scanner.max.result.size but enforce it via the
> client only (as the name implies anyway).
> Comments? Concerns?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
