Akka演员和调度员

下面的例子是调度消息时的经典反模式吗？Akka演员和调度员

class MyActor extends Actor { 

    private val scheduler = context.system.scheduler.schedule(3.seconds, 3.seconds, self, Tick) 

    def receive = { 
    case Tick => processMessage(....) 
    } 
}

为什么我应该远离使用本地调度程序？

来源

2016-05-18 sparkr

我已经看到的一个问题是测试这个Actor变得困难。假设这位演员内部有相当多的逻辑，那么我注定了，但除此之外，这被认为是反模式？你们有什么感想？ – sparkr

我会尽量总结为什么你不应该使用调度器作为默认模式。

如果您提交的任务数量多于您处理的任务数量，那么您的JVM可能会耗尽内存或者您的任务可能会延迟。
演员调度不是持久的，所以如果例如在17:50你安排了一个Tick消息在10分钟内发送，但由于一些例外，你的演员被监督员17:53重新启动，作为默认监督的一部分政策，结果你的计划任务将被延迟3分钟......为了解决这个问题，你可以使用持续的演员，它将重播所有的计划事件，并重新安排它，如果事件时间更长，那么当前时间你的计划周期将是三角洲那两个时间戳。
基于HashedWheeltimer阿卡调度哪些是最适合安排短期

在我们的项目中，我们使用的是我们从“要求演员”发送消息给其他演员“演员每请求”模式，然后是设置context.setReceiveTimeout(x seconds)。如果我们没有收到任何x秒响应，我们认为这个信息已经丢失，并根据我们使用“至少一次”或“最多一次”交付的模式来应用我们的逻辑。

来源

2016-05-21 20:56:47

Akka演员和调度员

回答

相关问题