SpringCloud/spring-cloud-circuitbreaker
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Split files

Browse Source
This commit is contained in:
spencergibb
2023-09-14 19:23:23 -04:00
parent 3c24c6895b
commit 883ab8bb2b
13 changed files with 394 additions and 392 deletions
Download Patch File Download Diff File Expand all files Collapse all files

328
docs/modules/ROOT/pages/spring-cloud-circuitbreaker-resilience4j.adoc
View File

@@ -1,331 +1,3 @@
[[configuring-resilience4j-circuit-breakers]]
= Configuring Resilience4J Circuit Breakers
[[starters]]
== Starters
There are two starters for the Resilience4J implementations, one for reactive applications and one for non-reactive applications.
* `org.springframework.cloud:spring-cloud-starter-circuitbreaker-resilience4j` - non-reactive applications
* `org.springframework.cloud:spring-cloud-starter-circuitbreaker-reactor-resilience4j` - reactive applications
[[auto-configuration]]
== Auto-Configuration
You can disable the Resilience4J auto-configuration by setting
`spring.cloud.circuitbreaker.resilience4j.enabled` to `false`.
[[default-configuration]]
== Default Configuration
To provide a default configuration for all of your circuit breakers create a `Customizer` bean that is passed a
`Resilience4JCircuitBreakerFactory` or `ReactiveResilience4JCircuitBreakerFactory`.
The `configureDefault` method can be used to provide a default configuration.
====
[source,java]
----
@Bean
public Customizer<Resilience4JCircuitBreakerFactory> defaultCustomizer() {
return factory -> factory.configureDefault(id -> new Resilience4JConfigBuilder(id)
.timeLimiterConfig(TimeLimiterConfig.custom().timeoutDuration(Duration.ofSeconds(4)).build())
.circuitBreakerConfig(CircuitBreakerConfig.ofDefaults())
.build());
}
----
====
[[reactive-example]]
=== Reactive Example
====
[source,java]
----
@Bean
public Customizer<ReactiveResilience4JCircuitBreakerFactory> defaultCustomizer() {
return factory -> factory.configureDefault(id -> new Resilience4JConfigBuilder(id)
.circuitBreakerConfig(CircuitBreakerConfig.ofDefaults())
.timeLimiterConfig(TimeLimiterConfig.custom().timeoutDuration(Duration.ofSeconds(4)).build()).build());
}
----
====
[[customizing-the-executorservice]]
=== Customizing The ExecutorService
If you would like to configure the `ExecutorService` which executes the circuit breaker you can do so using the `Resilience4JCircuitBreakerFactory`.
For example if you would like to use a context aware `ExecutorService` you could do the following.
====
[source,java]
----
@Bean
public Customizer<ReactiveResilience4JCircuitBreakerFactory> defaultCustomizer() {
return factory -> {
ContextAwareScheduledThreadPoolExecutor executor = ContextAwareScheduledThreadPoolExecutor.newScheduledThreadPool().corePoolSize(5)
.build();
factory.configureExecutorService(executor);
};
}
----
====
[[specific-circuit-breaker-configuration]]
== Specific Circuit Breaker Configuration
Similarly to providing a default configuration, you can create a `Customizer` bean this is passed a
`Resilience4JCircuitBreakerFactory` or `ReactiveResilience4JCircuitBreakerFactory`.
====
[source,java]
----
@Bean
public Customizer<Resilience4JCircuitBreakerFactory> slowCustomizer() {
return factory -> factory.configure(builder -> builder.circuitBreakerConfig(CircuitBreakerConfig.ofDefaults())
.timeLimiterConfig(TimeLimiterConfig.custom().timeoutDuration(Duration.ofSeconds(2)).build()), "slow");
}
----
====
In addition to configuring the circuit breaker that is created you can also customize the circuit breaker after it has been created but before it is returned to the caller.
To do this you can use the `addCircuitBreakerCustomizer`
method.
This can be useful for adding event handlers to Resilience4J circuit breakers.
====
[source,java]
----
@Bean
public Customizer<Resilience4JCircuitBreakerFactory> slowCustomizer() {
return factory -> factory.addCircuitBreakerCustomizer(circuitBreaker -> circuitBreaker.getEventPublisher()
.onError(normalFluxErrorConsumer).onSuccess(normalFluxSuccessConsumer), "normalflux");
}
----
====
[[reactive-example]]
=== Reactive Example
====
[source,java]
----
@Bean
public Customizer<ReactiveResilience4JCircuitBreakerFactory> slowCustomizer() {
return factory -> {
factory.configure(builder -> builder
.timeLimiterConfig(TimeLimiterConfig.custom().timeoutDuration(Duration.ofSeconds(2)).build())
.circuitBreakerConfig(CircuitBreakerConfig.ofDefaults()), "slow", "slowflux");
factory.addCircuitBreakerCustomizer(circuitBreaker -> circuitBreaker.getEventPublisher()
.onError(normalFluxErrorConsumer).onSuccess(normalFluxSuccessConsumer), "normalflux");
};
}
----
====
[[circuit-breaker-properties-configuration]]
== Circuit Breaker Properties Configuration
You can configure `CircuitBreaker` and `TimeLimiter` configs or instances in your application's configuration properties file.
Property configuration has higher priority than Java `Customizer` configuration.
Descending priority from top to bottom.
* Method(id) config - on specific method or operation
* Service(group) config - on specific application service or operations
* Global default config
====
[source,java]
----
ReactiveResilience4JCircuitBreakerFactory.create(String id, String groupName)
Resilience4JCircuitBreakerFactory.create(String id, String groupName)
----
====
[[global-default-properties-configuration]]
=== Global Default Properties Configuration
====
[source]
----
resilience4j.circuitbreaker:
configs:
default:
registerHealthIndicator: true
slidingWindowSize: 50
resilience4j.timelimiter:
configs:
default:
timeoutDuration: 5s
cancelRunningFuture: true
----
====
[[configs-properties-configuration]]
=== Configs Properties Configuration
====
[source]
----
resilience4j.circuitbreaker:
configs:
groupA:
registerHealthIndicator: true
slidingWindowSize: 200
resilience4j.timelimiter:
configs:
groupC:
timeoutDuration: 3s
cancelRunningFuture: true
----
====
[[instances-properties-configuration]]
=== Instances Properties Configuration
====
[source]
----
resilience4j.circuitbreaker:
instances:
backendA:
registerHealthIndicator: true
slidingWindowSize: 100
backendB:
registerHealthIndicator: true
slidingWindowSize: 10
permittedNumberOfCallsInHalfOpenState: 3
slidingWindowType: TIME_BASED
recordFailurePredicate: io.github.robwin.exception.RecordFailurePredicate
resilience4j.timelimiter:
instances:
backendA:
timeoutDuration: 2s
cancelRunningFuture: true
backendB:
timeoutDuration: 1s
cancelRunningFuture: false
----
====
* `ReactiveResilience4JCircuitBreakerFactory.create("backendA")` or `Resilience4JCircuitBreakerFactory.create("backendA")` will apply `instances backendA properties`
* `ReactiveResilience4JCircuitBreakerFactory.create("backendA", "groupA")` or `Resilience4JCircuitBreakerFactory.create("backendA", "groupA")` will apply `instances backendA properties`
* `ReactiveResilience4JCircuitBreakerFactory.create("backendC")` or `Resilience4JCircuitBreakerFactory.create("backendC")` will apply `global default properties`
* `ReactiveResilience4JCircuitBreakerFactory.create("backendC", "groupC")` or `Resilience4JCircuitBreakerFactory.create("backendC", "groupC")` will apply `global default CircuitBreaker properties and config groupC TimeLimiter properties`
For more information on Resilience4j property configuration, see https://resilience4j.readme.io/docs/getting-started-3#configuration[Resilience4J Spring Boot 2 Configuration].
[[bulkhead-pattern-supporting]]
== Bulkhead pattern supporting
If `resilience4j-bulkhead` is on the classpath, Spring Cloud CircuitBreaker will wrap all methods with a Resilience4j Bulkhead.
You can disable the Resilience4j Bulkhead by setting `spring.cloud.circuitbreaker.bulkhead.resilience4j.enabled` to `false`.
Spring Cloud CircuitBreaker Resilience4j provides two implementation of bulkhead pattern:
* a `SemaphoreBulkhead` which uses Semaphores
* a `FixedThreadPoolBulkhead` which uses a bounded queue and a fixed thread pool.
By default, Spring Cloud CircuitBreaker Resilience4j uses `FixedThreadPoolBulkhead`. To modify the default behavior to use `SemaphoreBulkhead` set the property `spring.cloud.circuitbreaker.resilience4j.enableSemaphoreDefaultBulkhead` to `true`.
For more information on implementation
of Bulkhead patterns see the https://resilience4j.readme.io/docs/bulkhead[Resilience4j Bulkhead].
The `Customizer<Resilience4jBulkheadProvider>` can be used to provide a default `Bulkhead` and `ThreadPoolBulkhead` configuration.
====
[source,java]
----
@Bean
public Customizer<Resilience4jBulkheadProvider> defaultBulkheadCustomizer() {
return provider -> provider.configureDefault(id -> new Resilience4jBulkheadConfigurationBuilder()
.bulkheadConfig(BulkheadConfig.custom().maxConcurrentCalls(4).build())
.threadPoolBulkheadConfig(ThreadPoolBulkheadConfig.custom().coreThreadPoolSize(1).maxThreadPoolSize(1).build())
.build()
);
}
----
====
[[specific-bulkhead-configuration]]
== Specific Bulkhead Configuration
Similarly to proving a default 'Bulkhead' or 'ThreadPoolBulkhead' configuration, you can create a `Customizer` bean this
is passed a `Resilience4jBulkheadProvider`.
====
[source,java]
----
@Bean
public Customizer<Resilience4jBulkheadProvider> slowBulkheadProviderCustomizer() {
return provider -> provider.configure(builder -> builder
.bulkheadConfig(BulkheadConfig.custom().maxConcurrentCalls(1).build())
.threadPoolBulkheadConfig(ThreadPoolBulkheadConfig.ofDefaults()), "slowBulkhead");
}
----
====
In addition to configuring the Bulkhead that is created you can also customize the bulkhead and thread pool bulkhead after they
have been created but before they are returned to caller. To do this you can use the `addBulkheadCustomizer` and `addThreadPoolBulkheadCustomizer`
methods.
[[bulkhead-example]]
=== Bulkhead Example
====
[source,java]
----
@Bean
public Customizer<Resilience4jBulkheadProvider> customizer() {
return provider -> provider.addBulkheadCustomizer(bulkhead -> bulkhead.getEventPublisher()
.onCallRejected(slowRejectedConsumer)
.onCallFinished(slowFinishedConsumer), "slowBulkhead");
}
----
====
[[thread-pool-bulkhead-example]]
=== Thread Pool Bulkhead Example
====
[source,java]
----
@Bean
public Customizer<Resilience4jBulkheadProvider> slowThreadPoolBulkheadCustomizer() {
return provider -> provider.addThreadPoolBulkheadCustomizer(threadPoolBulkhead -> threadPoolBulkhead.getEventPublisher()
.onCallRejected(slowThreadPoolRejectedConsumer)
.onCallFinished(slowThreadPoolFinishedConsumer), "slowThreadPoolBulkhead");
}
----
====
[[bulkhead-properties-configuration]]
== Bulkhead Properties Configuration
You can configure ThreadPoolBulkhead and SemaphoreBulkhead instances in your application's configuration properties file.
Property configuration has higher priority than Java `Customizer` configuration.
====
[source]
----
resilience4j.thread-pool-bulkhead:
instances:
backendA:
maxThreadPoolSize: 1
coreThreadPoolSize: 1
resilience4j.bulkhead:
instances:
backendB:
maxConcurrentCalls: 10
----
====
For more inforamtion on the Resilience4j property configuration, see https://resilience4j.readme.io/docs/getting-started-3#configuration[Resilience4J Spring Boot 2 Configuration].
[[collecting-metrics]]
== Collecting Metrics
Spring Cloud Circuit Breaker Resilience4j includes auto-configuration to setup metrics collection as long as the right
dependencies are on the classpath. To enable metric collection you must include `org.springframework.boot:spring-boot-starter-actuator`, and `io.github.resilience4j:resilience4j-micrometer`. For more information on the metrics that
get produced when these dependencies are present, see the https://resilience4j.readme.io/docs/micrometer[Resilience4j documentation].
NOTE: You don't have to include `micrometer-core` directly as it is brought in by `spring-boot-starter-actuator`

6
docs/modules/ROOT/pages/spring-cloud-circuitbreaker-resilience4j/auto-configuration.adoc Normal file
View File

@@ -0,0 +1,6 @@
[[auto-configuration]]
= Auto-Configuration
You can disable the Resilience4J auto-configuration by setting
`spring.cloud.circuitbreaker.resilience4j.enabled` to `false`.

32
docs/modules/ROOT/pages/spring-cloud-circuitbreaker-resilience4j/bulkhead-pattern-supporting.adoc Normal file
View File

@@ -0,0 +1,32 @@
[[bulkhead-pattern-supporting]]
= Bulkhead pattern supporting
If `resilience4j-bulkhead` is on the classpath, Spring Cloud CircuitBreaker will wrap all methods with a Resilience4j Bulkhead.
You can disable the Resilience4j Bulkhead by setting `spring.cloud.circuitbreaker.bulkhead.resilience4j.enabled` to `false`.
Spring Cloud CircuitBreaker Resilience4j provides two implementation of bulkhead pattern:
* a `SemaphoreBulkhead` which uses Semaphores
* a `FixedThreadPoolBulkhead` which uses a bounded queue and a fixed thread pool.
By default, Spring Cloud CircuitBreaker Resilience4j uses `FixedThreadPoolBulkhead`. To modify the default behavior to use `SemaphoreBulkhead` set the property `spring.cloud.circuitbreaker.resilience4j.enableSemaphoreDefaultBulkhead` to `true`.
For more information on implementation
of Bulkhead patterns see the https://resilience4j.readme.io/docs/bulkhead[Resilience4j Bulkhead].
The `Customizer<Resilience4jBulkheadProvider>` can be used to provide a default `Bulkhead` and `ThreadPoolBulkhead` configuration.
====
[source,java]
----
@Bean
public Customizer<Resilience4jBulkheadProvider> defaultBulkheadCustomizer() {
return provider -> provider.configureDefault(id -> new Resilience4jBulkheadConfigurationBuilder()
.bulkheadConfig(BulkheadConfig.custom().maxConcurrentCalls(4).build())
.threadPoolBulkheadConfig(ThreadPoolBulkheadConfig.custom().coreThreadPoolSize(1).maxThreadPoolSize(1).build())
.build()
);
}
----
====

23
docs/modules/ROOT/pages/spring-cloud-circuitbreaker-resilience4j/bulkhead-properties-configuration.adoc Normal file
View File

@@ -0,0 +1,23 @@
[[bulkhead-properties-configuration]]
= Bulkhead Properties Configuration
You can configure ThreadPoolBulkhead and SemaphoreBulkhead instances in your application's configuration properties file.
Property configuration has higher priority than Java `Customizer` configuration.
====
[source]
----
resilience4j.thread-pool-bulkhead:
instances:
backendA:
maxThreadPoolSize: 1
coreThreadPoolSize: 1
resilience4j.bulkhead:
instances:
backendB:
maxConcurrentCalls: 10
----
====
For more inforamtion on the Resilience4j property configuration, see https://resilience4j.readme.io/docs/getting-started-3#configuration[Resilience4J Spring Boot 2 Configuration].

94
docs/modules/ROOT/pages/spring-cloud-circuitbreaker-resilience4j/circuit-breaker-properties-configuration.adoc Normal file
View File

@@ -0,0 +1,94 @@
[[circuit-breaker-properties-configuration]]
= Circuit Breaker Properties Configuration
You can configure `CircuitBreaker` and `TimeLimiter` configs or instances in your application's configuration properties file.
Property configuration has higher priority than Java `Customizer` configuration.
Descending priority from top to bottom.
* Method(id) config - on specific method or operation
* Service(group) config - on specific application service or operations
* Global default config
====
[source,java]
----
ReactiveResilience4JCircuitBreakerFactory.create(String id, String groupName)
Resilience4JCircuitBreakerFactory.create(String id, String groupName)
----
====
[[global-default-properties-configuration]]
== Global Default Properties Configuration
====
[source]
----
resilience4j.circuitbreaker:
configs:
default:
registerHealthIndicator: true
slidingWindowSize: 50
resilience4j.timelimiter:
configs:
default:
timeoutDuration: 5s
cancelRunningFuture: true
----
====
[[configs-properties-configuration]]
== Configs Properties Configuration
====
[source]
----
resilience4j.circuitbreaker:
configs:
groupA:
registerHealthIndicator: true
slidingWindowSize: 200
resilience4j.timelimiter:
configs:
groupC:
timeoutDuration: 3s
cancelRunningFuture: true
----
====
[[instances-properties-configuration]]
== Instances Properties Configuration
====
[source]
----
resilience4j.circuitbreaker:
instances:
backendA:
registerHealthIndicator: true
slidingWindowSize: 100
backendB:
registerHealthIndicator: true
slidingWindowSize: 10
permittedNumberOfCallsInHalfOpenState: 3
slidingWindowType: TIME_BASED
recordFailurePredicate: io.github.robwin.exception.RecordFailurePredicate
resilience4j.timelimiter:
instances:
backendA:
timeoutDuration: 2s
cancelRunningFuture: true
backendB:
timeoutDuration: 1s
cancelRunningFuture: false
----
====
* `ReactiveResilience4JCircuitBreakerFactory.create("backendA")` or `Resilience4JCircuitBreakerFactory.create("backendA")` will apply `instances backendA properties`
* `ReactiveResilience4JCircuitBreakerFactory.create("backendA", "groupA")` or `Resilience4JCircuitBreakerFactory.create("backendA", "groupA")` will apply `instances backendA properties`
* `ReactiveResilience4JCircuitBreakerFactory.create("backendC")` or `Resilience4JCircuitBreakerFactory.create("backendC")` will apply `global default properties`
* `ReactiveResilience4JCircuitBreakerFactory.create("backendC", "groupC")` or `Resilience4JCircuitBreakerFactory.create("backendC", "groupC")` will apply `global default CircuitBreaker properties and config groupC TimeLimiter properties`
For more information on Resilience4j property configuration, see https://resilience4j.readme.io/docs/getting-started-3#configuration[Resilience4J Spring Boot 2 Configuration].

8
docs/modules/ROOT/pages/spring-cloud-circuitbreaker-resilience4j/collecting-metrics.adoc Normal file
View File

@@ -0,0 +1,8 @@
[[collecting-metrics]]
= Collecting Metrics
Spring Cloud Circuit Breaker Resilience4j includes auto-configuration to setup metrics collection as long as the right
dependencies are on the classpath. To enable metric collection you must include `org.springframework.boot:spring-boot-starter-actuator`, and `io.github.resilience4j:resilience4j-micrometer`. For more information on the metrics that
get produced when these dependencies are present, see the https://resilience4j.readme.io/docs/micrometer[Resilience4j documentation].
NOTE: You don't have to include `micrometer-core` directly as it is brought in by `spring-boot-starter-actuator`

55
docs/modules/ROOT/pages/spring-cloud-circuitbreaker-resilience4j/default-configuration.adoc Normal file
View File

@@ -0,0 +1,55 @@
[[default-configuration]]
= Default Configuration
To provide a default configuration for all of your circuit breakers create a `Customizer` bean that is passed a
`Resilience4JCircuitBreakerFactory` or `ReactiveResilience4JCircuitBreakerFactory`.
The `configureDefault` method can be used to provide a default configuration.
====
[source,java]
----
@Bean
public Customizer<Resilience4JCircuitBreakerFactory> defaultCustomizer() {
return factory -> factory.configureDefault(id -> new Resilience4JConfigBuilder(id)
.timeLimiterConfig(TimeLimiterConfig.custom().timeoutDuration(Duration.ofSeconds(4)).build())
.circuitBreakerConfig(CircuitBreakerConfig.ofDefaults())
.build());
}
----
====
[[reactive-example]]
== Reactive Example
====
[source,java]
----
@Bean
public Customizer<ReactiveResilience4JCircuitBreakerFactory> defaultCustomizer() {
return factory -> factory.configureDefault(id -> new Resilience4JConfigBuilder(id)
.circuitBreakerConfig(CircuitBreakerConfig.ofDefaults())
.timeLimiterConfig(TimeLimiterConfig.custom().timeoutDuration(Duration.ofSeconds(4)).build()).build());
}
----
====
[[customizing-the-executorservice]]
== Customizing The ExecutorService
If you would like to configure the `ExecutorService` which executes the circuit breaker you can do so using the `Resilience4JCircuitBreakerFactory`.
For example if you would like to use a context aware `ExecutorService` you could do the following.
====
[source,java]
----
@Bean
public Customizer<ReactiveResilience4JCircuitBreakerFactory> defaultCustomizer() {
return factory -> {
ContextAwareScheduledThreadPoolExecutor executor = ContextAwareScheduledThreadPoolExecutor.newScheduledThreadPool().corePoolSize(5)
.build();
factory.configureExecutorService(executor);
};
}
----
====

52
docs/modules/ROOT/pages/spring-cloud-circuitbreaker-resilience4j/specific-bulkhead-configuration.adoc Normal file
View File

@@ -0,0 +1,52 @@
[[specific-bulkhead-configuration]]
= Specific Bulkhead Configuration
Similarly to proving a default 'Bulkhead' or 'ThreadPoolBulkhead' configuration, you can create a `Customizer` bean this
is passed a `Resilience4jBulkheadProvider`.
====
[source,java]
----
@Bean
public Customizer<Resilience4jBulkheadProvider> slowBulkheadProviderCustomizer() {
return provider -> provider.configure(builder -> builder
.bulkheadConfig(BulkheadConfig.custom().maxConcurrentCalls(1).build())
.threadPoolBulkheadConfig(ThreadPoolBulkheadConfig.ofDefaults()), "slowBulkhead");
}
----
====
In addition to configuring the Bulkhead that is created you can also customize the bulkhead and thread pool bulkhead after they
have been created but before they are returned to caller. To do this you can use the `addBulkheadCustomizer` and `addThreadPoolBulkheadCustomizer`
methods.
[[bulkhead-example]]
== Bulkhead Example
====
[source,java]
----
@Bean
public Customizer<Resilience4jBulkheadProvider> customizer() {
return provider -> provider.addBulkheadCustomizer(bulkhead -> bulkhead.getEventPublisher()
.onCallRejected(slowRejectedConsumer)
.onCallFinished(slowFinishedConsumer), "slowBulkhead");
}
----
====
[[thread-pool-bulkhead-example]]
== Thread Pool Bulkhead Example
====
[source,java]
----
@Bean
public Customizer<Resilience4jBulkheadProvider> slowThreadPoolBulkheadCustomizer() {
return provider -> provider.addThreadPoolBulkheadCustomizer(threadPoolBulkhead -> threadPoolBulkhead.getEventPublisher()
.onCallRejected(slowThreadPoolRejectedConsumer)
.onCallFinished(slowThreadPoolFinishedConsumer), "slowThreadPoolBulkhead");
}
----
====

52
docs/modules/ROOT/pages/spring-cloud-circuitbreaker-resilience4j/specific-circuit-breaker-configuration.adoc Normal file
View File

@@ -0,0 +1,52 @@
[[specific-circuit-breaker-configuration]]
= Specific Circuit Breaker Configuration
Similarly to providing a default configuration, you can create a `Customizer` bean this is passed a
`Resilience4JCircuitBreakerFactory` or `ReactiveResilience4JCircuitBreakerFactory`.
====
[source,java]
----
@Bean
public Customizer<Resilience4JCircuitBreakerFactory> slowCustomizer() {
return factory -> factory.configure(builder -> builder.circuitBreakerConfig(CircuitBreakerConfig.ofDefaults())
.timeLimiterConfig(TimeLimiterConfig.custom().timeoutDuration(Duration.ofSeconds(2)).build()), "slow");
}
----
====
In addition to configuring the circuit breaker that is created you can also customize the circuit breaker after it has been created but before it is returned to the caller.
To do this you can use the `addCircuitBreakerCustomizer`
method.
This can be useful for adding event handlers to Resilience4J circuit breakers.
====
[source,java]
----
@Bean
public Customizer<Resilience4JCircuitBreakerFactory> slowCustomizer() {
return factory -> factory.addCircuitBreakerCustomizer(circuitBreaker -> circuitBreaker.getEventPublisher()
.onError(normalFluxErrorConsumer).onSuccess(normalFluxSuccessConsumer), "normalflux");
}
----
====
[[reactive-example]]
== Reactive Example
====
[source,java]
----
@Bean
public Customizer<ReactiveResilience4JCircuitBreakerFactory> slowCustomizer() {
return factory -> {
factory.configure(builder -> builder
.timeLimiterConfig(TimeLimiterConfig.custom().timeoutDuration(Duration.ofSeconds(2)).build())
.circuitBreakerConfig(CircuitBreakerConfig.ofDefaults()), "slow", "slowflux");
factory.addCircuitBreakerCustomizer(circuitBreaker -> circuitBreaker.getEventPublisher()
.onError(normalFluxErrorConsumer).onSuccess(normalFluxSuccessConsumer), "normalflux");
};
}
----
====

8
docs/modules/ROOT/pages/spring-cloud-circuitbreaker-resilience4j/starters.adoc Normal file
View File

@@ -0,0 +1,8 @@
[[starters]]
= Starters
There are two starters for the Resilience4J implementations, one for reactive applications and one for non-reactive applications.
* `org.springframework.cloud:spring-cloud-starter-circuitbreaker-resilience4j` - non-reactive applications
* `org.springframework.cloud:spring-cloud-starter-circuitbreaker-reactor-resilience4j` - reactive applications

64
docs/modules/ROOT/pages/spring-cloud-circuitbreaker-spring-retry.adoc
View File

@@ -10,67 +10,3 @@ All circuit breakers created using Spring Retry will be created using the `Circu
https://github.com/spring-projects/spring-retry/blob/master/src/main/java/org/springframework/retry/support/DefaultRetryState.java[`DefaultRetryState`].
Both of these classes can be configured using `SpringRetryConfigBuilder`.
[[default-configuration]]
== Default Configuration
To provide a default configuration for all of your circuit breakers create a `Customizer` bean that is passed a
`SpringRetryCircuitBreakerFactory`.
The `configureDefault` method can be used to provide a default configuration.
====
[source,java]
----
@Bean
public Customizer<SpringRetryCircuitBreakerFactory> defaultCustomizer() {
return factory -> factory.configureDefault(id -> new SpringRetryConfigBuilder(id)
.retryPolicy(new TimeoutRetryPolicy()).build());
}
----
====
[[specific-circuit-breaker-configuration]]
== Specific Circuit Breaker Configuration
Similarly to providing a default configuration, you can create a `Customizer` bean this is passed a
`SpringRetryCircuitBreakerFactory`.
====
[source,java]
----
@Bean
public Customizer<SpringRetryCircuitBreakerFactory> slowCustomizer() {
return factory -> factory.configure(builder -> builder.retryPolicy(new SimpleRetryPolicy(1)).build(), "slow");
}
----
====
In addition to configuring the circuit breaker that is created you can also customize the circuit breaker after it has been created but before it is returned to the caller.
To do this you can use the `addRetryTemplateCustomizers`
method.
This can be useful for adding event handlers to the `RetryTemplate`.
====
[source,java]
----
@Bean
public Customizer<SpringRetryCircuitBreakerFactory> slowCustomizer() {
return factory -> factory.addRetryTemplateCustomizers(retryTemplate -> retryTemplate.registerListener(new RetryListener() {
@Override
public <T, E extends Throwable> boolean open(RetryContext context, RetryCallback<T, E> callback) {
return false;
}
@Override
public <T, E extends Throwable> void close(RetryContext context, RetryCallback<T, E> callback, Throwable throwable) {
}
@Override
public <T, E extends Throwable> void onError(RetryContext context, RetryCallback<T, E> callback, Throwable throwable) {
}
}));
}
----
====

18
docs/modules/ROOT/pages/spring-cloud-circuitbreaker-spring-retry/default-configuration.adoc Normal file
View File

@@ -0,0 +1,18 @@
[[default-configuration]]
= Default Configuration
To provide a default configuration for all of your circuit breakers create a `Customizer` bean that is passed a
`SpringRetryCircuitBreakerFactory`.
The `configureDefault` method can be used to provide a default configuration.
====
[source,java]
----
@Bean
public Customizer<SpringRetryCircuitBreakerFactory> defaultCustomizer() {
return factory -> factory.configureDefault(id -> new SpringRetryConfigBuilder(id)
.retryPolicy(new TimeoutRetryPolicy()).build());
}
----
====

46
docs/modules/ROOT/pages/spring-cloud-circuitbreaker-spring-retry/specific-circuit-breaker-configuration.adoc Normal file
View File

@@ -0,0 +1,46 @@
[[specific-circuit-breaker-configuration]]
= Specific Circuit Breaker Configuration
Similarly to providing a default configuration, you can create a `Customizer` bean this is passed a
`SpringRetryCircuitBreakerFactory`.
====
[source,java]
----
@Bean
public Customizer<SpringRetryCircuitBreakerFactory> slowCustomizer() {
return factory -> factory.configure(builder -> builder.retryPolicy(new SimpleRetryPolicy(1)).build(), "slow");
}
----
====
In addition to configuring the circuit breaker that is created you can also customize the circuit breaker after it has been created but before it is returned to the caller.
To do this you can use the `addRetryTemplateCustomizers`
method.
This can be useful for adding event handlers to the `RetryTemplate`.
====
[source,java]
----
@Bean
public Customizer<SpringRetryCircuitBreakerFactory> slowCustomizer() {
return factory -> factory.addRetryTemplateCustomizers(retryTemplate -> retryTemplate.registerListener(new RetryListener() {
@Override
public <T, E extends Throwable> boolean open(RetryContext context, RetryCallback<T, E> callback) {
return false;
}
@Override
public <T, E extends Throwable> void close(RetryContext context, RetryCallback<T, E> callback, Throwable throwable) {
}
@Override
public <T, E extends Throwable> void onError(RetryContext context, RetryCallback<T, E> callback, Throwable throwable) {
}
}));
}
----
====