[
https://issues.apache.org/jira/browse/FLINK-2332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14636970#comment-14636970
]
ASF GitHub Bot commented on FLINK-2332:
---------------------------------------
Github user tillrohrmann commented on the pull request:
https://github.com/apache/flink/pull/917#issuecomment-123737269
* I chose to call the method `decorateMessage` because it not necessarily
only attaches leader session IDs. In the future we might use this method for
something other than just wrapping the messages in a `LeaderSessionMessage`.
Moreover, calling it `attachSession` would contradict the idea of transparency
here. But we can change it as long as we don't have to do any other decorations.
* The trait `RequiresLeaderSessionID` is only a marker trait which does not
contain any code. Thus, it is effectively equivalent to a Java interface and
in fact Java classes can implement it. The only reason I chose a trait instead
of an interface is that all messages which are sent by the actors are
implemented as Scala classes. I can change it to be an interface, however I
don't think that it cements the language blend.
* I agree that it's not necessary to use mixins here. The reason to
implement the logging and leader session message decoration as a mixin was just
the beauty of the implementation. But I forgot about the clumsy names in the
log output. I will include the mixins in the class `FlinkActor`.
* It is true that the leader session ID can change in the case of HA with
ZooKeeper. However, the ZooKeeper HA is not part of this PR.
> 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)
