問題タブ [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.
transactions - スキップが発生したときにバッチが同じチャンク/アイテムの二重処理を防ぐ方法はありますか?
私の特定のシナリオでは、ファイルから読み取った巨大なエンティティをデータベースに永続化する必要がありますが、コミット間隔はvalue = 1
. また、使用されているデリゲート プロセッサがべき等であるかどうかもよくわかりませんCompositeItemProcessor
。だから私の質問は、再処理の無駄な時間を防ぎ、データベースへの多くの未使用のクエリを避ける方法があるかどうかです。また、SkipListener を使用して、特定のテーブルへの読み取り/処理/書き込みのエラーをログに記録し、そのような構成 (再処理なし) がそれに準拠していないと思われます。
春のバッチ 2.1.9 を使用しています。
前もって感謝します。
____________________________更新 2016 年 7 月 5 日__________________________________________
数日間の調査の後、一部のユーザーとスプリング開発者の間で概念的な議論があることに気付きました。
この2014年の投稿の回答に対するコメントで@MichaelMinellaが述べたように、書き込みフェーズ中にスローされたスキップされた例外で設計されたように、この動作が機能することがわかりました。
ItemWriter#write
メソッドはアイテムのリストを受け取ります。一度に 1 つずつ確認しないと、リスト内のどれがライターで例外をスローしたかを判断する方法がありません。
そのため、リスト全体をスキャンせずにフレームワークが失敗した項目を発見する方法はまだありません (チャンク サイズが1であっても)。これを行うためのフレームワークの内部動作は を使用し、FaultTolerantChunkProcessor
はRetryTemplate
この2013 の投稿で説明されています。この問題に関する詳細な議論は、この春のバッチ フォーラム 2012 の投稿で見つけることができます。
java - application.properties ファイルからスプリング @Retryable の maxAttempts を読み取る
注釈の maxAttempts 引数@Retryable
はハードコードされています。ファイルからその値を読み取ることはできapplication.properties
ますか?
何かのようなもの
java - spring @retryable を構成可能にするにはどうすればよいですか?
私はこのコードを持っています
// ここにいくつかの実装 }
@Value を使用して maxAttempts 、遅延、乗数を構成可能にする方法はありますか? または、注釈内のそのようなフィールドを構成可能にする他のアプローチはありますか?
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 つのアノテーションを連携させないのかという問題にはまだ答えていません。
spring - main または service クラスなしで Spring @Retryable を含む
main メソッドを持たない API があります。これは、データベース プロシージャを呼び出すためのクラスのセットです。どのクラスにも Service アノテーションが含まれていません。この API を別のスプリング ブート アプリケーションに含めています。外部 API で @Retryable として任意のメソッドに注釈を付け、Spring ブート アプリケーションから呼び出すと、再試行が提供されません。
これについて助けてもらえますか?
java - @Retryable を使用して例外を除外しようとすると、ExhaustedRetryException がスローされます
@Retryable
REST テンプレートを呼び出すメソッドで使用しようとしています。通信エラーが原因でエラーが返された場合は、再試行したいのですが、それ以外の場合は、呼び出しで例外をスローしたいだけです。
ApiException が発生すると、@Retryable によってスローされて無視されるのではなく、十分な「回復可能」、つまりメソッドExhaustedRetryException
が見つからないという苦情が発生します。@Recover
回復可能なメソッドが存在するだけで満足し、期待どおりに機能するかどうかを確認したいと思いました。それほどでもない。例外をスローする代わりに、回復可能なメソッドを呼び出しました。
任意の洞察をいただければ幸いです。バグですか、それともオペレーターのミスですか?これは Spring Boot 1.3.6 と Spring-Retry 1.1.3 を使用しています。