[
https://issues.apache.org/jira/browse/HADOOP-5453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12681390#action_12681390
]
Konstantin Shvachko commented on HADOOP-5453:
---------------------------------------------
Steve, are you saying that {{FSEditsLog}} should throw something like
{{TerminalException}} instead of exiting the JVM and the {{main()}} in
{{NameNode}} or unit tests will catch it and exit (in case of {{main()}}) or
verify something in case of unit tests.
I think this would be reasonable.
But will require some fundamental changes. Particularly, this will mean that
{{NameNode.stop()}} will be called in the main method instead of the NameNode
constructor.
> 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.
