REST サービスから読み取りを行っていますが、頻繁に使用されるサービスの「待機して再試行」を処理する必要があり、エラーが発生します。
1 秒あたりのクエリ数が多すぎる
また
サーバービジー状態
一般的に言えば、多くの REST サービスを呼び出す必要があるため、例外が発生したときに発生するバックオフ ロジックを一般的に処理するにはどうすればよいでしょうか?
これが組み込まれているフレームワークはありますか?配管やインフラストラクチャについてあまり心配しないクリーンなコードを書きたいだけです。
REST サービスから読み取りを行っていますが、頻繁に使用されるサービスの「待機して再試行」を処理する必要があり、エラーが発生します。
1 秒あたりのクエリ数が多すぎる
また
サーバービジー状態
一般的に言えば、多くの REST サービスを呼び出す必要があるため、例外が発生したときに発生するバックオフ ロジックを一般的に処理するにはどうすればよいでしょうか?
これが組み込まれているフレームワークはありますか?配管やインフラストラクチャについてあまり心配しないクリーンなコードを書きたいだけです。
再試行ロジックを処理するメソッド内で試行をラップできます。たとえば、WebClientの非同期メソッドを使用している場合:
public async Task<T> RetryQuery<T>(Func<Task<T>> operation, int numberOfAttempts, int msecsBetweenRetries = 500)
{
while (numberOfAttempts > 0)
{
try
{
T value = await operation();
return value;
}
catch
{
// Failed case - retry
--numberOfAttempts;
}
await Task.Delay(msecsBetweenRetries);
}
throw new ApplicationException("Operation failed repeatedly");
}
次に、次の方法でこれを使用できます。
// Try 3 times with 500 ms wait times in between
string result = await RetryQuery(async () => webClient.DownloadStringTaskAsync(url), 3);
Enterprise Library の一部であるTransient Fault Handling Application Blockを調べることをお勧めします。
過去に、EL は IMO が過度に設計されており、それほど有用ではありませんでしたが、それに対処するための措置を講じました。TFHAB は、より優れた設計ガイドライン (これも IMO) に従っている新しいブロックの 1 つです。