hadoop-yarn-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Junping Du (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (YARN-4602) Scalable and Simple Message Service for YARN application
Date Fri, 04 Mar 2016 10:02:40 GMT

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

Mime
View raw message