[
https://issues.apache.org/jira/browse/HDFS-2990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13215302#comment-13215302
]
Colin Patrick McCabe commented on HDFS-2990:
--------------------------------------------
Hi Nicholas,
I took a quick look at your suggestion. Here are the files I view as
format-specific in the namenode package:
{code}
BackupImage.java
BackupJournalManager.java
EditLogBackupInputStream.java
EditLogBackupOutputStream.java
EditLogFileInputStream.java
EditLogFileOutputStream.java
EditLogInputStream.java
EditLogOutputStream.java
EditsDoubleBuffer.java
FSDirectory.java
FSEditLog.java
FSEditLogLoader.java
FSEditLogOpCodes.java
FSEditLogOp.java
FSImageCompression.java
FSImageFormat.java
FSImage.java
FSImagePreTransactionalStorageInspector.java
FSImageSerialization.java
FSImageStorageInspector.java
FSImageTransactionalStorageInspector.java
JournalManager.java
JournalSet.java
JournalStream.java
NNStorage.java
NNStorageRetentionManager.java
{code}
After moving all of those into a separate namespace,
org.apache.hadoop.hdfs.server.namenode.format, I found that I had to make a lot
of interfaces public that I didn't really want to. This isn't really suprising
because these files represent nearly 1/3 of the total files in
org.apache.hadoop.hdfs.server.namenode.
My conclusion is that this is probably not the best way forward.
Assuming that we don't accept the patch I posted above, it looks like making
things public and using interface annotations are the way forward for sharing
more code between OEV / OIV and the NameNode.
cheers,
Colin
> Move OfflineImageViewer, OfflineEditsViewer into the same package as the
> NameNode
> ---------------------------------------------------------------------------------
>
> Key: HDFS-2990
> URL: https://issues.apache.org/jira/browse/HDFS-2990
> Project: Hadoop HDFS
> Issue Type: Bug
> Reporter: Colin Patrick McCabe
> Assignee: Colin Patrick McCabe
> Attachments: HDFS-2990.patch
>
>
> Since OfflineImageviewer and OfflineEditsVeiwer are in different namespaces
> than the NameNode, we can't ruuse a lot of the code from the NameNode without
> making things public that we probably don't want to make public. Let's move
> them into the NameNode namespace to avoid this problem. These tools will
> always be tightly tied to the NameNode anyway (they are parsing the same
> on-disk structures, after all), so that is where they belong.
--
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
