[
https://issues.apache.org/jira/browse/HDFS-8?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steve Loughran resolved HDFS-8.
-------------------------------
Resolution: Cannot Reproduce
closing as so out of date it probably doesn't happen -and if it does, the stack
trace is obsolete
> Interrupting the namenode thread triggers System.exit()
> -------------------------------------------------------
>
> Key: HDFS-8
> URL: https://issues.apache.org/jira/browse/HDFS-8
> Project: Hadoop HDFS
> Issue Type: Bug
> 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 was sent by Atlassian JIRA
(v6.2#6252)
