[ 
https://issues.apache.org/jira/browse/HDFS-9144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bob Hansen updated HDFS-9144:
-----------------------------
    Attachment: HDFS-9144.HDFS-8707.002.patch

Carried refactoring through the DN operations:
* Merged with the libhdfs C-API work
* Removed Trait templates for OO classes
* Removed Stream templates for OO classes
* Removed Handler templates for explicit callback signatures
* Single-read usage now goes FileSystem -open-> FileHandle -pread-> ephemeral 
BlockReader
* Moved the ephemeral part of AsyncReadSome into the BlockReader, so the 
BlockReader now keeps all the state for a single read operation
* Per [~wheat9]'s request, added initial cancellation code
* Included comments on DN connection re-use

There is opportunity for further work (removing more stream and callback 
templates), but I think this stands as a good discrete unit of work.

I no longer classify as clean eyes, but my hope is that this is cleaner in 
terms of:
* Clear abstractions and concerns
* Clearer threading models and lifecycles for major objects
* Easier for new developers to engage and understand

Please review in terms of those qualities.

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

Reply via email to