Mailing-List: contact hdfs-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: hdfs-issues@hadoop.apache.org
Date: Thu, 30 Jun 2011 16:25:28 +0000 (UTC)
From: "Daryn Sharp (JIRA)" <jira@apache.org>
To: hdfs-issues@hadoop.apache.org
Message-ID: 
 <589853117.5970.1309451128625.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <1321652620.68068.1307162687352.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (HDFS-2034) length in getBlockRange becomes -ve
 when reading only from currently being written blk
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ 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