hadoop-yarn-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Karthik Kambatla (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (YARN-2883) Queuing of container requests in the NM
Date Fri, 01 Apr 2016 15:30:25 GMT

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

Karthik Kambatla edited comment on YARN-2883 at 4/1/16 3:29 PM:
----------------------------------------------------------------

Discussed this briefly with [~kkaranasos]. Our opinions appear to differ on the scope of {{ContainersMonitorImpl}}
- my opinion is this class should monitor only running containers and shouldn't be aware of
containers that are not running yet or play part in decision making of when containers should
start running. It appears [~kkaranasos] believes this class should also monitor when the non-running
containers should start running. 

IMO, expanding the scope of {{ContainersMonitorImpl}} makes the code hard to follow as we
have communication going both ways between {{ContainersMonitorImpl}} and {{ContainersManagerImpl}}.
Also, {{ContainersMonitorImpl}} will then have state that needs to be persisted for a work-preserving
NM restart. Would like to hear others' thoughts. [~chris.douglas], [~asuresh] - what do you
guys think? /cc [~jlowe]


was (Author: kasha):
Discussed this briefly with [~kkaranasos]. Our opinions appear to differ on the scope of {{ContainersMonitorImpl}}
- my opinion is this class should monitor only running containers and shouldn't be aware of
containers that have not running yet or play part in decision making of when containers should
start running. It appears [~kkaranasos] believes this class should also monitor when the non-running
containers should start running. 

IMO, expanding the scope of {{ContainersMonitorImpl}} makes the code hard to follow as we
have communication going both ways between {{ContainersMonitorImpl}} and {{ContainersManagerImpl}}.
Also, {{ContainersMonitorImpl}} will then have state that needs to be persisted for a work-preserving
NM restart. Would like to hear others' thoughts. [~chris.douglas], [~asuresh] - what do you
guys think? /cc [~jlowe]

> Queuing of container requests in the NM
> ---------------------------------------
>
>                 Key: YARN-2883
>                 URL: https://issues.apache.org/jira/browse/YARN-2883
>             Project: Hadoop YARN
>          Issue Type: Sub-task
>          Components: nodemanager, resourcemanager
>            Reporter: Konstantinos Karanasos
>            Assignee: Konstantinos Karanasos
>         Attachments: YARN-2883-trunk.004.patch, YARN-2883-trunk.005.patch, YARN-2883-trunk.006.patch,
YARN-2883-trunk.007.patch, YARN-2883-trunk.008.patch, YARN-2883-yarn-2877.001.patch, YARN-2883-yarn-2877.002.patch,
YARN-2883-yarn-2877.003.patch, YARN-2883-yarn-2877.004.patch
>
>
> We propose to add a queue in each NM, where queueable container requests can be held.
> Based on the available resources in the node and the containers in the queue, the NM
will decide when to allow the execution of a queued container.
> In order to ensure the instantaneous start of a guaranteed-start container, the NM may
decide to pre-empt/kill running queueable containers.



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

Mime
View raw message