問題タブ [retrypolicy]

これは私のラバフロー 1です。

最初のフローには次のものがありerror handlingます。

File(処理されるメッセージごとにファイルを書き込みます)

フロー 2 :

リカバリ フロー( groovy スクリプトで呼び出す):

これは、Mule からの XML です。

1. からサービスを停止するActiveMQと、エラー処理からのメッセージを含むファイルが保存され、典型的なエラーが表示されます。

「Active_MQ」が停止しているため、イベントを処理できません

2. 次に、ActiveMQ serviceもう一度実行し、groovy スクリプトを使用して回復フローを開始します。そのフローはすべてのメッセージを回復し、文字列に変換して、最初のフローに戻って再キューイングします。

問題は、サービスが再実行されたときにミュールが検出されないことです。これを検出するには、ミュール プロジェクトを再起動する必要があります。

ActiveMQ が Mule で再び実行されていることを自動検出する方法はありますか?

私のサービスは DService で、サービス チェーンの 4 番目のリンクです。つまり、コール フローは、オンライン ユーザー -> AService -> BService -> CService -> DService -> EService です。

DService から EService を呼び出すと、HttpTimeoutException のような再試行可能な例外がスローされることがあります。私は通常、2 ～ 3 回再試行し、2 ～ 3 回再試行しても失敗した場合は例外をスローします。

私の質問は、私が CService にスローしている例外は、再試行可能または再試行不可である必要がありますか? 両方のオプションの長所と短所の私の評価を以下に見つけてください

DService から 再試行可能な例外をスローすることの短所 - DService が再試行可能な例外をスローした場合、同じ規則に従って、CService も DService を 2 ～ 3 回再試行し、CD の呼び出しごとに、D は E サービス呼び出しに対して 2 ～ 3 回再試行します。同様に、最終的に EService への呼び出しは、呼び出しチェーンを上るにつれて指数関数的に増加します。したがって、EService ネットワークが実際に長時間ダウンしていた場合、不要な呼び出しが多数発生していることになります。これは、チェーン内の各呼び出しにタイムアウトを設定することで軽減できますが、不要な数の呼び出しに対して十分な軽減策であるかどうかはまだわかりません.

DService から再試行可能な例外をスローすることの長所 - CService は、その後の再試行で正しい値が得られる可能性があるため (制限時間内に) しばらくしてから再試行します - 特にクライアントがバックエンド ジョブである場合、あきらめる前に指数関数的に長時間再試行できます。 . Un-Retriable 例外をスローすると、このオプションが取り除かれます

これについてあなたの意見や提案をお寄せください

ありがとう、ハリッシュ

Azure Table Storage を使用しており、InsertOrMerge 操作を実行するときに 408 タイムアウトが発生することがあります。この場合、再試行したいのですが、これらのエラーに対して再試行ポリシーが守られていないようです。

これは、テーブルの相互作用を処理するために使用するクラスです。メソッド GetFooEntityAsync は、Table Storage からエンティティを取得しようとします。できない場合は、新しい FooEntity を作成し、それをテーブルに追加します (FooTableEntity へのマッピング)。

GetFooEntityAsync() を呼び出すと、"Request failed" 行が実行されることがあります。値を検査する場合args.RequestInformation.HttpStatusCode= 408。ただし、次のようになります。

• Debug.WriteLine("Got a 408");GetFooEntity メソッド内では実行されません。

• Debug.WriteLine($"Retry policy activated...デリゲート内でDefaultOperationContext.Retrying実行されることはありません（これは2回実行されると予想されます-これは再試行ではありませんか？）。

• DefaultOperationContext.RequestResults結果の長いリストが含まれています (ほとんどの場合、ステータス コードは 404、一部は 204 です)。

この (かなり古い) ブログ投稿によると、コード 400 から 500、および 501 から 505 の例外は再試行できません。ただし、タイムアウト (408) は、まさに再試行が必要な状況です。この場合、カスタムの再試行ポリシーを作成する必要があるかもしれません。

RequestCompleted デリゲートが呼び出されたとき以外のコードでは見つからないため、408 がどこから来ているのか完全にはわかりません。再試行ポリシーのさまざまな設定を試してみましたが、うまくいきませんでした。ここで何が欠けていますか？テーブルストレージから 408 で操作を再試行するにはどうすればよいですか?

編集:コードを更新して、実装したカスタム再試行ポリシーを表示し、408 エラーで再試行します。ただし、再試行のブレークポイントがまだヒットしていないように見えるため、再試行がトリガーされていないようです。再試行ポリシーがアクティブ化されない理由は何ですか?

Curator を newClient に使用し、リトライ ポリシーを設定しましたが、接続文字列が間違っている場合、接続されたリトライは常にメモリ不足になるまで実行されますが、プログラムを一度終了させて​​、リトライを 3 回実行したいと考えています。

頻繁に失敗し、再試行する必要があるコードがある場合。次に、再試行パターンを使用します。

通常、そのリクエストを再試行する前に数ミリ秒遅延します。なぜ遅延が必要なのか知りたいのですが？再試行リクエストが待機せずに再度リクエストを送信した場合はどうなりますか。