Spray.io - 向另一個參與者處理委託處理

我使用Spray.io框架實現REST服務。這種服務必須接收一些「搜索」查詢，處理它們並將結果發送回客戶端。通過搜索位於單獨的actor - SearchActor中的代碼，所以在接收到來自用戶的（JSON）查詢後，我重新發送（使用問式）此查詢到我的SearchActor。但是我不明白這是我必須實現spray.io路由演員和我的SearchActor之間的交互。Spray.io - 向另一個參與者處理委託處理

我在這裏看到幾個變體，但哪一個更正確，爲什麼？

在啓動時創建SearchActor的一個實例，每個請求發送到這個演員
爲每個請求創建SearchActor的新實例
在啓動時創建SearchActor演員的游泳池和發送請求到該池

來源

2014-04-23 Vov Pov

你不是被迫使用問句模式。 ~~實際上，它會爲您的每個請求創建一個線程，這可能不是您想要的~~。我建議您改用tell。您可以通過爲每個請求產生一個新的Actor（~~比線索~~便宜）做到這一點，其中RequestContext在其構造函數字段之一中。您將使用此上下文將響應返回，通常使用其方法complete。

示例代碼。

class RESTActor extends HttpService { 
    val route = path("mypath") ~ post { 
    entity(as[SearchActor.Search]) { search => ctx => 
     SearchActor(ctx) ! search 
    } 
    } 
} 

case class SearchActor(ctx: RequestContext) { 
    def receive = { 
    case msg: Search => //... search process 
    case msg: Result => ctx.complete(msg) // sends back reply 
    } 
}

來源

2014-04-24 02:30:51 Leo

>「它會創建一個線程」 WAT？ – ZhekaKozlov

來自Akka doc的一些澄清=>問：創建一個臨時的一次性演員來接收消息的回覆並完成一個scala.concurrent.Future與它;回報說未來。噴霧在其指令中處理期貨。所以，不，它不會創建線程。上述方法與使用ask模式非常相似。這取決於你想寫你的商業邏輯的地方。 – Leo

關於講述/問題差異的有趣討論=> https://groups.google.com/forum/#!topic/akka-user/GlMq6J4ZlAc – Leo

變體＃1在初始實現後沒有問題 - 您想要擴展，所以單個阻塞actor是不好的。

變體＃2和＃3並沒有很大的不同 - 創建新演員很便宜，開銷也很小。由於你的演員經常死亡（即後端不可用），我會說＃2是要走的路。

具體實現的想法顯示在http://techblog.net-a-porter.com/2013/12/ask-tell-and-per-request-actors/

來源

2014-04-24 02:31:36 abatyuk

Spray.io - 向另一個參與者處理委託處理

回答

相關問題