[
https://issues.apache.org/jira/browse/TEZ-708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13934228#comment-13934228
]
Siddharth Seth commented on TEZ-708:
------------------------------------
[~jeagles], [~bikassaha] I'm not fully convinced that we'll need to wait a
long time before a LocalTaskScheduler requires at least some amount of logic.
In any case, lets go with this approach for now and get simple LocalMode
running - and revisit if required when requirements change later for dual mode
operation.
One thing to look at is whether the LocalTaskScheduler will manage resources
(number of tasks available to be run locally etc) or the LocalCOntainerLauncher
- the TaskScheduler seems like a better place.
Assuming the scheduling will be a simple FIFO based on priorities ? I don't
think we have inversion of priorities (Reduce has a higher priority than Maps
in MR). As long as we use a scheduler which does not need this, a simple queue
should be sufficient.Otherwise pre-emption, if it is ever required, will likely
have to be implemented. It may be required in any case if local mode is to be
used for failure handling - but that's not the current goal.
> Avoid asking for new containers in uber-local mode
> --------------------------------------------------
>
> Key: TEZ-708
> URL: https://issues.apache.org/jira/browse/TEZ-708
> Project: Apache Tez
> Issue Type: Sub-task
> Reporter: Chen He
> Assignee: Jonathan Eagles
> Attachments: TEZ-708.patch
>
>
> Once we finish this task, the TaskSchedulerEventHandler should not ask for
> new container in the Uber-mode.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
