[
https://issues.apache.org/jira/browse/FLINK-5499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15851009#comment-15851009
]
ASF GitHub Bot commented on FLINK-5499:
---------------------------------------
Github user wangzhijiang999 commented on the issue:
https://github.com/apache/flink/pull/3125
@StephanEwen
Yes, the current concern is only focusing on state restore performance.
This PR does not consider all the scenarios and it may be only the first step
for the slot location implementation.
If the location do not exist, it can add other strategies to decide the
locations, such as co-loated by input for batch job as you mentioned. And it
can be the second step for the implementation.
Wish your further comments!
> Try to reuse the resource location of prior execution attempt in allocating
> slot
> --------------------------------------------------------------------------------
>
> Key: FLINK-5499
> URL: https://issues.apache.org/jira/browse/FLINK-5499
> Project: Flink
> Issue Type: Improvement
> Components: JobManager
> Reporter: Zhijiang Wang
> Assignee: Zhijiang Wang
>
> Currently when schedule execution to request to allocate slot from
> {{SlotPool}}, the {{TaskManagerLocation}} parameter is empty collection. So
> for task fail over scenario, the new execution attempt may be deployed to
> different task managers. If setting rockDB as state backend, the performance
> is better if the data can be restored from local machine. So we try to reuse
> the {{TaskManagerLocation}} of prior execution attempt when allocating slot
> from {{SlotPool}}. If the {{TaskManagerLocation}} is empty from prior
> executions, the behavior is the same with current status.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
