[
https://issues.apache.org/jira/browse/HDFS-2003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13043162#comment-13043162
]
Todd Lipcon commented on HDFS-2003:
-----------------------------------
A few comments on the patch itself:
- FSEditLogLoader.java line 174, length variable is unused.
- DelegationTokenIdentifier import in the same file is unused
- From the perspective of FSEditLogLoader, an EOFException while reading the
opcode (expected) is treated the same as an EOFException in the middle of
reading one of the ops (unexpected). This seems unintentional, since a
truncated log file is not normal, right?
- I'm thinking it might be slightly cleaner to make a new class like
FSEditLogReader, which is instantiated with an InputStream and logVersion. It
would then expose just a readOp() method. I think that will make it easier to
mock up sources of edits in the future. What do you think?
- Style nit: camelCase (eg "addCloseOp") is preferred for things like the
variable "addcloseop". Another option which might make the code a little neater
is to name the outer op (which hasn't been downcasted yet) something like
"genericOp", and then use "op" for all of the downcasted ones.
Perhaps more to come - got to run and catch a train :)
> Separate FSEditLog reading logic from editLog memory state building logic
> -------------------------------------------------------------------------
>
> Key: HDFS-2003
> URL: https://issues.apache.org/jira/browse/HDFS-2003
> Project: Hadoop HDFS
> Issue Type: Improvement
> Affects Versions: Edit log branch (HDFS-1073)
> Reporter: Ivan Kelly
> Assignee: Ivan Kelly
> Fix For: Edit log branch (HDFS-1073)
>
> Attachments: HDFS-2003.diff, HDFS-2003.diff
>
>
> Currently FSEditLogLoader has code for reading from an InputStream
> interleaved with code which updates the FSNameSystem and FSDirectory. This
> makes it difficult to read an edit log without having a whole load of other
> object initialised, which is problematic if you want to do things like count
> how many transactions are in a file etc.
> This patch separates the reading of the stream and the building of the memory
> state.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
