[
https://issues.apache.org/jira/browse/HDFS-1926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13035839#comment-13035839
]
Sanjay Radia commented on HDFS-1926:
------------------------------------
Todd, your comments on decoupling makes sense: in this new world image and
edits are not coupled.
Now even in the old world, the listener is messy way to propagate the error;
one is better off having the storage object record that it had an error in the
past and report an error to all future writes (be for writing edits or
images). So I dislike the listener notion.
In the new world, we don't need the coupling but we could make the error a
storage object property - the storage could decide to report errors on all
future writes if one write error has occurred in the past. This deals with the
issue of both edits writer and image writer timing out separately to detect an
error on the storage device.
> Remove references to StorageDirectory from JournalManager interface
> -------------------------------------------------------------------
>
> Key: HDFS-1926
> URL: https://issues.apache.org/jira/browse/HDFS-1926
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Reporter: Ivan Kelly
> Assignee: Ivan Kelly
> Attachments: HDFS-1926-nolistener.diff, HDFS-1926.diff, HDFS-1926.diff
>
>
> The JournalManager interface introduced by HDFS-1799 has a
> getStorageDirectory method which is out of place in a generic interface. This
> JIRA removed that call by refactoring the error handling for FSEditLog. Each
> EditLogFileOutputStream is now a NNStorageListener and listens for error on
> it's containing StorageDirectory. If an error occurs from FSImage, the stream
> will be aborted. If the error occurs in FSEditLog, the stream will be aborted
> and NNStorage will be notified that the StorageDirectory is no longer valid.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
