[
https://issues.apache.org/jira/browse/YARN-311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13807484#comment-13807484
]
Luke Lu commented on YARN-311:
------------------------------
I share the same concern with Bikas with the RMNode lock inside the static util
method. It doesn't appear to be necessary, as long as both
RMNodeImpl#totalCapacity and overCommitTimeout is volatile (the latter is not
in the patch), which are simply accessed via get/set (no dependent op like
increment). The lock could lead to deadlocks latter (after new code/refactor)
even if it appears to be fine now.
> Dynamic node resource configuration: core scheduler changes
> -----------------------------------------------------------
>
> Key: YARN-311
> URL: https://issues.apache.org/jira/browse/YARN-311
> Project: Hadoop YARN
> Issue Type: Sub-task
> Components: resourcemanager, scheduler
> Reporter: Junping Du
> Assignee: Junping Du
> Attachments: YARN-311-v10.patch, YARN-311-v1.patch,
> YARN-311-v2.patch, YARN-311-v3.patch, YARN-311-v4.patch, YARN-311-v4.patch,
> YARN-311-v5.patch, YARN-311-v6.1.patch, YARN-311-v6.2.patch,
> YARN-311-v6.patch, YARN-311-v7.patch, YARN-311-v8.patch, YARN-311-v9.patch
>
>
> As the first step, we go for resource change on RM side and expose admin APIs
> (admin protocol, CLI, REST and JMX API) later. In this jira, we will only
> contain changes in scheduler.
> The flow to update node's resource and awareness in resource scheduling is:
> 1. Resource update is through admin API to RM and take effect on RMNodeImpl.
> 2. When next NM heartbeat for updating status comes, the RMNode's resource
> change will be aware and the delta resource is added to schedulerNode's
> availableResource before actual scheduling happens.
> 3. Scheduler do resource allocation according to new availableResource in
> SchedulerNode.
> For more design details, please refer proposal and discussions in parent
> JIRA: YARN-291.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
