[
https://issues.apache.org/jira/browse/HDFS-2034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13057915#comment-13057915
]
Daryn Sharp commented on HDFS-2034:
-----------------------------------
I noticed that the last conditional of {{if (readLengthPastCompleteBlk &&
offset < getFileLength())}} dropped the RHS side. Presumably this is because
it's the condition in the early assert? Todd mentioned earlier that most
people run with asserts disabled, which means the method will return the wrong
data if asserts are off and the constraint is violated. I'd lean towards the
assert being an exception (not sure why we didn't discuss that option earlier),
but I'd be happy if the RHS condition was re-added. Todd can be the judge.
> length in getBlockRange becomes -ve when reading only from currently being
> written blk
> --------------------------------------------------------------------------------------
>
> Key: HDFS-2034
> URL: https://issues.apache.org/jira/browse/HDFS-2034
> Project: Hadoop HDFS
> Issue Type: Bug
> Reporter: John George
> Assignee: John George
> Priority: Minor
> Attachments: HDFS-2034-1.patch, HDFS-2034-1.patch, HDFS-2034-2.patch,
> HDFS-2034-3.patch, HDFS-2034-4.patch, HDFS-2034.patch
>
>
> This came up during HDFS-1907. Posting an example that Todd posted in
> HDFS-1907 that brought out this issue.
> {quote}
> Here's an example sequence to describe what I mean:
> 1. open file, write one and a half blocks
> 2. call hflush
> 3. another reader asks for the first byte of the second block
> {quote}
> In this case since offset is greater than the completed block length, the
> math in getBlockRange() of DFSInputStreamer.java will set "length" to
> negative.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
