[
https://issues.apache.org/jira/browse/HADOOP-5453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12680845#action_12680845
]
Steve Loughran commented on HADOOP-5453:
----------------------------------------
I'm seeing this on startup, possibly the relevant output directories aren't
there; but a fatal exit isn't ideal for test runs as it makes it harder for me
to see what I've got wrong. If instead the FSEdit entered some failed state
(with some good text) then it could propagate to the NN, where it could be
remotely reported without having to go through the logs.
> 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.
