[
https://issues.apache.org/jira/browse/HDFS-6772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14089597#comment-14089597
]
Arpit Agarwal commented on HDFS-6772:
-------------------------------------
[~mingma], I was unsure whether this delta can result in lost commands, since
it will cause the caller {{processCommands}} to discard any subsequent commands.
{code}
---
a/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/datanode/BPOfferService.java
+++
b/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/datanode/BPOfferService.java
@@ -531,7 +531,7 @@ boolean processCommandFromActor(DatanodeCommand cmd,
LOG.info("DatanodeCommand action : DNA_REGISTER from " + actor.nnAddr
+ " with " + actor.state + " state");
actor.reRegister();
- return true;
+ return false;
{code}
On further investigation it works because RegisterCommand is sent by itself.
Could you please add a comment to {{RegisterCommand}} stating it must not be
combined with other commands in the same response?
Thanks for adding a test case. I think you can remove this comment _Connection
to NN times due to NN restart._ A timeout is not needed for the test case to
work. The NN will always ask the DN to re-register after restart.
> Get DNs out of blockContentsStale==true state faster when NN restarts
> ---------------------------------------------------------------------
>
> Key: HDFS-6772
> URL: https://issues.apache.org/jira/browse/HDFS-6772
> Project: Hadoop HDFS
> Issue Type: Improvement
> Reporter: Ming Ma
> Assignee: Ming Ma
> Attachments: HDFS-6772.patch
>
>
> Here is the non-HA scenario.
> 1. Get HDFS into block-over-replicated situation.
> 2. Restart the NN.
> 3. From NN's point of view, DNs will remain in blockContentsStale==true state
> for a long time. That in turns make postponedMisreplicatedBlocks size big.
> Bigger postponedMisreplicatedBlocks size will impact blockreport latency.
> Given blockreport takes NN global lock, it has severe impact on NN
> performance and make the cluster unstable.
> Why will DNs remain in blockContentsStale==true state for a long time?
> 1. When a DN reconnect to NN upon NN restart, blockreport RPC could come in
> before heartbeat RPC. That is due to how BPServiceActor#offerService decides
> when to send blockreport and heartbeat. In the case of NN restart, NN will
> ask DN to register when NN gets the first heartbeat request; DN will then
> register with NN; followed by blockreport RPC; the heartbeat RPC will come
> after that.
> 2. So right after the first blockreport, given heartbeatedSinceFailover
> remains false, blockContentsStale will stay true.
> {noformat}
> DatanodeStorageInfo.java
> void receivedBlockReport() {
> if (heartbeatedSinceFailover) {
> blockContentsStale = false;
> }
> blockReportCount++;
> }
> {noformat}
> 3. So the DN will remain in blockContentsStale==true until the next
> blockreport. For big cluster, dfs.blockreport.intervalMsec could be set to
> some large value.
>
--
This message was sent by Atlassian JIRA
(v6.2#6252)
