【问题标题】:Akka Ask & FuturesAkka 询问和期货
【发布时间】:2015-07-07 14:26:55
【问题描述】:

我是一个阿卡菜鸟,所以很抱歉!

我正在使用一个使用 Spray 和 Akka 的系统。 我正在使用以下代码 sn-p 向另一个参与者发送消息。 它使用 ask which,据我了解,它将返回在“mapTo”和“map”中解决的未来。然后我使用 Sprays “完成”指令将结果返回给用户。

val response = (worker ? Create(json))
            .mapTo[Ok]
            .map(result => s"I got a response: ${result}")
            .recover { case _ => "error" }

complete(response)

我的问题是,既然这是未来,我是否需要担心向客户发送正确的响应?在一些代码示例中,我看到了作为请求的一部分发送要回复的 actorRef 的示例......

// set reply to actor
val replyTo = sender() // important to not close over sender()

// create actor that collects replies from workers
val aggregator = context.actorOf(Props(
    classOf[StatsAggregator], words.size, replyTo))

然后在接收actor中...

replyTo ! SendResult

我应该将“replyTo”actor 作为请求的一部分传递,还是在 mapTo 中处理这一切?

提前致谢!

【问题讨论】:

  • replyTo 成语仅在您在未来的回调中发送消息时才重要。
  • 嗨瑞恩,感谢您的回复。你能详细说明一下吗? Complete 如何知道何时运行并确保它使用正确的消息回复正确的客户端?挡住了吗???此外,在接收演员中,它反过来将工作委托给子演员。然后我是否必须使用“replyTo”习语,还是可以再次使用与上述相同的模式 (mapTo) 来控制返回的响应?

标签: akka spray


【解决方案1】:

complete 指令将向您服务的 http/https 客户端发送回响应。你不需要做更多的事情。请注意,您的代码通过在未来创建 recover 来吞下错误。 Spray 会将其视为成功并返回状态码200

最后也是最重要的,你的工人必须像这样回复Ok 消息。

class Worker extends Actor {
    def receive: Receive = {
        case Create(json) => 
        //do some staff with json
        sender() ! Ok // This Ok message will be passed in the future in spray route
    }
}

只有当worker在内部使用Future来处理工作负载时才需要replyTo。如下例所示

class Worker extends Actor {
    def recieve: Recieve = {
        case Create(json) => 
            val future = Future{
                //do some staff with json
            }

            val replyTo = sender()

            future.onComplete {
                case scala.util.Success(result) => 
                    replyTo ! Ok
                case scala.util.Failure(ex) => 
                    replyTo ! akka.actor.Status.Failure(ex)    
            }
    }
}

需要replyTo 来修复消息的实际发送者,因为onComplete 可能在不同的actor 上下文中执行,该上下文可能指向不同的发送者,从而导致消息被发送到错误的actor。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2013-04-12
    • 2015-06-29
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2013-06-29
    • 2016-09-06
    相关资源
    最近更新 更多