問題タブ [spring-retry]

Retry を使用した次の Spring Integration 構成があります。

簡略化された Java コードは次のとおりです。

このコードを再試行する際の問題は、List sdConfCodes が再試行のたびに部分的に処理される可能性があるため、処理のために送信する必要があるたびに、より少ない量の要素を処理する必要があることです。このコードを整理する最良の方法は何ですか?

Artem Bilan の提案 (ありがとう!) に従って、SDCreationServiceImpl の変数リストを使用して 2 番目のメソッド、つまり activateConfirmationCodes を作成し、XML 仕様でこのメソッドを sdCreationServiceImpl のメソッドとして指定しました。

そして、service-activator の XML 仕様は次のとおりです。

はい、このメソッド activateConfirmationCodes は Retry で呼び出されますが、最初のメソッド processMessage はまったく呼び出されません。最初の試行で呼び出す方法を 1 つ指定し、再試行する方法を別の方法で指定することはできますか? この設計では、リストがシングルトンになり、マルチスレッドで問題が発生する可能性がありますね。このリストを特定のメッセージのみの Bean に関連付けることはできますか?

概要:リーダー/プロセッサ/ライターが成功した場合でも、ジョブが再起動/再試行されます。

私のステップは次のように定義されています。

ある時点で、特定の HTTP エラーが発生したときに再試行をトリガーしたいのですが、この時点で、そのコードはすべてコメントアウトされています。Item* インターフェイスを実装する単純なクラスと、チャンク サイズ 1 しかありません。

繰り返しポリシーを複数回にするように指示できることは何もしていません。

私のアプリケーションは、複数の JMS リスナーを持つ Spring Boot アプリケーションです。リスナーがメッセージを受け取ると、メッセージの内容を含む適切なジョブをディスパッチします。

この仕事は輸出です。JMS メッセージは、エクスポートするレコードの ID を提供します。ItemReader (@StepScope で注釈が付けられている) は、レコードを Map に取り込みます。ItemProcessor は、追加データを Map に追加します。ItemWriter は、以前に収集したデータを使用して Basic 認証で HTTP POST を実行します。

テスト クラスは、別のプロセスで、REST リスナーを登録し、JMS メッセージを送信します。REST メソッドはメッセージを受け取ると終了します。これは成功を意味します。(テストを強化する必要があります。)

現在起こっていることは、REST トランザクションが成功した (例外/エラーなし、認証パス、データが双方向で交換された) にもかかわらず、Batch フレームワークがステップを繰り返すということです。テスト クラスは REST 要求に応答した後に終了するため、新しい POST は失敗します。1回実行したところ、120回以上再試行されました。

質問: 成功した場合、再試行/繰り返しメカニズムがトリガーされないようにするにはどうすればよいですか?

ログ:

Spring Retryで外部呼び出しとどのように統合できますAsyncRestTemplateか? それが不可能な場合、それをサポートする別のフレームワークはありますか?

私のユースケース:

future.get()この呼び出しを再試行するにはどうすればよいですか? 外部サービスが 404 を返した場合、その間にそれらのタスクを再び呼び出さないようにして、外部呼び出しを再試行したいですか? 実際には外部サービスへの別の呼び出しを行わないため、 aでラップfuture.get()することはできません。retryTemplate.execute()

Amazon S3 にファイルをアップロードするこのタスクレットがあります。AmazonClientExceptionここで、がスローされるたびにタスクレットの実行を再試行したいと考えています。@Retryableアノテーションを使用するとうまくいくと思いました。

タスクレット:

ジョブ構成:

しかし、それはそれがするべきことをしません。例外がスローされたときに、バッチ ジョブはまだタスクレットを再試行しません。

何かご意見は？

構成もこちら

春の再試行を試みていますが、奇妙な問題に直面しています。Rest Controller 内のメソッドで retry アノテーションを使用すると、再試行が機能しません。しかし、そのメソッドを別のサービス クラスに移動すると、機能します。次のコードは機能しません。

しかし、次のようにします。

私の質問は@Retryable、コントローラーで使用するとなぜ動作しないのですか?

I am trying implement sample retry mechanism for RabbitMQ using Spring's StatefulRetryOperationsInterceptor.

As stated in documentation, I need to setup message key generator as the message id is absent. What I don't understand is the real usage of unique id generated per message. i.e. when I used below implementation I did not have any issue with retry:

JpaOptimisticLockingFailureException が発生した場合にトランザクション サービス メソッドをリトライしたい

サービスメソッドに @Retryable アノテーションを付けると

サービスメソッドは次のロジックを実行します

一度に 2 つのリクエストを実行します (JpaOptimisticLockingFailureException が発生する状況を作成します)。

最初のトランザクションはコミットされ、2 番目は JpaOptimisticLockingFailureException をスローして再試行します。

findOrCreate メソッドまたは getByCode メソッドを呼び出す代わりに、顧客の挿入時に再試行が失敗する

適切に再試行可能にすることは可能ですか?