[
https://issues.apache.org/jira/browse/HDFS-9144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15022627#comment-15022627
]
James Clampffer commented on HDFS-9144:
---------------------------------------
"It's to ensure that the BlockReaderImpl's lifecycle is tied to the request,
and won't be freed until the final callback is complete in the read_handler. I
suppose it could be a unique_ptr, but I went with shared_ptr for consistency."
Cool, I think shared_ptr is fine. I wanted to make sure I wasn't missing
something.
Thanks for rebasing and the last round of fixes. +1 on the patch
At the moment my plan is to commit HDFS-9368, then HDFS-9359 (depends on
HDFS-9368 and needs reviewing), and then make sure everything is stable under
stress. Once everything seems solid we can add this. Those two patches
shouldn't require any further changes to your patch. Seem reasonable?
> 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, HDFS-9144.HDFS-8707.003.patch,
> HDFS-9144.HDFS-8707.004.patch, HDFS-9144.HDFS-8707.005.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)
