[
https://issues.apache.org/jira/browse/HADOOP-5453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12681400#action_12681400
]
Steve Loughran commented on HADOOP-5453:
----------------------------------------
Yes, I think it should do that, but the current code has a feature in that it
is allowed to exit() from any thread, without having to report failure back
upstream. Throwing an exception isn't enough if you are in a worker thread, as
it needs to get handed to something that cares
We can postpone this until we have more of a lifcycle for the Namenode: until
it can fail on startup in a more structured manner, there's little to be gained
by not having FSEdit exit. Presumably that's why I'm encountering this problem
on my HADOOP-3628-branch
> Could FSEditLog report problems more elegantly than with System.exit(-1)
> ------------------------------------------------------------------------
>
> Key: HADOOP-5453
> URL: https://issues.apache.org/jira/browse/HADOOP-5453
> Project: Hadoop Core
> Issue Type: Improvement
> Components: dfs
> Affects Versions: 0.21.0
> Reporter: Steve Loughran
> Priority: Minor
>
> When FSEdit encounters problems, it prints something and then exits.
> It would be better for any in-JVM deployments of FSEdit for these to be
> raised in some other way (such as throwing an exception), rather than taking
> down the whole JVM. That could be in JUnit tests, or it could be inside other
> applications. Test runners and the like can intercept those System.exit()
> calls with their own Security Manager -often turning the System.exit()
> operation into an exception there and then. If FSEdit did that itself, it may
> be easier to stay in control.
> The current approach has some benefits -it can exit regardless of which
> thread has encountered problems, but it is tricky to test.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
