Mailing-List: contact yarn-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: yarn-issues@hadoop.apache.org
Date: Fri, 4 Mar 2016 10:02:40 +0000 (UTC)
From: "Junping Du (JIRA)" <jira@apache.org>
To: yarn-issues@hadoop.apache.org
Message-ID: <JIRA.12932181.1453132879000.4235.1457085760876@Atlassian.JIRA>
In-Reply-To: <JIRA.12932181.1453132879000@Atlassian.JIRA>
References: <JIRA.12932181.1453132879000@Atlassian.JIRA>
 <JIRA.12932181.1453132879766@arcas>
Subject: [jira] [Updated] (YARN-4602) Scalable and Simple Message Service
 for YARN application
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/YARN-4602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Junping Du updated YARN-4602:
-----------------------------
    Description: 
We are proposing to support MR AM restart with work preserving in MAPREDUCE-6608 (https://issues.apache.org/jira/browse/MAPREDUCE-6608) that when AM get failed for some reason, the inflight tasks will keep running/pending until new AM attempt comes back to continue. One of prerequisite is tasks should know where the new AM attempt get launched so TaskUmbilicalProtocol can get retry between clients and new server.
There could be the same requirement for other applications running on YARN too. Some application decide to handle message delivery itself, e.g. Long running services can leverage Slider agent to notify messages back and forth. However, vanilla applications on YARN is hard to achieve this because Hadoop RPC mechanism essentially is a single way of communication. Although two directions mechanism like heartbeats (between NM-RM or AM-RM) can get built on top of it, it make less sense to build the same mechanism between AM and its application containers - or it need to handle massive of client connections in AM which could be the new bottleneck for scalability and very complicated in state maintaining. Instead, we need a new message mechanism that is simple and scalable.


  was:
Currently, mostly communications among YARN daemons, services and applications are go through RPC. In almost all cases, logic running inside of containers are RPC client but not server because it get launched inflight. The only special case is AM container, because it get launched earlier than any other containers so it can be RPC server and tell new coming containers server address in application logic (like MR AM). 
The side effects are: 
1. When AM container get failed, the new AM attempts will get launched with new address/port, so previous RPC are broken.
2. Application's requirement are variable, there could be other dependency between containers (not AM), so some container failed over will affect other containers' running logic.
It is better to have some message/notification mechanism between containers for handle above cases.


> Scalable and Simple Message Service for YARN application
> --------------------------------------------------------
>
>                 Key: YARN-4602
>                 URL: https://issues.apache.org/jira/browse/YARN-4602
>             Project: Hadoop YARN
>          Issue Type: Sub-task
>          Components: applications, resourcemanager
>            Reporter: Junping Du
>            Assignee: Junping Du
>
> We are proposing to support MR AM restart with work preserving in MAPREDUCE-6608 (https://issues.apache.org/jira/browse/MAPREDUCE-6608) that when AM get failed for some reason, the inflight tasks will keep running/pending until new AM attempt comes back to continue. One of prerequisite is tasks should know where the new AM attempt get launched so TaskUmbilicalProtocol can get retry between clients and new server.
> There could be the same requirement for other applications running on YARN too. Some application decide to handle message delivery itself, e.g. Long running services can leverage Slider agent to notify messages back and forth. However, vanilla applications on YARN is hard to achieve this because Hadoop RPC mechanism essentially is a single way of communication. Although two directions mechanism like heartbeats (between NM-RM or AM-RM) can get built on top of it, it make less sense to build the same mechanism between AM and its application containers - or it need to handle massive of client connections in AM which could be the new bottleneck for scalability and very complicated in state maintaining. Instead, we need a new message mechanism that is simple and scalable.


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)