0

我有一个关于 Behaviors.unhandled 的问题，我知道 Akka 将未处理的消息发送到死信，并且使用以下配置它也会记录它

akka {
 loglevel = "DEBUG"
 actor {
   debug {
    # enable DEBUG logging of unhandled messages
   unhandled = on
   }
  }
}

这在以下问题之前有争议Behaviours.unhandled并争论了 Akka 工作的典型方式，这是可以接受的，也应该只在 DEBUG 级别登录。

在这一点上，我的但来了，有限状态机是 Akka 的另一层，在有限状态机概念中，这种情况与未设计的处理转换有关，正如问题的原始海报所声称的那样，这是一个在迭代方法中非常重要的错误设计有限状态机。

对于 Akka FSM，典型的 FSM 配置将如下所示，

private val NEW: Behavior[Event] = {
  Behaviors.receive {
    case (ctx, onUserClicked(payload)) =>
      //doSomething()

    case _ => Behaviors.unhandled
  }
}

现在，如果令我们惊讶的是，如果用户设法在 NEW 状态期间生成 onUserDoubleClicked(payload) 事件，那么这是我们这边的设计错误。

问题是，我们大多数人不会在生产环境中以 DEBUG 级别运行我们的应用程序，如果我们在生产环境中遇到未处理的转换，我们将永远不会发现这一点并在下一次迭代中修复。

为了能够跟踪这一点，我们必须订阅 Dead Letters 根本不会传递给 FSM 概念......

出于这个原因，我认为即使这种情况对于普通 Akka 也是可以接受的，对于有限状态机概念，这种情况必须至少在 WARN 级别记录，或者必须提供配置选项来配置行为，或者您是否看到任何其他方式来实现这没有大量的代码混乱？

4

1 回答 1

0

我不确定这是否是您问题的最准确答案，但我会分享对我们有用的这个用例。

看看这个：https ://github.com/bilal-fazlani/fsm-with-akka-typed

我们尝试使用 akka typed 为 FSM 提取模式。此模式的关键是自定义接收函数，即myReceive。

这不仅允许我们自己在任何级别记录未处理的消息，而且还可以向发件人发送他们的消息未处理的回复。这种模式的另一个好处是——因为我们创建了单独的消息层次结构，例如ReadBehaviorMessageand WriteBehaviorMessage，我们现在被迫处理“特定状态”的所有消息；否则编译器会显示警告。

于 2020-01-14T18:05:40.100 回答