[
https://issues.apache.org/jira/browse/HADOOP-12334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14961361#comment-14961361
]
Chris Nauroth commented on HADOOP-12334:
----------------------------------------
Hello [~gouravk]. I would not suggest trying to write a test for this against
live Azure Storage. The patch relates to client-side error handling of
server-side errors. I don't think there is a reliable way to force the service
to return those errors.
Instead, I was thinking we might be able to use mocks to simulate the errors
and confirm that it can fall back to a client-side copy.
{{TestAzureFileSystemErrorConditions}} is an example of a test suite that
already does something similar, so you might try looking at that one as a
sample.
Please take a look, and let me know if you think it can be done or if you think
it's not feasible. Thanks!
> 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-12334.06.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
(v6.3.4#6332)