したがって、この質問は私の古い質問に関連しています。同じ Akka ActorSystem を再利用する必要がありますか、それとも必要なたびに作成できますか?
アクターのライフサイクルについて質問したところ、頭の中で何かが間違っていることはわかっていましたが、正しく言い表すことができませんでした。うまくいけば、私は今できる:-)。
これが状況です。他のコンポーネントやアクターに依存するアクターをテストしたいので、ブートストラップ時間でアクターを作成しました (私は scalatra を使用していますが、アプリをブートストラップします)。したがって、私は次のようなものを持っています:
trait DependencyComponent
{
val dependency : Dependency
}
trait ActorComponentA extends Actor with DependencyComponent {
val actorB : ActorRef
}
trait ActorComponentB extends Actor with DependencyComponent
よし、トレイトを拡張し、モックの依存関係を提供することで、アクターをテストできるようになりました。そして、次のようにアプリをブートストラップできます。
ブートストラップ
val system = ActorSystem()
val actorA = system.actorOf(Props[DefaultActorA])
class DefaultActorB extends ActorComponentB {
val dependency = new RealDependency()
}
class DefaultActorA extends ActorComponentA {
val dependency = new RealDependency()
val actorB = context.actorOf(Props[DefaultActorB]).withRouter(RoundRobinRouter(nrOfInstances = 100)))
}
クールです、私は幸せです :-)、これで自分のアプリ内でアクター システムとアクター A を使用できるようになり、作業を渡すために 100 個のアクター B がルーティングされました。したがって、actorA が作業が完了したと判断した場合、ルーティングされたアクターにブロードキャストしてシャットダウンする必要があることを理解しています。この時点で別のリクエストが来ると、ActorA はすべてのアクターが停止しているため、ルーターにメッセージを送信できなくなります。
起動時にこれを設定しなかった場合、actorA とその依存関係は、必要に応じてアプリで作成できます。しかし、それはDIの世界で「オブジェクトを新しくする」ことに非常に似ています。テストするために、アクターが作成された場所をオーバーライドすることになります。
Scalatra のドキュメントでは、起動時にアクターを作成することが提案されているため、ここで何かが欠けているように感じます。どんな助けでも感謝します。
乾杯、クリス。
編集
@futurechimp と @cmbaxter の両方に +1 を付けました。これらはどちらも有効ですが、少し矛盾しているようです。だから、これはあなたの両方へのオープンなコメントです。
だから@cmbaxterは、ルーティングされたアクターで「停止」を決して呼び出さず、すべてのリクエストで使用するためにそれらのプールを維持することを提案していると考えています。そして@futurechimp、サーブレットにリクエストごとにアクターをインスタンス化し、ライフサイクルの最後にアクターを殺すことを提案しています。右?
リクエストごとにより多くのアクターが生成されるようです (ただし、それらは破棄されます)。ポーリングがすべてのリクエストに対して限られたセットしか持たない場合、このアプローチにボトルネックが生じる可能性はありますか?
基本的に、私の仮定が正しいかどうかを尋ねていると思います。もしそうなら、両方のアプローチの長所と短所は何ですか?