[
https://issues.apache.org/jira/browse/HDFS-1926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13032914#comment-13032914
]
Ivan Kelly commented on HDFS-1926:
----------------------------------
I've uploaded the correct patch.
The reason I see for NNStorageListener is that if a directory fails you don't
want to keep trying it. This may not be a problem though. It certainly would be
nice to get rid of NNStorageListener. Without it, if a StorageDirectory fails
(disk failure etc) during a image save, then FSEditLog wouldn't know anything
about it until the next time it went to write an entry, at which point the
write would fail and the stream would be removed from rotation. I guess the
only problem here would be if write didn't fail immediately, but blocked
indefinitely (if the StorageDirectory pointed to a hard mounted NFS share for
example).
I'll try getting rid of it completely from the edit log side of things, run the
tests and see how it goes.
> 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.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
