[
https://issues.apache.org/jira/browse/HDFS-3077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13472020#comment-13472020
]
Sanjay Radia commented on HDFS-3077:
------------------------------------
Comments so far:
* JournalNode States - I am a little confused about how the state of JN is
captured in the code.
** The "inWritingState" seems to be captured by (curSegment != null) - this is
used fairly often, lets hide this behind a method isJournalSegmentOpen(...)
** The journal state should be more concrete: Init, writing, recovering
(perhaps more than one recovering states)
* JournalNodes joining a pack
Can you please explain the following two cases
** a JournalNode (previously down) that is joining a set of other JNs
especially when the others are in writing mode.
** a new JournalNode join the pack.
* Exceptions
** journal operation (ie write)
shouldn't this thrown EpochException/FencedException" -- this exception is
critical so that client side does not retry the operation.
(perhaps this can be a EpochException which is turned into a
FencedException on client side.)
** Should there be some other more concrete exception that are subclasses of
IOException?
* AsyncLogger
JavaDoc states "This is essentially a wrapper around {@link QJournalProtocol}
with the key differences being ..."
Should this be "This is essentially a wrapper around {@link JournalManager }
with the key differences being ..."
* Javadoc
** QJM contructor - document at least the URI.
** Qprotocol - some methods do not have the parameters documented. Referring to
the doc is fine for method semantics in some cases.
** RequestInfo - document parameters
** Javadoc for class Journal:
A JournalNode can manage journals for several independent NN namespaces.
The Journal class implements a single journal i.e. the part that stores the
journal transactions persistently.
Each such journal (identified by a journal id) is entirely independent despite
being hosted by
a single journalNode daemon (ie the same JVM).
> Quorum-based protocol for reading and writing edit logs
> -------------------------------------------------------
>
> Key: HDFS-3077
> URL: https://issues.apache.org/jira/browse/HDFS-3077
> Project: Hadoop HDFS
> Issue Type: New Feature
> Components: ha, name-node
> Reporter: Todd Lipcon
> Assignee: Todd Lipcon
> Fix For: QuorumJournalManager (HDFS-3077)
>
> Attachments: hdfs-3077-partial.txt, hdfs-3077-test-merge.txt,
> hdfs-3077.txt, hdfs-3077.txt, hdfs-3077.txt, hdfs-3077.txt, hdfs-3077.txt,
> hdfs-3077.txt, hdfs-3077.txt, qjournal-design.pdf, qjournal-design.pdf,
> qjournal-design.pdf, qjournal-design.pdf, qjournal-design.pdf,
> qjournal-design.pdf, qjournal-design.tex, qjournal-design.tex
>
>
> Currently, one of the weak points of the HA design is that it relies on
> shared storage such as an NFS filer for the shared edit log. One alternative
> that has been proposed is to depend on BookKeeper, a ZooKeeper subproject
> which provides a highly available replicated edit log on commodity hardware.
> This JIRA is to implement another alternative, based on a quorum commit
> protocol, integrated more tightly in HDFS and with the requirements driven
> only by HDFS's needs rather than more generic use cases. More details to
> follow.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
