問題タブ [spring-retry]

For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.

0 投票する
1 に答える
916 参照

transactions - スキップが発生したときにバッチが同じチャンク/アイテムの二重処理を防ぐ方法はありますか?

私の特定のシナリオでは、ファイルから読み取った巨大なエンティティをデータベースに永続化する必要がありますが、コミット間隔はvalue = 1. また、使用されているデリゲート プロセッサがべき等であるかどうかもよくわかりませんCompositeItemProcessor。だから私の質問は、再処理の無駄な時間を防ぎ、データベースへの多くの未使用のクエリを避ける方法があるかどうかです。また、SkipListener を使用して、特定のテーブルへの読み取り/処理/書き込みのエラーをログに記録し、そのような構成 (再処理なし) がそれに準拠していないと思われます。

春のバッチ 2.1.9 を使用しています。

前もって感謝します。

____________________________更新 2016 年 7 月 5 日__________________________________________

数日間の調査の後、一部のユーザーとスプリング開発者の間で概念的な議論があることに気付きました。

この2014年の投稿の回答に対するコメントで@MichaelMinellaが述べたように、書き込みフェーズ中にスローされたスキップされた例外で設計されたように、この動作が機能することがわかりました。

ItemWriter#writeメソッドはアイテムのリストを受け取ります。一度に 1 つずつ確認しないと、リスト内のどれがライターで例外をスローしたかを判断する方法がありません。

そのため、リスト全体をスキャンせずにフレームワークが失敗した項目を発見する方法はまだありません (チャンク サイズが1であっても)。これを行うためのフレームワークの内部動作は を使用し、FaultTolerantChunkProcessorRetryTemplateこの2013 の投稿で説明されています。この問題に関する詳細な議論は、この春のバッチ フォーラム 2012 の投稿で見つけることができます。

0 投票する
2 に答える
4122 参照

java - application.properties ファイルからスプリング @Retryable の maxAttempts を読み取る

注釈の maxAttempts 引数@Retryableはハードコードされています。ファイルからその値を読み取ることはできapplication.propertiesますか?

何かのようなもの

0 投票する
5 に答える
29816 参照

java - spring @retryable を構成可能にするにはどうすればよいですか?

私はこのコードを持っています

// ここにいくつかの実装 }

@Value を使用して maxAttempts 、遅延、乗数を構成可能にする方法はありますか? または、注釈内のそのようなフィールドを構成可能にする他のアプローチはありますか?

0 投票する
3 に答える
1767 参照

java - @PostConstruct と @Retryable を一緒に使用できないのはなぜですか?

を使用して、Spring Framework ベースのアプリケーションを作成しましたAnnotationConfigApplicationContext

1 つの Bean には、外部サービスへの接続を作成する init メソッドがあります。@PostConstructこれは、Bean が開始されると自動的に実行されるように注釈を付けることができます。

この接続を作成するときに例外を処理するには、例外がキャッチされた場合に init メソッドを最大 5 回再試行する必要があります。メソッドに両方の注釈を付けると@PostConstruct@Retryable例外が1回スローされ、プログラムが終了することがわかります-@Retryable効果がないように見えます。

@EnableRetryと一緒に構成クラスで正しく使用しました@Configuration。再試行可能として注釈が付けられた同じ Bean に別のメソッド B を作成しました。Bean がインスタンス化された後にこのメソッドが呼び出されると、例外がスローされたときにメソッドが再試行され、期待どおりに動作することがわかります。

なぜこれが機能しないのかについての私の考えは、おそらくアスペクトに関連するものであるか、またはスプリング再試行要素がアタッチされる前にポストコンストラクトが発生するのでしょうか?

メソッドでプログラムで試すのではなく、例外を処理し、注釈を介して再試行できる初期化メソッドを持つより良い方法は実際にありますか?

編集: 外部サービスへの接続の作成は 経由で行うべきではないことに同意します@Postconstruct。これにより、再試行が失敗した場合にコンテキスト全体の初期化が停止し、悪影響が生じる可能性があります。

ただし、これは、Spring Framework のどの部分がこれら 2 つのアノテーションを連携させないのかという問題にはまだ答えていません。

0 投票する
1 に答える
540 参照

spring - main または service クラスなしで Spring @Retryable を含む

main メソッドを持たない API があります。これは、データベース プロシージャを呼び出すためのクラスのセットです。どのクラスにも Service アノテーションが含まれていません。この API を別のスプリング ブート アプリケーションに含めています。外部 API で @Retryable として任意のメソッドに注釈を付け、Spring ブート アプリケーションから呼び出すと、再試行が提供されません。

これについて助けてもらえますか?

0 投票する
1 に答える
16028 参照

java - @Retryable を使用して例外を除外しようとすると、ExhaustedRetryException がスローされます

@RetryableREST テンプレートを呼び出すメソッドで使用しようとしています。通信エラーが原因でエラーが返された場合は、再試行したいのですが、それ以外の場合は、呼び出しで例外をスローしたいだけです。

ApiException が発生すると、@Retryable によってスローされて無視されるのではなく、十分な「回復可能」、つまりメソッドExhaustedRetryExceptionが見つからないという苦情が発生します。@Recover

回復可能なメソッドが存在するだけで満足し、期待どおりに機能するかどうかを確認したいと思いました。それほどでもない。例外をスローする代わりに、回復可能なメソッドを呼び出しました。

任意の洞察をいただければ幸いです。バグですか、それともオペレーターのミスですか?これは Spring Boot 1.3.6 と Spring-Retry 1.1.3 を使用しています。