[
https://issues.apache.org/jira/browse/FLINK-8910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16424072#comment-16424072
]
ASF GitHub Bot commented on FLINK-8910:
---------------------------------------
Github user StefanRRichter commented on a diff in the pull request:
https://github.com/apache/flink/pull/5676#discussion_r178836145
--- Diff:
flink-core/src/main/java/org/apache/flink/api/common/TaskInfo.java ---
@@ -107,4 +131,12 @@ public int getAttemptNumber() {
public String getTaskNameWithSubtasks() {
return this.taskNameWithSubtasks;
}
+
+ /**
+ * Returns the allocation id for where this task is executed.
+ * @return the allocation id for where this task is executed.
+ */
+ public String getAllocationID() {
--- End diff --
What I find problematic about deleting the DFS files is that not all state
is (yet) covered by local recovery and it is also a lot harder to debug the
cause if there is an actual scheduling problem. With the current code, you can
easily see which allocation was lost. REST API might be an option if it is
somehow exposed there.
> Introduce automated end-to-end test for local recovery (including sticky
> scheduling)
> ------------------------------------------------------------------------------------
>
> Key: FLINK-8910
> URL: https://issues.apache.org/jira/browse/FLINK-8910
> Project: Flink
> Issue Type: Sub-task
> Components: State Backends, Checkpointing
> Affects Versions: 1.5.0
> Reporter: Stefan Richter
> Assignee: Stefan Richter
> Priority: Major
> Fix For: 1.5.0
>
>
> We should have an automated end-to-end test that can run nightly to check
> that sticky allocation and local recovery work as expected.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
