[
https://issues.apache.org/jira/browse/HDFS-16155?focusedWorklogId=641633&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-641633
]
ASF GitHub Bot logged work on HDFS-16155:
-----------------------------------------
Author: ASF GitHub Bot
Created on: 25/Aug/21 11:55
Start Date: 25/Aug/21 11:55
Worklog Time Spent: 10m
Work Description: bbeaudreault commented on a change in pull request
#3271:
URL: https://github.com/apache/hadoop/pull/3271#discussion_r695678157
##########
File path:
hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/client/impl/TestFetchBlockLocationsRetryer.java
##########
@@ -0,0 +1,107 @@
+/**
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.hadoop.hdfs.client.impl;
+
+import static org.junit.Assert.assertEquals;
+import static org.junit.Assert.assertFalse;
+import static org.junit.Assert.assertTrue;
+
+import org.apache.hadoop.conf.Configuration;
+import org.apache.hadoop.hdfs.client.HdfsClientConfigKeys;
+import org.apache.hadoop.hdfs.client.HdfsClientConfigKeys.Retry;
+import
org.apache.hadoop.hdfs.client.impl.DfsClientConf.FetchBlockLocationsRetryer;
+import org.junit.Test;
+
+public class TestFetchBlockLocationsRetryer {
+
+ private static final double EPSILON = 0.001;
+
+ @Test
+ public void testIsMaxFailuresExceeded() {
+ Configuration conf = new Configuration();
+
+
conf.setInt(HdfsClientConfigKeys.DFS_CLIENT_MAX_BLOCK_ACQUIRE_FAILURES_KEY, 3);
+ FetchBlockLocationsRetryer retryer = new FetchBlockLocationsRetryer(conf);
+
+ assertFalse(retryer.isMaxFailuresExceeded(1));
+ assertTrue(retryer.isMaxFailuresExceeded(3));
+ assertTrue(retryer.isMaxFailuresExceeded(5));
+ }
+
+ @Test
+ public void testDefaultRetryPolicy() {
Review comment:
Per the comment in the original backoff policy:
> // Introducing a random factor to the wait time before another retry.
> // The wait time is dependent on # of failures and a random factor.
> // At the first time of getting a BlockMissingException, the wait
time
> // is a random number between 0..3000 ms. If the first retry
> // still fails, we will wait 3000 ms grace period before the 2nd
retry.
> // Also at the second retry, the waiting window is expanded to 6000
ms
> // alleviating the request rate from the server. Similarly the 3rd
retry
> // will wait 6000ms grace period before retry and the waiting window
is
> // expanded to 9000ms.
The first backoff should be between 0-3000ms. The second should be between
3000ms-9000ms (3000 + 6000). The third retry should be between 6000-15000ms
(6000 + 9000).
The random factor is applied to the 2nd part of that. So the second retry is
`3000 + rand() * 6000`, etc.
This test proves that this original retry strategy continues to work with
the new code. It's hard to test with randomness, so the random factor is
disabled. We're left with only the worst case scenario (if `rand()` returned
1). See the assertions below to see that the results adhere to the original
description above.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
Issue Time Tracking
-------------------
Worklog Id: (was: 641633)
Time Spent: 1h 50m (was: 1h 40m)
> Allow configurable exponential backoff in DFSInputStream refetchLocations
> -------------------------------------------------------------------------
>
> Key: HDFS-16155
> URL: https://issues.apache.org/jira/browse/HDFS-16155
> Project: Hadoop HDFS
> Issue Type: Improvement
> Components: dfsclient
> Reporter: Bryan Beaudreault
> Assignee: Bryan Beaudreault
> Priority: Minor
> Labels: pull-request-available
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> The retry policy in
> [DFSInputStream#refetchLocations|https://github.com/apache/hadoop/blob/trunk/hadoop-hdfs-project/hadoop-hdfs-client/src/main/java/org/apache/hadoop/hdfs/DFSInputStream.java#L1018-L1040]
> was first written many years ago. It allows configuration of the base time
> window, but subsequent retries double in an un-configurable way. This retry
> strategy makes sense in some clusters as it's very conservative and will
> avoid DDOSing the namenode in certain systemic failure modes – for example,
> if a file is being read by a large hadoop job and the underlying blocks are
> moved by the balancer. In this case, enough datanodes would be added to the
> deadNodes list and all hadoop tasks would simultaneously try to refetch the
> blocks. The 3s doubling with random factor helps break up that stampeding
> herd.
> However, not all cluster use-cases are created equal, so there are other
> cases where a more aggressive initial backoff is preferred. For example in a
> low-latency single reader scenario. In this case, if the balancer moves
> enough blocks, the reader hits this 3s backoff which is way too long for a
> low latency use-case.
> One could configure the the window very low (10ms), but then you can hit
> other systemic failure modes which would result in readers DDOSing the
> namenode again. For example, if blocks went missing due to truly dead
> datanodes. In this case, many readers might be refetching locations for
> different files with retry backoffs like 10ms, 20ms, 40ms, etc. It takes a
> while to backoff enough to avoid impacting the namenode with that strategy.
> I suggest adding a configurable multiplier to the backoff strategy so that
> operators can tune this as they see fit for their use-case. In the above low
> latency case, one could set the base very low (say 2ms) and the multiplier
> very high (say 50). This gives an aggressive first retry that very quickly
> backs off.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
