Akka 2.2 ClusterSingletonManager发送切换到[无]

我使用Akka 2.2 contrib的项目

ClusterSingletonManager

来保证集群中始终存在并且只有一种特定类型的参与者（主参与者）。然而，我观察到一种奇怪的行为（顺便说一句，这可能是意料之中的，但不明白为什么）。每当主机退出集群并稍后加入时，都会发生以下操作序列：

[INFO] [04/30/2013 17:47:35.805] [ClusterSystem-akka.actor.default-dispatcher-9] [akka://ClusterSystem/system/cluster/core/daemon] Cluster Node [akka.tcp://ClusterSystem@127.0.0.1:2551] - Welcome from [akka.tcp://ClusterSystem@127.0.0.1:2552]
[INFO] [04/30/2013 17:47:48.703] [ClusterSystem-akka.actor.default-dispatcher-8] [akka://ClusterSystem/user/singleton] Member removed [akka.tcp://ClusterSystem@127.0.0.1:52435]
[INFO] [04/30/2013 17:47:48.712] [ClusterSystem-akka.actor.default-dispatcher-2] [akka://ClusterSystem/user/singleton] ClusterSingletonManager state change [Start -> BecomingLeader]
[INFO] [04/30/2013 17:47:49.752] [ClusterSystem-akka.actor.default-dispatcher-9] [akka://ClusterSystem/user/singleton] Retry [1], sending HandOverToMe to [None]
[INFO] [04/30/2013 17:47:50.850] [ClusterSystem-akka.actor.default-dispatcher-21] [akka://ClusterSystem/user/singleton] Retry [2], sending HandOverToMe to [None]
[INFO] [04/30/2013 17:47:51.951] [ClusterSystem-akka.actor.default-dispatcher-20] [akka://ClusterSystem/user/singleton] Retry [3], sending HandOverToMe to [None]
[INFO] [04/30/2013 17:47:53.049] [ClusterSystem-akka.actor.default-dispatcher-3] 

...

[INFO] [04/30/2013 17:48:10.650] [ClusterSystem-akka.actor.default-dispatcher-21] [akka://ClusterSystem/user/singleton] Retry [20], sending HandOverToMe to [None]
[INFO] [04/30/2013 17:48:11.751] [ClusterSystem-akka.actor.default-dispatcher-4] [akka://ClusterSystem/user/singleton] Timeout in BecomingLeader. Previous leader unknown, removed and no TakeOver request.
[INFO] [04/30/2013 17:48:11.752] [ClusterSystem-akka.actor.default-dispatcher-4] [akka://ClusterSystem/user/singleton] Singleton manager [akka.tcp://ClusterSystem@127.0.0.1:2551] starting singleton actor
[INFO] [04/30/2013 17:48:11.754] [ClusterSystem-akka.actor.default-dispatcher-4] [akka://ClusterSystem/user/singleton] ClusterSingletonManager state change [BecomingLeader -> Leader]

---

为什么它试图向

[None]

发送

切换表？它需要大约20秒（20次重试）才能成为新的领导者，尽管在这种特定情况下，前一个领导者是众所周知的…
我不确定这是否能回答您的问题，但在查看
ClusterSingletonManager
的源代码时，您可以看到导致此场景的事件链。这个类使用Akka中的有限状态机逻辑，您看到的行为由于从
Start->BecomingLeader
的状态转换而停止。首先，查看
Start
状态：

when(Start) {
  case Event(StartLeaderChangedBuffer, _) ⇒
    leaderChangedBuffer = context.actorOf(Props[LeaderChangedBuffer].withDispatcher(context.props.dispatcher))
    getNextLeaderChanged()
    stay

  case Event(InitialLeaderState(leaderOption, memberCount), _) ⇒
    leaderChangedReceived = true
    if (leaderOption == selfAddressOption && memberCount == 1)
      // alone, leader immediately
      gotoLeader(None)
    else if (leaderOption == selfAddressOption)
      goto(BecomingLeader) using BecomingLeaderData(None)
    else
      goto(NonLeader) using NonLeaderData(leaderOption)
}

when(BecomingLeader) {
  ...
  case Event(HandOverRetry(count), BecomingLeaderData(previousLeaderOption)) ⇒
    if (count <= maxHandOverRetries) {
      logInfo("Retry [{}], sending HandOverToMe to [{}]", count, previousLeaderOption)
      previousLeaderOption foreach { peer(_) ! HandOverToMe }
      setTimer(HandOverRetryTimer, HandOverRetry(count + 1), retryInterval, repeat = false)
    } else if (previousLeaderOption forall removed.contains) {
      // can't send HandOverToMe, previousLeader unknown for new node (or restart)
      // previous leader might be down or removed, so no TakeOverFromMe message is received
      logInfo("Timeout in BecomingLeader. Previous leader unknown, removed and no TakeOver request.")
      gotoLeader(None)
    } else
        throw new ClusterSingletonManagerIsStuck(
        s"Becoming singleton leader was stuck because previous leader [${previousLeaderOption}] is unresponsive")
  }

这里要看的部分是：

    else if (leaderOption == selfAddressOption)
      goto(BecomingLeader) using BecomingLeaderData(None)

在我看来，这篇文章似乎是在说“如果我是领导者，改变开始成为领导者，没有作为之前的领导者选项”

然后，如果您查看
BecomingLeader
状态：

when(Start) {
  case Event(StartLeaderChangedBuffer, _) ⇒
    leaderChangedBuffer = context.actorOf(Props[LeaderChangedBuffer].withDispatcher(context.props.dispatcher))
    getNextLeaderChanged()
    stay

  case Event(InitialLeaderState(leaderOption, memberCount), _) ⇒
    leaderChangedReceived = true
    if (leaderOption == selfAddressOption && memberCount == 1)
      // alone, leader immediately
      gotoLeader(None)
    else if (leaderOption == selfAddressOption)
      goto(BecomingLeader) using BecomingLeaderData(None)
    else
      goto(NonLeader) using NonLeaderData(leaderOption)
}

when(BecomingLeader) {
  ...
  case Event(HandOverRetry(count), BecomingLeaderData(previousLeaderOption)) ⇒
    if (count <= maxHandOverRetries) {
      logInfo("Retry [{}], sending HandOverToMe to [{}]", count, previousLeaderOption)
      previousLeaderOption foreach { peer(_) ! HandOverToMe }
      setTimer(HandOverRetryTimer, HandOverRetry(count + 1), retryInterval, repeat = false)
    } else if (previousLeaderOption forall removed.contains) {
      // can't send HandOverToMe, previousLeader unknown for new node (or restart)
      // previous leader might be down or removed, so no TakeOverFromMe message is received
      logInfo("Timeout in BecomingLeader. Previous leader unknown, removed and no TakeOver request.")
      gotoLeader(None)
    } else
        throw new ClusterSingletonManagerIsStuck(
        s"Becoming singleton leader was stuck because previous leader [${previousLeaderOption}] is unresponsive")
  }

when（BecomingLeader）{
...
案例事件（切换重试（计数），BecomingLeaderData（previousLeaderOption））⇒
如果（计数，所以它看起来像一个bug：-）我也对这个很感兴趣。看起来像一个bug，但也太容易复制而成为一个疏忽？