hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Colin Patrick McCabe (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HDFS-3050) refactor OEV to share more code with the NameNode
Date Wed, 07 Mar 2012 22:48:57 GMT

    [ https://issues.apache.org/jira/browse/HDFS-3050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13224807#comment-13224807
] 

Colin Patrick McCabe commented on HDFS-3050:
--------------------------------------------

Hi Nicholas,

I took a look at implementing your suggestion today.  Basically, I found that:
* I had to implement a lot of accessors.  Eclipse made this easy, but it still ended up leading
to some very long code.
* All the Op classes needed to become public, because the {{oev}} stuff is in another module
* I have to either use instanceof, or add a visit() method to each OpCode (Visitor pattern)

This last point may need some explanation.  Basically, the edit log loader returns objects
of type {{FSEditLogOp}} to you.

If you call {{XmlEditsSerializer.toXml(contentHandler, op)}}, the method that Java will look
for is {{XmlEditsSerializer::toXml(ContentHandler contentHandler, FSEditLogOp op)}}.  It will
not invoke {{XmlEditsSerializer::toXml(ContentHandler contentHandler, FSEditLogOp.MkdirOp
op)}} (if the operation happens to be MkdirOp.)

There are two workaround for this:
1. code like this:

{code}
XmlEditsSerializer::toXml(ContentHandler contentHandler, FSEditLogOp.MkdirOp op) {
  if (instanceof(op, FSEditLogOp.MkdirOp))
    XmlEditsSerializer::toXml(contentHandler, (FSEditLogOp.MkdirOp)op);
  else if (instanceof(op, FSEditLogOp.ReassignLeaseOp))
    XmlEditsSerializer::toXml(contentHandler, (FSEditLogOp.ReassignLeaseOp)op);
    ...
}
{code}

2. adding a visit() method to every single FSEditLogOp, and using the visitor pattern.  The
FSEditLogOp classes will also have to implement an EditLogOpVisitor interface.  This will
end up being much more invasive than the original change, both in terms of lines of code,
efficiency, and clutter.

I feel kind of stuck right now, because I don't like either one of these options.  I feel
that they're both much worse than the original patch I posted.  Do you guys have any thoughts?
                
> refactor OEV to share more code with the NameNode
> -------------------------------------------------
>
>                 Key: HDFS-3050
>                 URL: https://issues.apache.org/jira/browse/HDFS-3050
>             Project: Hadoop HDFS
>          Issue Type: Improvement
>          Components: name-node
>            Reporter: Colin Patrick McCabe
>            Assignee: Colin Patrick McCabe
>            Priority: Minor
>         Attachments: HDFS-3050.patch2
>
>
> Current, OEV (the offline edits viewer) re-implements all of the opcode parsing logic
found in the NameNode.  This duplicated code creates a maintenance burden for us.
> OEV should be refactored to simply use the normal EditLog parsing code, rather than rolling
its own.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message