[jira] [Commented] (HDFS-9144) Refactor libhdfs into stateful/ephemeral objects

["Bob Hansen (JIRA)" <ji...@apache.org>]

    [ 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)