[
https://issues.apache.org/jira/browse/HBASE-17408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15796349#comment-15796349
]
stack commented on HBASE-17408:
-------------------------------
bq. Ted, giving more context definitely helps others to follow along.
Yep.
bq. The server would have to buffer up all the responses causing OOM on the
server side.
We need to chunk multiget as we do Scans? HBASE-15414
bq. On the second instance (which is the same reason Ted logged this issue),
the application was doing multi requests with Increment. In this case, it was
doing 15K increments in a single RPC, which would take longer than RPC timeout.
Thats a good one. Thats broke. Yeah, a bound would help piecemealing in
increments in batches < 15k. Thanks makes sense.
> Introduce per request limit by number of mutations
> --------------------------------------------------
>
> Key: HBASE-17408
> URL: https://issues.apache.org/jira/browse/HBASE-17408
> Project: HBase
> Issue Type: Improvement
> Reporter: Ted Yu
>
> HBASE-16224 introduced hbase.client.max.perrequest.heapsize to limit the
> amount of data sent from client.
> We should consider adding per request limit through the number of mutations
> in a batch.
> In recent troubleshooting sessions, customer had to do this in their
> application code to avoid OOME on the server side.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
