hadoop-common-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Nauroth (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HADOOP-12334) Change Mode Of Copy Operation of HBase WAL Archiving to bypass Azure Storage Throttling after retries
Date Tue, 08 Sep 2015 23:47:46 GMT

    [ https://issues.apache.org/jira/browse/HADOOP-12334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14735851#comment-14735851

Chris Nauroth commented on HADOOP-12334:

Hello [~gouravk].  Thank you for the patch.  I have a few comments.

          if(srcBlob.getProperties().getBlobType() == BlobType.PAGE_BLOB){

Is it necessary to check that it's a page blob?  Would the same logic also be useful for block


Here, if {{opStream.flush()}} throws an exception, then {{opStream}} and {{ipStream}} won't
get closed.  Likewise, if {{opStream.close()}} throws an exception, then {{ipStream}} won't
get closed.  I recommend using try-with-resources to guarantee the resources get closed.

Is it possible to cover the new functionality with a unit test, perhaps using mocks to inject
an exception with {{SERVER_BUSY}} as the reason?

> Change Mode Of Copy Operation of HBase WAL Archiving to bypass Azure Storage Throttling
after retries
> -----------------------------------------------------------------------------------------------------
>                 Key: HADOOP-12334
>                 URL: https://issues.apache.org/jira/browse/HADOOP-12334
>             Project: Hadoop Common
>          Issue Type: Improvement
>          Components: tools
>            Reporter: Gaurav Kanade
>            Assignee: Gaurav Kanade
>         Attachments: HADOOP-12334.01.patch, HADOOP-12334.02.patch, HADOOP-12334.03.patch,
HADOOP-12334.04.patch, HADOOP-12334.05.patch
> HADOOP-11693 mitigated the problem of HMaster aborting regionserver due to Azure Storage
Throttling event during HBase WAL archival. The way this was achieved was by applying an intensive
exponential retry when throttling occurred.
> As a second level of mitigation we will change the mode of copy operation if the operation
fails even after all retries -i.e. we will do a client side copy of the blob and then copy
it back to destination. This operation will not be subject to throttling and hence should
provide a stronger mitigation. However it is more expensive, hence we do it only in the case
we fail after all retries

This message was sent by Atlassian JIRA

View raw message