Akka中的错误内核和监督：来自陈旧儿童的消息会被传递给重启的演员吗？

Question

如果一个行动者携带非常重要的数据（即如果可以避免，其状态不应丢失），该行动者应将任何可能危险的子任务提供给它所监督的儿童，并酌情处理这些儿童的失败。根据请求的性质，最好为每个请求创建一个新的子请求，这样可以简化收集答复的状态管理。这被称为Erlang的“错误内核模式”。

...创建子级并将容易出错的工作委托给它们是一个好主意，将重要的状态集中在父级/主管角色中。

在这个场景中，如果具有重要状态的actor由于某种原因重新启动，我是否需要处理来自它的陈旧子级（在重新启动之前创建的）的消息？

C在B的构造函数中创建。

然后假设消息BC从B发送到C。C开始处理它（让我们想象一下它在那里运行长时间运行的计算），一旦完成，将用CB回复B。

现在，假设在将CB发送到B并由B处理之前，A将消息AB发送到B。此消息导致b抛出异常，并且作为a监督策略决策的结果，b将重新启动。

重新启动的b会从c接收在b重新启动之前发送的cb吗？

如果是，那么CB(C)的发件人是否被视为重新启动B的子级？C和C'的actor ref是否相等（假设C和C'的名称相等）？

Answer 1

是的，重新启动的B将从第一个C收到响应。如果C正在执行长时间运行的工作，而其父级失败，则在C完成长时间运行的工作之前，B实际上不会重新启动。作为重新启动b的一部分，将停止（不是重新启动）原始的c，并创建一个新的c（您称之为c')，它是重新启动的b的子级。但是，第一个C将不是重新启动的B的子级。

当第一个C完成时，其发件人引用仍然有效，即使该响应即将重新启动，该响应仍然可以传递到该refs邮箱。当重新启动b时，它能够保留重新启动前邮箱中的内容，从而在启动备份后立即接收并处理cb消息。

我起草了一个小代码示例来展示这种行为：

import akka.actor._
import concurrent.duration._

object RestartExample extends App{
  case object Start
  case object AB
  case object BC
  case object CB

  val system = ActorSystem("test")
  val a = system.actorOf(Props[A])
  a ! Start

  class A extends Actor{
    val b = context.actorOf(Props[B], "myb")
    import context.dispatcher

    def receive = {
      case Start =>
        b ! Start
        context.system.scheduler.scheduleOnce(3 seconds, b, AB)
    }
  }

  class B extends Actor{
    println("new B actor instance created")
    val c = context.actorOf(Props[C], "myc")
    def receive = {
      case Start =>
        c ! BC
      case CB =>
        println("got a CB from C")
      case AB =>
        throw new RuntimeException("foo")
    }
  } 

  class C extends Actor{
    println("new C actor instance created")
    def receive = {
      case BC =>
        Thread.sleep(10000) // simulating long running behavior
        println("done with long processing...")
        sender ! CB
    }
  } 
}