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