[
https://issues.apache.org/jira/browse/HDFS-767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12790226#action_12790226
]
Steve Loughran commented on HDFS-767:
-------------------------------------
I've come across problems w/ random backoff on systems where the entire
building gets powered off and on in one go, everything boots back up, and they
all come up at the same time, all go on the network at the same time, all flood
and then back off. This happens if
* the hardware is identical
* boot time to on-LAN is the same (either PXE time or flash disk)
* the random number generator is driven off the start time of the machine
Accordingly, this code may still have problems in such situations, where the
only workaround is to use a bit of the MAC address as part of your parameters,
to give you something different from everyone else.
> Job failure due to BlockMissingException
> ----------------------------------------
>
> Key: HDFS-767
> URL: https://issues.apache.org/jira/browse/HDFS-767
> Project: Hadoop HDFS
> Issue Type: Improvement
> Reporter: Ning Zhang
> Assignee: Ning Zhang
> Attachments: HDFS-767.patch
>
>
> If a block is request by too many mappers/reducers (say, 3000) at the same
> time, a BlockMissingException is thrown because it exceeds the upper limit (I
> think 256 by default) of number of threads accessing the same block at the
> same time. The DFSClient wil catch that exception and retry 3 times after
> waiting for 3 seconds. Since the wait time is a fixed value, a lot of clients
> will retry at about the same time and a large portion of them get another
> failure. After 3 retries, there are about 256*4 = 1024 clients got the block.
> If the number of clients are more than that, the job will fail.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.