[
https://issues.apache.org/jira/browse/HDFS-3605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13410083#comment-13410083
]
Uma Maheswara Rao G commented on HDFS-3605:
-------------------------------------------
{quote}
The design of the code should be such that, it will re-process those "future"
events, but they'll get re-postponed at that point
{quote}
This is what I mean, if i understand you intent correctly here. leave the
future genstamps here for processing. Once all the OP codes read and processed
anyway it is processing all quequed messages again if anything left I remeber.
So, this should help us in this case.
{quote}
Maybe the issue is specifically in the case where these opcodes get read during
the "catchup" during transition to active?
{quote}
What issue you are pointing here. Edits are getting read in correct order only
right?
> Missing Block in following scenario
> -----------------------------------
>
> Key: HDFS-3605
> URL: https://issues.apache.org/jira/browse/HDFS-3605
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: name-node
> Affects Versions: 2.0.0-alpha, 2.0.1-alpha
> Reporter: Brahma Reddy Battula
> Assignee: Todd Lipcon
> Attachments: TestAppendBlockMiss.java
>
>
> Open file for append
> Write data and sync.
> After next log roll and editlog tailing in standbyNN close the append stream.
> Call append multiple times on the same file, before next editlog roll.
> Now abruptly kill the current active namenode.
> Here block is missed..
> this may be because of All latest blocks were queued in StandBy Namenode.
> During failover, first OP_CLOSE was processing the pending queue and adding
> the block to corrupted block.
--
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
