How would the ZK approach make things faster? Are you saying the AMs would
do the watching? Currently containers assignments aren't actually sent to
the NodeManagers on heartbeats. The first time a NM hears about a
container is when an AM launches it.
On Tue, Sep 24, 2013 at 4:12 AM, Harsh J
Yes, but the heartbeat coupling isn't necessary I think. One could
even use ZK write/watch approach for faster assignment of regular
work?
On Tue, Sep 24, 2013 at 2:24 PM, Steve Loughran wrote:
> On 21 September 2013 09:19, Sandy Ryza wrote:
>
>> I don't believe there is any reason scheduling de
On 21 September 2013 09:19, Sandy Ryza wrote:
> I don't believe there is any reason scheduling decisions need to be coupled
> with NodeManager heartbeats. It doesn't sidestep any race conditions
> because a NodeManager could die immediately after heartbeating.
>
>
historically its been done for
I don't believe there is any reason scheduling decisions need to be coupled
with NodeManager heartbeats. It doesn't sidestep any race conditions
because a NodeManager could die immediately after heartbeating.
On Sat, Sep 21, 2013 at 2:11 AM, Omkar Joshi wrote:
> Hi Wei,
>
> Yes there is a clea
Hi Wei,
Yes there is a clear lag between AM requesting resource and satisfying NM
heartbeats (thereby we process the event) are received. Developers in
project Tez ( http://incubator.apache.org/projects/tez.html ) have done
some similar stuff. You can check it there. I hope it helps.
Thanks,
Omka
Hey, Wei:
The nodeHeartBeat is used to let RM knows this NM is still alive. We
only assign containers from alive NM. Another thing is when scheduler
receives the nodeHeartBeat, the scheduler will get the container status
(such as completed, new launched) from NM, and it can use it to update t
Hi, all,
I have a simple question. Currently in YARN, the resource matching is triggered
by the node manager heartbeat. That is, assignContainers() is only invoked when
a new heartbeat comes in. Why we don't use resource request triggered
mechanism? That is, when AM submits allocateRequest, we
