Mailing-List: contact hdfs-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Date: Mon, 28 Nov 2016 21:13:58 +0000 (UTC)
From: "Mingliang Liu (JIRA)" <jira@apache.org>
To: hdfs-issues@hadoop.apache.org
Message-ID: <JIRA.13021744.1479473973000.381863.1480367638456@Atlassian.JIRA>
In-Reply-To: <JIRA.13021744.1479473973000@Atlassian.JIRA>
References: <JIRA.13021744.1479473973000@Atlassian.JIRA> <JIRA.13021744.1479473973246@arcas>
Subject: [jira] [Commented] (HDFS-11156) Webhdfs rest api
 GET_BLOCK_LOCATIONS output doesn't comply with FileSystem API
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Mon, 28 Nov 2016 21:14:00 -0000


    [ https://issues.apache.org/jira/browse/HDFS-11156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15703132#comment-15703132 ] 

Mingliang Liu commented on HDFS-11156:
--------------------------------------

The patch looks good to me overall. +1

I have several minor comments:

# Do we need to specially handle the case of {{list.isEmpty()}}? Looks pretty similar to the {{else}} clause.
{code}
593	    } else if (list.isEmpty()) {
594	      return new String[0];
595	    } else {
596	      final String[] array = new String[list.size()];
597	      int i = 0;
598	      for (Object object : list) {
599	        array[i++] = object.toString();
600	      }
601	      return array;
602	    }
{code}
# Are you considering using {{assertArrayEquals()}}?
{code:title=testWebHdfsGetBlockLocationsWithStorageType()}
899	        for(int j=0; j<raw.getStorageTypes().length; j++) {
900	          Assert.assertEquals(
901	              raw.getStorageTypes()[j],
902	              rest.getStorageTypes()[j]);
903	        }
{code}
# This helper method can be static, and the intermediate variable {{response}} definition can be joined with the return statement {{return IOUtils.toString(conn.getInputStream());}}.
{code:title=testWebHdfsGetBlockLocationsWithStorageType()}
912	  private String getResponse(URL url, String httpRequestType)
913	      throws IOException {
914	    HttpURLConnection conn = (HttpURLConnection) url.openConnection();
915	    conn.setRequestMethod(httpRequestType);
916	    conn.setInstanceFollowRedirects(false);
917	    String response = IOUtils.toString(conn.getInputStream());
918	    return response;
919	  }
{code}

> Webhdfs rest api GET_BLOCK_LOCATIONS output doesn't comply with FileSystem API
> ------------------------------------------------------------------------------
>
>                 Key: HDFS-11156
>                 URL: https://issues.apache.org/jira/browse/HDFS-11156
>             Project: Hadoop HDFS
>          Issue Type: Bug
>          Components: webhdfs
>    Affects Versions: 2.7.3
>            Reporter: Weiwei Yang
>            Assignee: Weiwei Yang
>         Attachments: HDFS-11156.01.patch, HDFS-11156.02.patch, HDFS-11156.03.patch
>
>
> Following webhdfs REST API
> {code}
> http://<HOST>:<PORT>/webhdfs/v1/<PATH>?op=GET_BLOCK_LOCATIONS&offset=0&length=1
> {code}
> will get a response like
> {code}
> {
>   "LocatedBlocks" : {
>     "fileLength" : 1073741824,
>     "isLastBlockComplete" : true,
>     "isUnderConstruction" : false,
>     "lastLocatedBlock" : { ... },
>     "locatedBlocks" : [ {...} ]
>   }
> }
> {code}
> This represents for *o.a.h.h.p.LocatedBlocks*. However according to *FileSystem* API, 
> {code}
> public BlockLocation[] getFileBlockLocations(Path p, long start, long len)
> {code}
> clients would expect an array of BlockLocation. This mismatch should be fixed. Marked as Incompatible change as this will change the output of the GET_BLOCK_LOCATIONS API.


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: hdfs-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: hdfs-issues-help@hadoop.apache.org