doc: 阅读transient errors文档
This commit is contained in:
@@ -62,6 +62,9 @@
|
||||
- [retry原理](#retry原理)
|
||||
- [retryWhen](#retrywhen)
|
||||
- [retry helper](#retry-helper)
|
||||
- [retrying with transient errors](#retrying-with-transient-errors)
|
||||
- [handling Exceptions in operators or functions](#handling-exceptions-in-operators-or-functions)
|
||||
>>>>>>> 8d41980 (doc: 阅读transient errors文档)
|
||||
|
||||
# Reactor
|
||||
## Reactive Programming
|
||||
@@ -967,4 +970,25 @@ project reactor提供了`Retry` helper,如`RetrySpec`和`RetryBackoffSpec`,
|
||||
- `doBeforeRetry`和`doAfterRetry`:针对retrytrigger执行side effect
|
||||
- > `doBeforeRetry()`方法触发在delay发生之前,而`doAfterRetry()`触发在delay之后
|
||||
- `onRetryExhaustedThrow(BiFunction)`:在重试数量达到上限后,通过`onRetryExhaustedThrow(BiFunction)`来自定义异常。
|
||||
- 通常情况下,当重试数量达到上限后,自定义异常类型通过`Exceptions.retryExhausted(…)`方法来构建,其返回的异常类型为`RetryExhaustedException`,可以通过`Exceptions.isRetryExhausted(Throwable)`方法来进行区分
|
||||
- 通常情况下,当重试数量达到上限后,自定义异常类型通过`Exceptions.retryExhausted(…)`方法来构建,其返回的异常类型为`RetryExhaustedException`,可以通过`Exceptions.isRetryExhausted(Throwable)`方法来进行区分
|
||||
##### retrying with transient errors
|
||||
在`RetrySignal`中存在如下两个方法:
|
||||
- `totalRetriesInARow()`:每当`error is recovered`(retry attempt导致了`onNext`而不是`onError`)时,index都会被设置为0
|
||||
- `totalRetries()`:`totalRetries()`方法返回的值是单调递增的,并不会被重置
|
||||
|
||||
当使用`RetrySpec`和`RetryBackoffSpec`时,可以通过`transientErrors(true)`方法来令策略使用`totalRetriesInARow()`处理transient error。
|
||||
|
||||
示例如下所示:
|
||||
```java
|
||||
AtomicInteger errorCount = new AtomicInteger();
|
||||
Flux<Integer> transientFlux = httpRequest.get()
|
||||
.doOnError(e -> errorCount.incrementAndGet());
|
||||
|
||||
transientFlux.retryWhen(Retry.max(2).transientErrors(true))
|
||||
.blockLast();
|
||||
assertThat(errorCount).hasValue(6);
|
||||
```
|
||||
|
||||
> `transientErrors`主要是为了处理周期性发生异常,异常能够重试成功,并且发生异常后一段时间平稳运行的场景
|
||||
|
||||
#### handling Exceptions in operators or functions
|
||||
|
||||
Reference in New Issue
Block a user