[
https://issues.apache.org/jira/browse/HDFS-4591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aaron T. Myers updated HDFS-4591:
---------------------------------
Attachment: HDFS-4591.patch
Here's a patch which addresses the issue by doing a sort of double-checked
locking on the NN HA state. This won't completely eliminate the possibility
that a client will have to wait for a checkpoint before receiving a
StandbyException, but should reduce the likelihood to a very narrow window.
This patch also takes the liberty of fixing three little bugs that I noticed
along the way:
# A bug wherein the getBlocks call was not checking the HA state at all.
# A bug wherein the getBlocks RPC call was checking for super user privilege
twice - once in NameNodeRpcServer and once in BlockManager.
# A bug wherein the getAdditionalDatanode call was checking for writes being
allowed when in fact it is a read-only operation.
All of these bugs seem like they should be innocuous to me, but no reason not
to fix them.
This patch also moves a few checkOperation calls from NameNodeRpcServer into
FSNamesystem to make it more obvious that we're doing the proper double check
on the OperationCategory.
> HA clients can fail to fail over while Standby NN is performing long
> checkpoint
> -------------------------------------------------------------------------------
>
> Key: HDFS-4591
> URL: https://issues.apache.org/jira/browse/HDFS-4591
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: ha, namenode
> Affects Versions: 2.0.4-alpha
> Reporter: Aaron T. Myers
> Assignee: Aaron T. Myers
> Attachments: HDFS-4591.patch
>
>
> Clients know to fail over to talk to the Active NN when they perform an RPC
> to the Standby NN and it throws a StandbyException. However, most places in
> the code that check if the NN is in the standby state do so inside the FSNS
> fsLock. Since this lock is held for the duration of the saveNamespace during
> a checkpoint, StandbyExceptions will not be thrown during this time.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
