[ 
https://issues.apache.org/jira/browse/HBASE-22634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16873480#comment-16873480
 ] 

Sebastien Barnoud commented on HBASE-22634:
-------------------------------------------

For the flush, 

 
{code:java}
private void timerCallbackForWriteBufferPeriodicFlush() {
    if (currentWriteBufferSize.get() == 0) {
        return; // Nothing to flush
    }
    long now = System.currentTimeMillis();
    if (firstRecordInBufferTimestamp.get() + 
writeBufferPeriodicFlushTimeoutMs.get() > now) {
        return; // No need to flush yet
    }
    // The first record in the writebuffer has been in there too long --> flush
    try {
        executedWriteBufferPeriodicFlushes.incrementAndGet();
        flush();
    } catch (InterruptedIOException | RetriesExhaustedWithDetailsException e) {
        LOG.error("Exception during timerCallbackForWriteBufferPeriodicFlush 
--> " + e.getMessage());
    }
}
{code}

As explained in the current comment, timerCallbackForWriteBufferPeriodicFlush 
call flush() which is not synchronized, so checkClose() which need to be 
synchronized in this case.
The lock avoid some race condition when the connection is closed between two 
flush interval.

> Improve performance of BufferedMutator
> --------------------------------------
>
>                 Key: HBASE-22634
>                 URL: https://issues.apache.org/jira/browse/HBASE-22634
>             Project: HBase
>          Issue Type: Improvement
>          Components: Client
>    Affects Versions: 2.1.5
>         Environment: HDP 2.6.5
> Linux RedHat
>            Reporter: Sebastien Barnoud
>            Priority: Major
>         Attachments: HBASE-22634.001.branch-2.patch
>
>
> The default ThreadPoolExecutor uses a default size of 1 (property 
> hbase.htable.threads.max). When using a size > 1, we still encountered poor 
> performance and exception while submitting to the pool (pool exceed its 
> capacity).
> This patch propose a fix on different issues encountered when the pool size 
> is > 1:
>  * thread safety issue
>  * concurrent cleanup by Netty and the "legacy" code
>  * errors in the backpressure
>  * Netty memory leak
> And propose a BufferedMutatorThreadPoolExecutor which:
>  * uses hbase.client.max.total.tasks as the default size (instead of 1)
>  * some usefull metrics
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to