Mailing-List: contact hdfs-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: hdfs-issues@hadoop.apache.org
Date: Wed, 4 Nov 2015 16:14:27 +0000 (UTC)
From: "Bob Hansen (JIRA)" <jira@apache.org>
To: hdfs-issues@hadoop.apache.org
Message-ID: <JIRA.12896377.1443180842000.152078.1446653667853@Atlassian.JIRA>
In-Reply-To: <JIRA.12896377.1443180842000@Atlassian.JIRA>
References: <JIRA.12896377.1443180842000@Atlassian.JIRA>
 <JIRA.12896377.1443180842107@arcas>
Subject: [jira] [Commented] (HDFS-9144) Refactor libhdfs into
 stateful/ephemeral objects
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Bob Hansen commented on HDFS-9144:
----------------------------------

[~wheat9]: I re-named the "object that acts as a clean interface to the NameNode" as "NameNodeOperations," but I'm still not completely satisfied.  This object should own both the RPCEngine and the ClientNameNodeProtocol objects and provide a nice, higher-level interface to the underlying operations (see the GetBlockLocations implementation).  I considered just pushing the current protobuf-consuming methods into the private space of ClientNameNodeProtocol and adding clean public methods, but ClientNameNodeProtocol is generated code.  

If you can suggest a better refactoring, I would happily take feedback.

> Refactor libhdfs into stateful/ephemeral objects
> ------------------------------------------------
>
>                 Key: HDFS-9144
>                 URL: https://issues.apache.org/jira/browse/HDFS-9144
>             Project: Hadoop HDFS
>          Issue Type: Sub-task
>          Components: hdfs-client
>    Affects Versions: HDFS-8707
>            Reporter: Bob Hansen
>            Assignee: Bob Hansen
>         Attachments: HDFS-9144.HDFS-8707.001.patch, HDFS-9144.HDFS-8707.002.patch
>
>
> In discussion for other efforts, we decided that we should separate several concerns:
> * A posix-like FileSystem/FileHandle object (stream-based, positional reads)
> * An ephemeral ReadOperation object that holds the state for reads-in-progress, which consumes
> * An immutable FileInfo object which holds the block map and file size (and other metadata about the file that we assume will not change over the life of the file)


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