[
https://issues.apache.org/jira/browse/FLINK-2332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14636964#comment-14636964
]
ASF GitHub Bot commented on FLINK-2332:
---------------------------------------
Github user StephanEwen commented on a diff in the pull request:
https://github.com/apache/flink/pull/917#discussion_r35216181
--- Diff:
flink-runtime/src/main/scala/org/apache/flink/runtime/FlinkActor.scala ---
@@ -19,34 +19,30 @@
package org.apache.flink.runtime
import _root_.akka.actor.Actor
-
-/**
- * Mixin to add debug message logging
- */
-trait ActorLogMessages {
- that: Actor with ActorSynchronousLogging =>
-
- override def receive: Receive = new Actor.Receive {
- private val _receiveWithLogMessages = receiveWithLogMessages
-
- override def isDefinedAt(x: Any): Boolean =
_receiveWithLogMessages.isDefinedAt(x)
-
- override def apply(x: Any): Unit = {
- if (!log.isDebugEnabled) {
- _receiveWithLogMessages(x)
- }
- else {
- log.debug(s"Received message $x at ${that.self.path} from
${that.sender()}.")
-
- val start = System.nanoTime()
-
- _receiveWithLogMessages(x)
-
- val duration = (System.nanoTime() - start) / 1000000
- log.debug(s"Handled message $x in $duration ms from
${that.sender()}.")
- }
- }
+import grizzled.slf4j.Logger
+
+/** Base trait for Flink's actors.
+ *
+ * The message handling logic is defined in the handleMessage method.
This allows to mixin
+ * stackable traits which change the message receiving behaviour.
+ */
+trait FlinkActor extends Actor {
+ lazy val log = Logger(getClass)
--- End diff --
I think abstract variables just give us function calls instead. Can it be a
regular variable?
When is the `getClass()` method here actually called?
> 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)