试图了解当音量增加或所有接收演员忙于完成工作以及如何调整它以消除此类行为时，AKKA群集的哪个层正在向死人发送偶然消息。
这是基本拓扑：2个节点。 Node1由一组actor（让我们称之为发布actor）和akka群集感知路由器组成。发布actor将消息发布到路由器（RoundRobin），然后路由器将消息路由到Node2，Node2由工作者演员组成（以免称他们为订阅者演员）接收消息并做一些工作并回到发布路由器。
观察：在公布的消息和订阅者工作人员忙碌的高速率（非常高的akka，10K 10秒）中，我看到双方偶尔死亡（发布演员和订阅者演员回来）。后者的死亡率几乎是30-40％，但在分析并注意到线程饥饿并为集群配置单独的调度程序和为订户工作者配置PinnedDispatcher之后，我们能够将死后率降低到1-2％。值得注意的是，当使用带有for-join线程池的默认调度程序并且actor的数量高于线程数时，观察到高死亡率的后者;当数字演员少于线程数导致我们痉挛时，其他akka系统处理正在使用fork-join池。 Ram，GC和CPU看起来受到控制。它使用默认的无界邮箱，因此无法与缓冲区相关联。据我所知，akka doe鼻涕管理背压
当然，我们确实理解akka doe snot gurantee交付，我们必须实现我们自己的重试逻辑。这里的主要尝试是了解导致死后的原因：它是否发生在akka远程处理，netty传输层......，是否有一些可以调整和配置的超时实现。
我花了相当多的时间进行分析，添加额外的日志记录，捕获死后的日志和日志，但没有得到任何实际原因的线索。
非常感谢任何提示，尝试的事项或其他信息
以下是我们添加的配置：
cluster-dispatcher { type = "Dispatcher" executor = "fork-join-executor" fork-join-executor {
parallelism-min = 2
parallelism-max = 4 } }
#usde by worker worker-pinned-dispatcher { executor = "thread-pool-executor" type = PinnedDispatcher }