hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Loughran (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HADOOP-5453) Could FSEditLog report problems more elegantly than with System.exit(-1)
Date Thu, 12 Mar 2009 17:18:51 GMT

    [ 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.

View raw message