問題タブ [akka-supervision]

ここで DbActor によってスローされた例外をどのように処理すればよいですか? 処理方法がわかりません。Failure ケースをパイプする必要がありますか?

ご意見をお待ちしております。よろしくお願いします。

私が構築している新しい akka アプリケーションに関して、設計上の課題があります。問題/課題は次のとおりです。クライアント側で、リクエストを送信する単純なアクターを作成し、bebe() を使用して適切なサーバーの応答を待ちます。もちろん、タイムアウト メッセージも含めます。適切な時間内に回答が得られない。ただし、興味深いのはサーバー側です。ここに私は次の構造を持っています：

アクター A (ラウンド ロビン ルーターとして構成) このルーターは、クライアントからすべての要求を受信して​​います。

次に、アクター A はメッセージをアクター A1、A2...Ax に転送します。これらはすべてアクター A のコンテキストで作成されたものであり、アクター A がスーパーバイザーであることを意味します。

通常の場合、メッセージは転送されるため、Actor Axe は送信者に返信するだけで済みますが、エラーが発生した場合は、サーバー ログにログを記録するだけでなく、ユーザーに通知することもできます。発生したエラーに関する情報の種類。

完璧な世界では、スーパーバイザー戦略で getErrorActorsLastSender() のようなことを言ってから、問題の原因となったクライアントの ActorRef を取得できるようにしたいと考えています。私がこれを好む理由は、すべてのエラー処理を 1 か所で行うことができ、すべての予期しない例外が少なくとも何らかの一般的な方法で常に処理されるからです。

別の方法は、各子アクターで prerestart() メソッドをオーバーライドし、例外がスローされたときにアクターを再起動するスーパーバイザー戦略を作成することです。ただし、これには x 子アクターに対してこのメ​​ソッドを実装する必要があります。

これがスーパーバイザーの戦略から可能である場合、何か良い提案はありますか?

前もって感謝します。

私は Akka が初めてで、このパラメーターを使用した例と使用時のヒントが必要です!

Akka doc を読む: http://doc.akka.io/docs/akka/2.2.3/AkkaScala.pdfセクションの状態

しかし、階層ツリーの最上位では、親アクターにはスーパーバイザーがありませんか?

私は現在、Akka (Java バージョン) でのフォールト トレランスとスーパーバイザーの戦略を検討しています。

... http://doc.akka.io/docs/akka/2.3.2/java/fault-tolerance.htmlおよびhttp://doc.akka.io/docs/akka/2.3.2/general/ Supervisor.html#supervision

いくつかの質問：

1) どのような種類の例外が予想されるかがわかっている場合、アクターで try/catch ブロックを使用する必要がありますか? なぜですか、そうでないのですか？そうでない場合、子がスローする可能性のある例外を効果的に処理するために、スーパーバイザー戦略に依存する必要がありますか?

2) デフォルトでは、スーパーバイザーが親アクターで明示的に構成されていない場合、例外をスローした子アクターはデフォルトで再起動されるように見えます。システム全体で状態を保持するアクターがいない場合はどうなりますか? 本当に再起動を行う必要がありますか?

3) system.actorOf( ... ) によって作成されたトップレベルのアクターが例外をスローした場合はどうなりますか? アクター システムの外でスーパーバイザー戦略をどのように提供しますか?

4) アクター A が子アクター B を持つシナリオを想定してみましょう。ここで、アクター A がアクター B に何らかの作業を依頼したとします。

一部のコードは次のようになります。

さて... アクター A が何らかの形で例外をスローした場合はどうなるでしょうか。デフォルトでは、スーパーバイザによって再起動されます。問題は、onComplete の「閉鎖」が今後も実行されるのか、それとも再起動時に効果的に「一掃」されるのかということです。

5) A->B->C のような階層があるとします。また、preRestart をオーバーライドして、効果的に子供を停止させないと仮定しましょう。A のプレスタートでは getContext().actorOf(B) を呼び出し、B のプレスタートでは getContext().actorOf(C) を呼び出します。A が例外をスローした場合、複数のアクター B と複数のアクター C がシステムに存在することになりますか?

ありがとう！

私はベスト プラクティスに従い、Akka でエラー カーネル パターンを適用しようとしています。ここからのこの引用によると：

1 つのアクターが非常に重要なデータを運ぶ場合 (つまり、回避可能であればその状態が失われてはならない)、このアクターは、監督する子に潜在的に危険なサブタスクを供給し、これらの子の失敗を適切に処理する必要があります。要求の性質によっては、要求ごとに新しい子を作成するのが最善の場合があります。これにより、応答を収集するための状態管理が簡素化されます。これは、Erlang の「エラー カーネル パターン」として知られています。

... 子を作成し、エラーが発生しやすい作業を子に委任して、重要な状態を親/スーパーバイザー アクターに集中させることをお勧めします。

このシナリオで、重要な状態のアクターが何らかの理由で再起動された場合、その古い子 (再起動前に作成されたもの) からのメッセージを処理する必要がありますか?

これを例で説明しましょう。

アクターが 3 人いると仮定しましょう: A(の親/スーパーバイザーB)、B(の親/スーパーバイザーC、重要な状態を含む)、およびC.

Aの監視戦略は、例外が発生した場合にその子を再起動するように構成されています。

CBのコンストラクタで作成されます。

次に、メッセージbcがフォームBから に送信されたとしますC。C処理を開始し (そこで長時間実行される計算を実行すると想像してください)、処理が完了すると、 に応答Bしcbます。

ここで、 before が に送信され、 send メッセージcbによって処理されたと仮定します。このメッセージによって例外がスローされ、の監視戦略の決定が再開されます。B AabBBAB

の子としての再起動B C中に停止しますB( のコンストラクターで newC'が作成されますB)。

再起動する前に送信されたものからB受信を再起動しますか?cbCB

はいの場合、senderof cb( C) は restarted の子と見なされBますか? アクターの ref のCとは等しいでしょうか (との名前が等しいとC'仮定します)?CC'