resilience4j | fault tolerance library designed for Java8 | HTTP library

Building an ARM-based image is not currently possible with mvn spring-boot:build-image, because the Cloud Native Buildpacks builders that Spring Boot integrates with do not support this. This is one of the possible items of focus on the Paketo buildpacks 2022 roadmap, which you can cast votes for.

CNB documents a work-around for this, but it's not simple to set up and run.

RUN mvn -f /home/path_to_app/pom.xml spring-boot:build-image -DskipTests

You would need Docker-in-Docker to make something like this work, since the CNB builder processes that would run inside the Docker container need to talk to the Docker daemon. Regardless, this would not allow you to build an ARM image for the reasons stated above.

The default Resilience4j aspect order is

This answer from the father of Resilience4j helped me:

In a production system you should not set minimumNumberOfCalls to 1. For testing it is okay, but 3 is better.

Let's assume you have minimumNumberOfCalls=3, slidingWindowSize = 10 and slidingWindowType = COUNT_BASED: That means the CircuitBreaker is calculating the failure rate and slow call rate based on the last 10 calls, as soon as 3 calls have been recorded.

Let's assume 2 calls are slow and 1 call is fast: That means the slow call rate is above 50% and the CircuitBreaker will transition to OPEN.

The minimumNumberOfCalls setting makes even more sense, if slidingWindowType = TIME_BASED and the failure rate is calculated based on the calls from the last N seconds.

As for the permittedNumberOfCallsInHalfOpenState question, after the wait-duration-in-open-state period is over, it goes into max-wait-duration-in-half-open-state and will allow a max of 5 calls. As long as the threshold is not met/exceeded, the circuit will close. It does not depend on the slidingWindowSize/minimumNumberOfCalls as per here.

The CircuitBreaker rejects calls with a CallNotPermittedException when it is OPEN. After a wait time duration has elapsed, the CircuitBreaker state changes from OPEN to HALF_OPEN and permits a configurable number of calls to see if the backend is still unavailable or has become available again. Further calls are rejected with a CallNotPermittedException, until all permitted calls have completed. If the failure rate or slow call rate is then equal or greater than the configured threshold, the state changes back to OPEN. If the failure rate and slow call rate is below the threshold, the state changes back to CLOSED.

P.S If you don't configure any property, the default value is used as per here.

When dealing with SpringBootTest and @CircuitBreaker, it was sufficient to add @EnableAspectJAutoProxy annotation to the test. After this change, the CircuitBreakerAspect was entertained and the test behaves as expected.

In order to make @TimeLimiter working as expected, one need to add @Bulkhead annotation to the method as well.

The updated method looks as follows:

Turned out that there is a chance to debug Invalid credentials error for OAuth2 approach. After a suggestion from https://stackoverflow.com/a/62917085/10596295, I debugged the application and realized that there is a problem with the property user-name-attribute. My final version of application.yml looks like this:

Following code worked,

I don't have an experience with Resilience4j but it looks like you're trying to use spring-aop here. This works with runtime generated proxy that wraps an original class providing additional functionality (Rate limiting in this case).

If so, you can't annotate the private method of the class because it won't be detected and processed by the proxy generation mechanism.

Instead consider creating another bean and expose its functionality as a public method:

You have a few options here but let me clarify why this happens. Feign is an HTTP binder for your APIs. In normal cases when you communicate backend-backend, the de-facto accepted HTTP status codes are 2xx to indicate that everything worked as expected. When an API reponds with a 3xx (302 in your case), that indicates a redirect which is usually used to instruct the browser to redirect the user to another page upon doing something.

Anyway, now that we've cleared why this could happen, let's see why your Feign client behaves this way. All Feign clients have a configuration parameter called follow-redirects. This controls whether upon receiving a 3xx HTTP response, the Feign client should automatically try to call the API specified in the response's Location header.

By default this parameter is set to true, meaning that redirects will be followed and it will be transparent for you, as a client user. From the exception, I think you somehow disabled it or you might use an HTTP client for which you disabled the redirect following manually.

Although I can clearly see from your implementation in the preguntarUsuarioExiste method that you're trying to decide whether a user exists in the system or not. In this case the 302 HTTP Found status doesn't make sense even though I understand why you'd want to use that (cause the term reflects that the user exists).

In this case, I'd simply remove the fixed 302 status with the @ResponseStatus annotation and change the API to return a ResponseEntity instead to resolve the status code dynamically. Something like this:

See https://kafka.apache.org/documentation/#consumerconfigs_retry.backoff.ms

The base amount of time to wait before attempting to reconnect to a given host. This avoids repeatedly connecting to a host in a tight loop. This backoff applies to all connection attempts by the client to a broker.

and https://kafka.apache.org/documentation/#consumerconfigs_reconnect.backoff.max.ms

The maximum amount of time in milliseconds to wait when reconnecting to a broker that has repeatedly failed to connect. If provided, the backoff per host will increase exponentially for each consecutive connection failure, up to this maximum. After calculating the backoff increase, 20% random jitter is added to avoid connection storms.

and