[
https://issues.apache.org/jira/browse/HDFS-6698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14194902#comment-14194902
]
Colin Patrick McCabe commented on HDFS-6698:
--------------------------------------------
Thanks, Lars. Sorry for the slowness of reviews on this-- I agree it's
important.
I guess when I was imagining doing this, I was thinking about adding a new
internal lock that protected {{DFSInputStream#locatedBlocks}} and some other
stuff that pread needed. Maybe I could be convinced that volatiles are the way
to go, but my default attitude towards volatile is skepticism... it's just so
easy to write incorrect code with volatile.
I wonder if we could combine this JIRA with HDFS-6735? It seems like the patch
there already incorporates this patch. And the issues (volatiles vs. second
lock) are the same.
> 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,
> HDFS-6698v2.txt, HDFS-6698v3.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.
> [[email protected]]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
