@Retry is a declarative MicroProfile Fault Tolerance annotation for repeating a failed method invocation before returning the failure. In Quarkus, the SmallRye Fault Tolerance extension supplies the implementation, keeping resilience behavior outside business logic. section 10.5
Use retry as one part of a broader fault-tolerance strategy:
- Retry failed operations for a configured number of attempts before propagating the failure. section 10.5
- Combine retry with fallback when eventual recovery is preferable but continued failure should produce an alternative result. section 10.5.1
- Apply the policy on the client side of a remote call, where the calling service must tolerate another service becoming unavailable. section 10.5.1
For the car-rental availability request, annotate the Reservation service method that calls Inventory. A configuration of maxRetries = 25 and delay = 1000 retries the method up to 25 times with a one-second delay between attempts. If every attempt fails, the request can wait up to 25 seconds before the failure reaches the client. section 10.5.1
$ quarkus extension add smallrye-fault-tolerance
Add the SmallRye Fault Tolerance extension to the Reservation service before using the annotation. section 10.5.1
@Retry(maxRetries = 25, delay = 1000)
Configure the availability method with 25 retries and a 1,000-millisecond delay between attempts. section 10.5.1
Availability during an Inventory outage
When Inventory is temporarily unavailable, Reservation re-executes its availability method instead of failing immediately. If Inventory remains down, retry eventually gives up; a separate fallback can return an empty car list rather than throw an exception. section 10.5.1
