[
https://issues.apache.org/jira/browse/HDFS-513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12742055#action_12742055
]
Hadoop QA commented on HDFS-513:
--------------------------------
-1 overall. Here are the results of testing the latest attachment
http://issues.apache.org/jira/secure/attachment/12415046/hdfs-513-trunk.txt
against trunk revision 802972.
+1 @author. The patch does not contain any @author tags.
-1 tests included. The patch doesn't appear to include any new or modified
tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.
+1 javadoc. The javadoc tool did not generate any warning messages.
+1 javac. The applied patch does not increase the total number of javac
compiler warnings.
+1 findbugs. The patch does not introduce any new Findbugs warnings.
+1 release audit. The applied patch does not increase the total number of
release audit warnings.
-1 core tests. The patch failed core unit tests.
+1 contrib tests. The patch passed contrib unit tests.
Test results:
http://hudson.zones.apache.org/hudson/job/Hdfs-Patch-vesta.apache.org/58/testReport/
Findbugs warnings:
http://hudson.zones.apache.org/hudson/job/Hdfs-Patch-vesta.apache.org/58/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
Checkstyle results:
http://hudson.zones.apache.org/hudson/job/Hdfs-Patch-vesta.apache.org/58/artifact/trunk/build/test/checkstyle-errors.html
Console output:
http://hudson.zones.apache.org/hudson/job/Hdfs-Patch-vesta.apache.org/58/console
This message is automatically generated.
> 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.
