hadoop-yarn-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Loughran (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (YARN-3192) Empty handler for exception: java.lang.InterruptedException #WebAppProxy.java and #/ResourceManager.java
Date Fri, 13 Feb 2015 21:14:12 GMT

    [ https://issues.apache.org/jira/browse/YARN-3192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14320771#comment-14320771

Steve Loughran commented on YARN-3192:

Thank you. I believe I understand precisely why swallowing interrupted exceptions matter.
In fact, I will refer you to HADOOP-6221, which fixed it somewhere used across the codebase
(RPCClient) and included a test in the fix, so we can even replicate a problem which was stopping
me shutting down my client cleanly on a ^C signal, which is why [my app's entry point|https://github.com/apache/incubator-slider/blob/develop/slider-core/src/main/java/org/apache/slider/core/main/ServiceLauncher.java#L252]
starts an async shutdown timer as well as recognising a double ^C signal as a sign to escalate
to a JVM halt.

What I am saying is: this is not a place where it matters.

Look at the one place the {{join()}} method is called [WebAppProxyServer.main()|https://github.com/apache/hadoop/blob/trunk/hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-web-proxy/src/main/java/org/apache/hadoop/yarn/server/webproxy/WebAppProxyServer.java#L93]]

it's caught and translated, as Chris points out, into a "this is the shutdown you asked for",
which then exits with  a 0. 

 Signalling a clean shutdown is the desired action here, not exiting with a -1. Note also
our use of the sole exit mechanism we allow in the Hadoop codebase, via a call to {{ExitUtil.terminate(-1,
t);}}. That's new to branch-2+ as of this week; until then the code was "errant". 

if you're going to touch {{join()}}, rather than have it throw, have it exit with a boolean
to indicate "managed shutdown vs interruption". It'll be ignored either way, but if it makes
you confident the code is better, then I wont say known.

> Empty handler for exception: java.lang.InterruptedException #WebAppProxy.java and #/ResourceManager.java
> --------------------------------------------------------------------------------------------------------
>                 Key: YARN-3192
>                 URL: https://issues.apache.org/jira/browse/YARN-3192
>             Project: Hadoop YARN
>          Issue Type: Bug
>    Affects Versions: 2.6.0
>            Reporter: Brahma Reddy Battula
>            Assignee: Brahma Reddy Battula
>         Attachments: YARN-3192.patch
> The InterruptedException is completely ignored. As a result, any events causing this
interrupt will be lost.
>  File: org/apache/hadoop/yarn/server/resourcemanager/ResourceManager.java
> {code}
>    try {
>             event = eventQueue.take();
>           } catch (InterruptedException e) {
>             LOG.error("Returning, interrupted : " + e);
>             return; // TODO: Kill RM.
>           }
> {code}
> File: "org/apache/hadoop/yarn/server/webproxy/WebAppProxy.java"
> {code}
> public void join() {
>     if(proxyServer != null) {
>       try {
>         proxyServer.join();
>       } catch (InterruptedException e) {
>       }
>     }
>   }
> {code}

This message was sent by Atlassian JIRA

View raw message