[
https://issues.apache.org/jira/browse/FLINK-17295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17225985#comment-17225985
]
Stephan Ewen commented on FLINK-17295:
--------------------------------------
About reconciliation: The early designs were assuming that an Execution Graph
in recinciliation state waits for a certain period for TaskManagers to register
their tasks and execution attempts. Only then would the EG create new execution
attempts and IDs. So that should be fine with any ID, it just means that the
IDs in use can have been generated by various leader sessions.
About having an ID in the EG: Sounds at first like it would work. I would at
this point slightly lean towards just having a true random element, because
that was how it worked before and it was rock solid. All approaches with
shared/reused ID parts so far ended up having a surprising corner case that we
didn't foresee. So a UUID part sounds to me safest at this point.
What do you think?
> Refactor the ExecutionAttemptID to consist of ExecutionVertexID and
> attemptNumber
> ---------------------------------------------------------------------------------
>
> Key: FLINK-17295
> URL: https://issues.apache.org/jira/browse/FLINK-17295
> Project: Flink
> Issue Type: Sub-task
> Components: Runtime / Coordination
> Reporter: Yangze Guo
> Priority: Major
> Labels: pull-request-available
> Fix For: 1.12.0
>
>
> Make the ExecutionAttemptID being composed of (ExecutionVertexID,
> attemptNumber).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
