凡關機演員

我們有很多演員是那些獲得創建爲凡關機演員

class BankActor extends Actor{ 
    def receive ={ 
     case CreateCustomer(message) => context.actorOf(Props[CustomerActor]) ! message 
    } 
}

而且CustomerActor以類似的方式創建其他演員。以這種方式創建演員的原因可能是將有數百（甚至數千）的由BankActor收到的CreateCustomer消息。我認爲在飛行中創建它們是一種更好的方式（給出Actor是低內存佔用）。我不認爲擁有一個CustomerActor的「池」是一件正確的事情，因爲biz req很清楚會有大量的「CreateCustomer」消息。你能分享一下你的想法嗎？現在回到關於停止「CustomerActor」的問題：我應該在「CustomerActor」的「receive」方法內部在哪裏做context.stop（self），它應該是每個「case」塊中最後一件事情嗎？什麼是最好的做法呢？

來源

2014-04-25 user2066049

這裏沒有足夠的信息給出任何實際的建議。 – Ryan

我會在此迴應Ryan，以獲得有用的回覆，您需要提供更多信息。儘管我會說一件事 - 上面的結構會爲您發送的每條消息創建一個演員，但可能有一個真正的原因，但是如果您只是想在發送消息後停止演員，那麼可能需要重新考慮您的問題設計並嘗試重用已經創建的演員。 –

我已經爲這個問題添加了更多的細節。讓我知道你是否需要更多信息。 – user2066049

避免創建頂級演員，除非您有充分的理由。（Use context.actorOf）

如果您不想在已創建的actor中對關閉進行編碼，請在「消息」之後發送新創建的actor爲PoisonPill。

class BankActor extends Actor{ 
    def receive = { 
     case CreateCustomer(message) => 
     val customer = context.actorOf(Props[CustomerActor]) 
     customer ! message 
     customer ! PoisonPill // message ordering is preserved on a per-sender basis (for all normal mailboxes) 
    } 
}

來源

2014-04-26 11:07:45

謝謝Viktor。在實際上我使用context.actorOf的例子中，這是一個真正的錯字（從字面上輸入片段）。在問題中糾正了它。發送PoisonPill是否遵循正確的事情/方式？case CreateCustomer（message）=> val customerActor = context.actorOf（Props [CustomerActor]）！消息 customerActor！ PoisionPill } – user2066049

是的，確切地說，我添加了一個片段來解釋。 –

回答

相關問題