[
https://issues.apache.org/jira/browse/HBASE-4143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13072622#comment-13072622
]
Gary Helmling commented on HBASE-4143:
--------------------------------------
{quote}
If single Put isn't batched, I wonder why the user would want to batch list of
{@link Put}s.
{quote}
The current semantics are: if autoflush is enabled, writes are automatically
flushed for you at the end of put(List<Put>); if disabled, then writes are
buffered until the write buffer is full.
I don't really want to change that as part of this issue. As I see it the
intent here is just to respect the write buffer sizing when batching. I just
want to fix an anti-pattern we introduced from an implementation detail of the
original fix.
> HTable.doPut(List) should check the writebuffer length every so often
> ---------------------------------------------------------------------
>
> Key: HBASE-4143
> URL: https://issues.apache.org/jira/browse/HBASE-4143
> Project: HBase
> Issue Type: Improvement
> Reporter: Doug Meil
> Assignee: Doug Meil
> Priority: Minor
> Attachments: HBASE-4143_update.patch, client_HBASE_4143.patch
>
>
> This came up on a dist-list conversation between Andy P., Ted Yu, and myself.
> Andy noted that extremely large lists passed into put(List) can cause
> issues. Ted suggested that having doPut check the write-buffer length every
> so often (5-10 records?) so the flush doesn't happen only at the end, and I
> think that's good idea.
> public void put(final List<Put> puts) throws IOException {
> doPut(puts);
> }
> private void doPut(final List<Put> puts) throws IOException {
> for (Put put : puts) {
> validatePut(put);
> writeBuffer.add(put);
> currentWriteBufferSize += put.heapSize();
> }
> if (autoFlush || currentWriteBufferSize > writeBufferSize) {
> flushCommits();
> }
> }
> Once this change is made, remove the comment in HBASE-4142 about large lists
> being a performance problem.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
