[ https://issues.apache.org/jira/browse/HDFS-6698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14091523#comment-14091523 ]
Hadoop QA commented on HDFS-6698: --------------------------------- {color:red}-1 overall{color}. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12660739/HDFS-6698v2.txt against trunk revision . {color:red}-1 patch{color}. The patch command could not apply the patch. Console output: https://builds.apache.org/job/PreCommit-HDFS-Build/7596//console This message is automatically generated. > try to optimize DFSInputStream.getFileLength() > ---------------------------------------------- > > Key: HDFS-6698 > URL: https://issues.apache.org/jira/browse/HDFS-6698 > Project: Hadoop HDFS > Issue Type: Sub-task > Components: hdfs-client > Affects Versions: 3.0.0 > Reporter: Liang Xie > Assignee: Liang Xie > Attachments: HDFS-6698.txt, HDFS-6698.txt, HDFS-6698v2.txt > > > HBase prefers to invoke read() serving scan request, and invoke pread() > serving get reqeust. Because pread() almost holds no lock. > Let's image there's a read() running, because the definition is: > {code} > public synchronized int read > {code} > so no other read() request could run concurrently, this is known, but pread() > also could not run... because: > {code} > public int read(long position, byte[] buffer, int offset, int length) > throws IOException { > // sanity checks > dfsClient.checkOpen(); > if (closed) { > throw new IOException("Stream closed"); > } > failures = 0; > long filelen = getFileLength(); > {code} > the getFileLength() also needs lock. so we need to figure out a no lock impl > for getFileLength() before HBase multi stream feature done. > [~saint....@gmail.com] -- This message was sent by Atlassian JIRA (v6.2#6252)