[
https://issues.apache.org/jira/browse/FLINK-2332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14636900#comment-14636900
]
ASF GitHub Bot commented on FLINK-2332:
---------------------------------------
Github user StephanEwen commented on the pull request:
https://github.com/apache/flink/pull/917#issuecomment-123720593
The mechanism looks good, all in all.
Some comments:
- I think it makes the code more understandable, if the
`decorateMessage()` method would be called something like `attachSession()`, or
so. Is the decoration used
- We have decided to gradually transition the runtime to Java, as this
mixture of languages is making it very clumsy in many parts. All other changes
followed the pattern to add new classes only in Java. Are there principle
reasons to not do this here as well? Especially by adding classes that are at
the core of this new mechanism (like `RequiresLeaderSessionID`) in Scala, we
effectively cement this language blend.
- In prior refactoring, we changed it such that JobManager, TaskManager,
etc do not use mixins any more. A big part of the decision were "clean logs"
and Java interoperability. This patch reverts this effort. Is there any
principle reason for that?
> Assign session IDs to JobManager and TaskManager messages
> ---------------------------------------------------------
>
> Key: FLINK-2332
> URL: https://issues.apache.org/jira/browse/FLINK-2332
> Project: Flink
> Issue Type: Sub-task
> Components: JobManager, TaskManager
> Reporter: Till Rohrmann
> Assignee: Till Rohrmann
> Fix For: 0.10
>
>
> In order to support true high availability {{TaskManager}} and {{JobManager}}
> have to be able to distinguish whether a message was sent from the leader or
> whether a message was sent from a former leader. Messages which come from a
> former leader have to be discarded in order to guarantee a consistent state.
> A way to do achieve this is to assign a leader session ID to a {{JobManager}}
> once he's elected as leader. This leader session ID is sent to the
> {{TaskManager}} upon registration at the {{JobManager}}. All subsequent
> messages should then be decorated with this leader session ID to mark them as
> valid. On the {{TaskManager}} side the received leader session ID as a
> response to the registration message, can then be used to validate incoming
> messages.
> The same holds true for registration messages which should have a
> registration session ID, too. That way, it is possible to distinguish invalid
> registration messages from valid ones. The registration session ID can be
> assigned once the TaskManager is notified about the new leader.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
