[
https://issues.apache.org/jira/browse/TEZ-1039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14002602#comment-14002602
]
Bikas Saha commented on TEZ-1039:
---------------------------------
Its explained in the comments in the patch. This is a result of our container
matching loop. After the request is made, then the container its affinitized to
may be in the rack matching level. So it would be matched by
RACK_LEVEL_ASSIGNER. If we dont match it there it will go to * level and be
matched by NON_LOCAL_ASSIGNER. Then go back to NODE level and so on. Worst
case, it may be matched to some other rack local request instead of the
container affinity request. So even in the rack local assigner we need to
consider container-affinity or else we will get unnecessary delays or lose the
matching opportunity altogether.
> Add Container locality to TaskScheduler
> ---------------------------------------
>
> Key: TEZ-1039
> URL: https://issues.apache.org/jira/browse/TEZ-1039
> Project: Apache Tez
> Issue Type: Improvement
> Reporter: Bikas Saha
> Assignee: Bikas Saha
> Attachments: TEZ-1039.1.patch, TEZ-1039.2.patch
>
>
> Currently, the task scheduler support node and rack locality. Proposal is to
> add another level - container locality (given a container) which means first
> try to assign to the container, then fall back to the container's node, rack
> and so on.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
