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

dhruba borthakur commented on HADOOP-4532:
------------------------------------------

> ClosedByInterruptException get handled differently as some form of shutdown 
> request
  This is closest to what we currently have in the NameNode.

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

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

Reply via email to