[ 
https://issues.apache.org/jira/browse/HDFS-17593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18091690#comment-18091690
 ] 

ASF GitHub Bot commented on HDFS-17593:
---------------------------------------

steveloughran commented on code in PR #8561:
URL: https://github.com/apache/hadoop/pull/8561#discussion_r3476329252


##########
hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/TestOpenFileWithLocatedBlocks.java:
##########
@@ -66,12 +63,13 @@ public class TestOpenFileWithLocatedBlocks {
   private static final EnumSet<CreateEncryptionZoneFlag> NO_TRASH =
       EnumSet.of(CreateEncryptionZoneFlag.NO_TRASH);
 
-  private MiniDFSCluster cluster;
-  private DistributedFileSystem fs;
-  private Configuration conf;
+  private static MiniDFSCluster cluster;
+  private static DistributedFileSystem fs;
+  private static Configuration conf;
+  private static Path ezPath;
 
-  @BeforeEach
-  public void setUp() throws IOException {
+  @BeforeAll
+  public static void setUp() throws Exception {

Review Comment:
   very minor, just call this "setupCluster" and "teardownCluster".
   
   setUp/tearDown have were the per method calls in junit1, and it's easy for 
people who have read too many tests to get mixed up.





> Allow setting block locations when opening streams
> --------------------------------------------------
>
>                 Key: HDFS-17593
>                 URL: https://issues.apache.org/jira/browse/HDFS-17593
>             Project: Hadoop HDFS
>          Issue Type: Improvement
>            Reporter: Csaba Ringhofer
>            Priority: Major
>              Labels: pull-request-available
>
> The HDFS client seems to always get block locations from the namenode when 
> opening a file:
> https://github.com/apache/hadoop/blob/4525c7e35ea22d7a6350b8af10eb8d2ff68376e7/hadoop-hdfs-project/hadoop-hdfs-client/src/main/java/org/apache/hadoop/hdfs/DFSClient.java#L1099
> This leads to unnecessary RPCs in Apache Impala when doing reads, as the 
> block locations are cached globally and the executors already have a good 
> guess about the block locations when opening a stream. Unless the cached 
> block locations are stale ideally no RPC should be made to the namenode.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to