Mailing-List: contact hdfs-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: hdfs-issues@hadoop.apache.org
Message-ID: <688557789.1249949354984.JavaMail.jira@brutus>
Date: Mon, 10 Aug 2009 17:09:14 -0700 (PDT)
From: "Todd Lipcon (JIRA)" <jira@apache.org>
To: hdfs-issues@hadoop.apache.org
Subject: [jira] Updated: (HDFS-513) NameNode.getBlockLocations throws NPE
 when offset > filesize and file is not empty
In-Reply-To: <118786470.1248911714812.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/HDFS-513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Todd Lipcon updated HDFS-513:
-----------------------------

    Status: Patch Available  (was: Open)

> NameNode.getBlockLocations throws NPE when offset > filesize and file is not empty
> ----------------------------------------------------------------------------------
>
>                 Key: HDFS-513
>                 URL: https://issues.apache.org/jira/browse/HDFS-513
>             Project: Hadoop HDFS
>          Issue Type: Bug
>          Components: name-node
>            Reporter: Todd Lipcon
>         Attachments: hdfs-513-trunk.txt, hdfs-513.txt
>
>
> in BlockManager.getBlockLocations, if the offset is past the end of a non-empty file, it returns null. In FSNamesystem.getBlockLocationsInternal, this null is passed through to inode.createLocatedBlocks, so it ends up with a LocatedBlocks instance whose .blocks is null. This is then iterated over in FSNamesystem.getBlockLocations, and throws an NPE.
> Instead, I think BlockManager.getBlockLocations should return Collections.emptyList in the past-EOF case. This would result in an empty list response from NN.getBlockLocations which matches the behavior of an empty file. If this sounds like the appropriate fix I"ll attach the patch.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.