問題タブ [spring-retry]

私は注釈ベースのSpring Retryを使用しています。以下は私のインターフェースです：

このインターフェイスを実装してダウンストリーム サービスを呼び出す 3 つのクラスがあります。ダウンストリーム呼び出しごとに個別の再試行ポリシーを定義できるように、RetryInterceptors を定義したいと考えています。要するに、実行時に RetryInterceptor を変更したいのです。

Spring で実行時に RetryInterceptor を変更し、コードで特定の RetryOperationsInterceptor を使用する方法はありますか?

Kafka からメッセージを取得し、ターゲット システムを呼び出してレガシー Oracle DB を更新するアプリケーションがあります。

ターゲット システムがダウンしている場合、メッセージを Kafka バスに残し、一定期間処理しないシナリオを有効にしたいと考えています。サーキットブレーカーの Hystrix ベースのソリューションを考えていましたが、Spring Cloud Stream にイベントのリッスンを「停止」するように指示するメカニズムが見つかりません。私が考えることができる他の唯一の代替手段は、サーキットブレーカーが開いている場合に、これらのメッセージをエラー/再処理トピックに転送することですが、それはアンチパターンのように思えます。システムがイベントを処理するのを一時停止できるはずです。これが、マイクロ サービス アプリでの pub/sub の利点です。

どんな助けでも感謝します。

Spring Retry を組み込んだ Spring Integration プロジェクトを継承しました。それがテストされたことがあるかどうかはわかりませんし、個別のテストもありません。そのため、単純なシナリオでそれを実行しようとしています。

RestTemplateexchangeメソッドをモックすることで、再試行ロジックをテストできるようにしたいと考えています。発生させたい例外を取得できますが、発生するのは 1 回だけです。再試行は行われません。

再試行アドバイスの XML は次のとおりです (retry-advice-context.xml):

以下は、SI 処理ファイルの一部です。

したがって、再試行 BeanretryAdviceは、さまざまなチェーンの一部です。チェーンには他にもたくさんあるので、サービス層からの再試行ロジックをチェックできるようにしたいだけです。コードのどこにも Retry アノテーションはありません (必要かどうかはわかりません)。

いくつかの質問:

1. サービス層から再試行機能をテストできますか? それともチェーン全体を実行する必要がありますか?
2. 再試行メカニズムに必要なもの (注釈、その他の XML) が不足していませんか?

ところで、これは SI 4.1.3 を使用しています。

ありがとう。

更新 1:

私の環境で Gary のプロジェクトを実行することができました。その後、retry-advice-context.xmlファイルをメインの SI xml に追加しました。マップのみを含むように変更しRuntimeExceptionました。ログステートメントはExponentialBackoffPolicyステートメントを示しました。RetryTemplateデバッグ ログ ステートメントも取得していました。

もう少し理解を深めて、そこにあったものを実際のコードに翻訳し、より多くの成功を収めました。例外が発生し、最大 3 回再試行されるというログ ステートメントが表示されます。

残念ながら、私が得るものは次のとおりです。

そのため、最初は最大 3 回再試行する必要があることを認識しています。しかし、1回の再試行の後に最後の試行が行われたと述べています。

Gary の作業コードでは、デバッグ ステートメントはRetry: count=2次の連続する試行に対して etc... を表示します。

sleepスポック テスト コードには、再試行が行われている間にステートメントがあります。そのまま時間を長くしたり短くしたりしました。

再試行コードを引き続き試行してデバッグし、1 回目の再試行で停止する理由を確認します。

POST エンドポイントを持つスプリング ブート API アプリケーションがあります。メソッドとして /doSomething と呼びましょう。そのリクエストでは、API [B] から取得する必要があり、API [B] に再度投稿する必要があります。その場合、スプリングの再試行を処理する最良の方法は何ですか。

以下のコードを見つけてください

IntegrationServiceBean クラス

私の問題は、統合サービス Bean に再試行が適用された場合、アプリケーションの主要部分のパフォーマンスに影響を与えることです。

そして、ベストプラクティスは何でしょうか

IBM の JRE 1.7 でスプリング バッチ ジョブを起動すると、エラーが発生します。

Spring Batch のバージョンは 3.0.7、Spring のバージョンは 4.3.5

このエラーは、Oracle JDK 1.7 では発生しません。ジョブが開始される前に、Spring Batch XML 構成、jobs-configuration.xml をロードすると表示されます。この問題は、Spring Batch と Spring をアップグレードした後に発生しました: Spring Batch の org.springframework.batch.classify.BackToBackPatternClassifier は org.springframework.classify.BackToBackPatternClassifier になりました (Spring Retry で)

ジョブ構成.xml:

ClassifierCcsb01Writer: