[
https://issues.apache.org/jira/browse/HDFS-5762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13871416#comment-13871416
]
Andrew Wang commented on HDFS-5762:
-----------------------------------
Nice find. I'm a little annoyed that our read method doesn't follow POSIX
(which says 0 length reads should return 0, not -1), but that ship has long
since sailed. It's good to have a test that verifies this behavior.
Some review comments:
* WATERMELON print in the test
* In readWithoutBounceBuffer(ByteBuffer), instead of breaking on a 0-length
read (which is valid for FileChannel), can we instead check for EOF and return
before that?
{code}
if (nRead <= 0) break;
{code}
* I think this could be clearer as:
{code}
if (nRead <= 0) {
if (dataPos == dataIn.size()) {
return -1;
}
} else if (nRead > 0) {
dataPos += nRead;
}
return nRead;
{code}
{code}
if (nRead > 0) {
dataPos += nRead;
}
if (nRead == 0 && dataPos == dataIn.size()) {
return -1;
}
return nRead;
{code}
* Sprinkling some comments around the changes in BRL would be appreciated
These are all stylistic comments, so +1 once addressed.
> BlockReaderLocal doesn't return -1 on EOF when doing zero-length reads
> ----------------------------------------------------------------------
>
> Key: HDFS-5762
> URL: https://issues.apache.org/jira/browse/HDFS-5762
> Project: Hadoop HDFS
> Issue Type: Bug
> Affects Versions: 2.4.0
> Reporter: Colin Patrick McCabe
> Assignee: Colin Patrick McCabe
> Attachments: HDFS-5762.001.patch
>
>
> Unlike the other block readers, BlockReaderLocal currently doesn't return -1
> on EOF when doing zero-length reads. This behavior, in turn, propagates to
> the DFSInputStream. BlockReaderLocal should do this, so that client can
> determine whether the file is at an end by doing a zero-length read and
> checking for -1.
> One place this shows up is in libhdfs, which does such a 0-length read to
> determine if direct (i.e., ByteBuffer) reads are supported.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
