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-4532) Interrupting the namenode thread triggers System.exit()
Date Wed, 29 Oct 2008 10:55:44 GMT

    [ https://issues.apache.org/jira/browse/HADOOP-4532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12643463#action_12643463
] 

Steve Loughran commented on HADOOP-4532:
----------------------------------------

>> Hosting a Namenode in a security manager that blocks off System.exit()
>A Security Manager imposes additional performance overhead, doesn't it?

I've moved to the security manager hosting; it doesn't impose much of an overhead as only
permissions for System.exit() are checked and intercepted. 

It's still a bit odd killing the process if startup fails, however, as if you run <junit
fork="true"/> your process gets killed. In ant, <junit fork="false" /> runs under
a security manager purely to stop anyone calling System.exit() in their code.

> Interrupting the namenode thread triggers System.exit()
> -------------------------------------------------------
>
>                 Key: HADOOP-4532
>                 URL: https://issues.apache.org/jira/browse/HADOOP-4532
>             Project: Hadoop Core
>          Issue Type: Bug
>          Components: dfs
>    Affects Versions: 0.20.0
>            Reporter: Steve Loughran
>            Priority: Minor
>
> My service setup/teardown tests are managing to trigger system exits in the namenode,
which seems overkill.
> 1. Interrupting the thread that is starting the namesystem up raises a java.nio.channels.ClosedByInterruptException.
> 2. This is caught in FSImage.rollFSImage, and handed off to processIOError
> 3. This triggers a call to Runtime.getRuntime().exit(-1); "All storage directories are
inaccessible.".
> Stack trace to follow. Exiting the JVM is somewhat overkill; if someone has interrupted
the thread is is (presumably) because they want to stop the namenode, which may not imply
they want to kill the JVM at the same time. Certainly JUnit does not expect it. 
> Some possibilities
>  -ClosedByInterruptException get handled differently as some form of shutdown request
>  -Calls to system exit are factored out into something that can have its behaviour changed
by policy options to throw a RuntimeException instead. 
> Hosting a Namenode in a security manager that blocks off System.exit() is the simplest
workaround; this is fairly simple, but it means that what would be a straight exit does now
get turned into an exception, so callers may be surprised by what happens.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message