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