{"id":13458752,"url":"https://github.com/spring-projects/spring-retry","last_synced_at":"2025-05-13T18:04:55.655Z","repository":{"id":1249064,"uuid":"1187608","full_name":"spring-projects/spring-retry","owner":"spring-projects","description":null,"archived":false,"fork":false,"pushed_at":"2025-04-15T08:26:22.000Z","size":1301,"stargazers_count":2219,"open_issues_count":29,"forks_count":525,"subscribers_count":104,"default_branch":"main","last_synced_at":"2025-05-06T17:13:45.902Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":"","language":"Java","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/spring-projects.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE-2.0.txt","code_of_conduct":"CODE_OF_CONDUCT.adoc","threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null}},"created_at":"2010-12-21T16:41:48.000Z","updated_at":"2025-05-06T01:38:09.000Z","dependencies_parsed_at":"2024-01-12T00:22:24.626Z","dependency_job_id":"9029e33e-c734-4d9b-88cf-9a61e4bfc3f8","html_url":"https://github.com/spring-projects/spring-retry","commit_stats":{"total_commits":468,"total_committers":87,"mean_commits":5.379310344827586,"dds":0.7414529914529915,"last_synced_commit":"72a0d0e2e3b4f8b2cfdf52ef5cc12b0c1bbb21ac"},"previous_names":[],"tags_count":42,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/spring-projects%2Fspring-retry","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/spring-projects%2Fspring-retry/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/spring-projects%2Fspring-retry/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/spring-projects%2Fspring-retry/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/spring-projects","download_url":"https://codeload.github.com/spring-projects/spring-retry/tar.gz/refs/heads/main","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":254000824,"owners_count":21997441,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-07-31T09:00:56.705Z","updated_at":"2025-05-13T18:04:55.634Z","avatar_url":"https://github.com/spring-projects.png","language":"Java","readme":"[![Build Status](https://github.com/spring-projects/spring-retry/actions/workflows/build-and-deploy-snapshot.yml/badge.svg?branch=main)](https://github.com/spring-projects/spring-retry/actions/workflows/build-and-deploy-snapshot.yml?query=branch%3Amain) [![Javadocs](https://www.javadoc.io/badge/org.springframework.retry/spring-retry.svg)](https://www.javadoc.io/doc/org.springframework.retry/spring-retry)\n[![Revved up by Develocity](https://img.shields.io/badge/Revved%20up%20by-Develocity-06A0CE?logo=Gradle\u0026labelColor=02303A)](https://ge.spring.io/scans?search.rootProjectNames=Spring%20Retry)\n\nThis project provides declarative retry support for Spring applications. \nIt is used in Spring Batch, Spring Integration, and others.\nImperative retry is also supported for explicit usage.\n\nThe Maven artifact for this library is:\n\n```xml\n\u003cdependency\u003e\n    \u003cgroupId\u003eorg.springframework.retry\u003c/groupId\u003e\n    \u003cartifactId\u003espring-retry\u003c/artifactId\u003e\n\u003c/dependency\u003e\n```\n\n## Quick Start\n\nThis section provides a quick introduction to getting started with Spring Retry.\nIt includes a declarative example and an imperative example.\n\n### Declarative Example\n\nThe following example shows how to use Spring Retry in its declarative style:\n\n```java\n@Configuration\n@EnableRetry\npublic class Application {\n\n}\n\n@Service\nclass Service {\n    @Retryable(retryFor = RemoteAccessException.class)\n    public void service() {\n        // ... do something\n    }\n    @Recover\n    public void recover(RemoteAccessException e) {\n       // ... panic\n    }\n}\n```\n\nThis example calls the `service` method and, if it fails with a `RemoteAccessException`, retries\n(by default, up to three times), and then tries the `recover` method if unsuccessful.\nThere are various options in the `@Retryable` annotation attributes for including and\nexcluding exception types, limiting the number of retries, and setting the policy for backoff.\n\nThe declarative approach to applying retry handling by using the `@Retryable` annotation shown earlier has an additional\nruntime dependency on AOP classes. For details on how to resolve this dependency in your project, see the\n['Java Configuration for Retry Proxies'](#javaConfigForRetryProxies) section.\n\n### Imperative Example\n\nThe following example shows how to use Spring Retry in its imperative style (available since version 1.3):\n\n```java\nRetryTemplate template = RetryTemplate.builder()\n\t\t\t\t.maxAttempts(3)\n\t\t\t\t.fixedBackoff(1000)\n\t\t\t\t.retryOn(RemoteAccessException.class)\n\t\t\t\t.build();\n\ntemplate.execute(ctx -\u003e {\n    // ... do something\n});\n```\n\nFor versions prior to 1.3,\nsee the examples in the [RetryTemplate](#using-retrytemplate) section.\n\n## Building\n\nSpring Retry requires Java 17 and Maven 3.0.5 (or greater).\nTo build, run the following Maven command:\n\n```\n$ mvn install\n```\n\n## Features and API\n\nThis section discusses the features of Spring Retry and shows how to use its API.\n\n### Using `RetryTemplate`\n\nTo make processing more robust and less prone to failure, it sometimes helps to\nautomatically retry a failed operation, in case it might succeed on a subsequent attempt.\nErrors that are susceptible to this kind of treatment are transient in nature. For\nexample, a remote call to a web service or an RMI service that fails because of a network\nglitch or a `DeadLockLoserException` in a database update may resolve itself after a\nshort wait. To automate the retry of such operations, Spring Retry has the\n`RetryOperations` strategy. The `RetryOperations` interface definition follows:\n\n```java\npublic interface RetryOperations {\n\n\t\u003cT, E extends Throwable\u003e T execute(RetryCallback\u003cT, E\u003e retryCallback) throws E;\n\n\t\u003cT, E extends Throwable\u003e T execute(RetryCallback\u003cT, E\u003e retryCallback, RecoveryCallback\u003cT\u003e recoveryCallback) throws E;\n\n\t\u003cT, E extends Throwable\u003e T execute(RetryCallback\u003cT, E\u003e retryCallback, RetryState retryState) throws E, ExhaustedRetryException;\n\n\t\u003cT, E extends Throwable\u003e T execute(RetryCallback\u003cT, E\u003e retryCallback, RecoveryCallback\u003cT\u003e recoveryCallback, RetryState retryState) throws E;\n\n}\n```\n\nThe basic callback is a simple interface that lets you insert some business logic to be retried:\n\n```java\npublic interface RetryCallback\u003cT, E extends Throwable\u003e {\n\n    T doWithRetry(RetryContext context) throws E;\n\n}\n```\n\nThe callback is tried, and, if it fails (by throwing an `Exception`), it is retried\nuntil either it is successful or the implementation decides to abort. There are a number\nof overloaded `execute` methods in the `RetryOperations` interface, to deal with various\nuse cases for recovery when all retry attempts are exhausted and to deal with retry state, which\nlets clients and implementations store information between calls (more on this later).\n\nThe simplest general purpose implementation of `RetryOperations` is `RetryTemplate`.\nThe following example shows how to use it:\n\n```java\nRetryTemplate template = new RetryTemplate();\n\nTimeoutRetryPolicy policy = new TimeoutRetryPolicy();\npolicy.setTimeout(30000L);\n\ntemplate.setRetryPolicy(policy);\n\nMyObject result = template.execute(new RetryCallback\u003cMyObject, Exception\u003e() {\n\n    public MyObject doWithRetry(RetryContext context) {\n        // Do stuff that might fail, e.g. webservice operation\n        return result;\n    }\n\n});\n```\n\nIn the preceding example, we execute a web service call and return the result to the user.\nIf that call fails, it is retried until a timeout is reached.\n\nSince version 1.3, fluent configuration of `RetryTemplate` is also available, as follows:\n\n```java\nRetryTemplate.builder()\n      .maxAttempts(10)\n      .exponentialBackoff(100, 2, 10000)\n      .retryOn(IOException.class)\n      .traversingCauses()\n      .build();\n\nRetryTemplate.builder()\n      .fixedBackoff(10)\n      .withinMillis(3000)\n      .build();\n\nRetryTemplate.builder()\n      .infiniteRetry()\n      .retryOn(IOException.class)\n      .uniformRandomBackoff(1000, 3000)\n      .build();\n```\n\n### Using `RetryContext`\n\nThe method parameter for the `RetryCallback` is a `RetryContext`.\nMany callbacks ignore the context.\nHowever, if necessary, you can use it as an attribute bag to store data for the duration of the iteration.\nIt also has some useful properties, such as `retryCount`.\n\nA `RetryContext` has a parent context if there is a nested retry in progress in the same thread.\nThe parent context is occasionally useful for storing data that needs to be shared between calls to execute.\n\nIf you don't have access to the context directly, you can obtain the current context within the scope of the retries by calling `RetrySynchronizationManager.getContext()`.\nBy default, the context is stored in a `ThreadLocal`.\nJEP 444 recommends that `ThreadLocal` should be avoided when using virtual threads, available in Java 21 and beyond.\nTo store the contexts in a `Map` instead of a `ThreadLocal`, call `RetrySynchronizationManager.setUseThreadLocal(false)`.\n\nAlso, the `RetryOperationsInterceptor` exposes `RetryOperationsInterceptor.METHOD` and `RetryOperationsInterceptor.METHOD_ARGS` attributes with `MethodInvocation.getMethod()` and `new Args(invocation.getArguments())` values, respectively, into the `RetryContext`.\n\n### Using `RecoveryCallback`\n\nWhen a retry is exhausted, the `RetryOperations` can pass control to a different\ncallback: `RecoveryCallback`. To use this feature, clients can pass in the callbacks\ntogether to the same method, as the following example shows:\n\n```\nMyObject myObject = template.execute(new RetryCallback\u003cMyObject, Exception\u003e() {\n    public MyObject doWithRetry(RetryContext context) {\n        // business logic here\n    },\n  new RecoveryCallback\u003cMyObject\u003e() {\n    MyObject recover(RetryContext context) throws Exception {\n          // recover logic here\n    }\n});\n```\n\nIf the business logic does not succeed before the template decides to abort, the client is\ngiven the chance to do some alternate processing through the recovery callback.\n\n## Stateless Retry\n\nIn the simplest case, a retry is just a while loop: the `RetryTemplate` can keep trying\nuntil it either succeeds or fails. The `RetryContext` contains some state to determine\nwhether to retry or abort. However, this state is on the stack, and there is no need to\nstore it anywhere globally. Consequently, we call this \"stateless retry\". The distinction\nbetween stateless and stateful retry is contained in the implementation of `RetryPolicy`\n(`RetryTemplate` can handle both). In a stateless retry, the callback is always executed\nin the same thread as when it failed on retry.\n\n## Stateful Retry\n\nWhere the failure has caused a transactional resource to become invalid, there are some\nspecial considerations. This does not apply to a simple remote call, because there is (usually) no\ntransactional resource, but it does sometimes apply to a database update,\nespecially when using Hibernate. In this case, it only makes sense to rethrow the\nexception that called the failure immediately so that the transaction can roll back and\nwe can start a new (and valid) one.\n\nIn these cases, a stateless retry is not good enough, because the re-throw and roll back\nnecessarily involve leaving the `RetryOperations.execute()` method and potentially losing\nthe context that was on the stack. To avoid losing the context, we have to introduce a\nstorage strategy to lift it off the stack and put it (at a minimum) in heap storage. For\nthis purpose, Spring Retry provides a storage strategy called `RetryContextCache`, which\nyou can inject into the `RetryTemplate`. The default implementation of the\n`RetryContextCache` is in-memory, using a simple `Map`. It has a strictly enforced maximum\ncapacity, to avoid memory leaks, but it does not have any advanced cache features (such as\ntime to live). You should consider injecting a `Map` that has those features if you need\nthem. For advanced usage with multiple processes in a clustered environment, you might\nalso consider implementing the `RetryContextCache` with a cluster cache of some sort\n(though, even in a clustered environment, this might be overkill).\n\nPart of the responsibility of the `RetryOperations` is to recognize the failed operations\nwhen they come back in a new execution (and usually wrapped in a new transaction). To\nfacilitate this, Spring Retry provides the `RetryState` abstraction. This works in\nconjunction with special `execute` methods in the `RetryOperations`.\n\nThe failed operations are recognized by identifying the state across multiple invocations\nof the retry. To identify the state, you can provide a `RetryState` object that is\nresponsible for returning a unique key that identifies the item. The identifier is used as\na key in the `RetryContextCache`.\n\n\u003e *Warning:*\nBe very careful with the implementation of `Object.equals()` and `Object.hashCode()` in\nthe key returned by `RetryState`. The best advice is to use a business key to identify the\nitems. In the case of a JMS message, you can use the message ID.\n\nWhen the retry is exhausted, you also have the option to handle the failed item in a\ndifferent way, instead of calling the `RetryCallback` (which is now presumed to be likely\nto fail). As in the stateless case, this option is provided by the `RecoveryCallback`,\nwhich you can provide by passing it in to the `execute` method of `RetryOperations`.\n\nThe decision to retry or not is actually delegated to a regular `RetryPolicy`, so the\nusual concerns about limits and timeouts can be injected there (see the [Additional Dependencies](#Additional_Dependencies) section).\n\n## Retry Policies\n\nInside a `RetryTemplate`, the decision to retry or fail in the `execute` method is\ndetermined by a `RetryPolicy`, which is also a factory for the `RetryContext`. The\n`RetryTemplate` is responsible for using the current policy to create a `RetryContext` and\npassing that in to the `RetryCallback` at every attempt. After a callback fails, the\n`RetryTemplate` has to make a call to the `RetryPolicy` to ask it to update its state\n(which is stored in `RetryContext`). It then asks the policy if another attempt can be\nmade. If another attempt cannot be made (for example, because a limit has been reached or\na timeout has been detected), the policy is also responsible for identifying the\nexhausted state -- but not for handling the exception. `RetryTemplate` throws the\noriginal exception, except in the stateful case, when no recovery is available. In that\ncase, it throws `RetryExhaustedException`. You can also set a flag in the\n`RetryTemplate` to have it unconditionally throw the original exception from the\ncallback (that is, from user code) instead.\n\n\u003e *Tip:*\nFailures are inherently either retryable or not -- if the same exception is always going\nto be thrown from the business logic, it does not help to retry it. So you should not\nretry on all exception types. Rather, try to focus on only those exceptions that you\nexpect to be retryable. It is not usually harmful to the business logic to retry more\naggressively, but it is wasteful, because, if a failure is deterministic, time is spent\nretrying something that you know in advance is fatal.\n\nSpring Retry provides some simple general-purpose implementations of stateless\n`RetryPolicy` (for example, a `SimpleRetryPolicy`) and the `TimeoutRetryPolicy` used in\nthe preceding example.\n\nThe `SimpleRetryPolicy` allows a retry on any of a named list of exception types, up to a\nfixed number of times. The following example shows how to use it:\n\n```java\n// Set the max attempts including the initial attempt before retrying\n// and retry on all exceptions (this is the default):\nSimpleRetryPolicy policy = new SimpleRetryPolicy(5, Collections.singletonMap(Exception.class, true));\n\n// Use the policy...\nRetryTemplate template = new RetryTemplate();\ntemplate.setRetryPolicy(policy);\ntemplate.execute(new RetryCallback\u003cMyObject, Exception\u003e() {\n    public MyObject doWithRetry(RetryContext context) {\n        // business logic here\n    }\n});\n```\n\nA more flexible implementation called `ExceptionClassifierRetryPolicy` is also available.\nIt lets you configure different retry behavior for an arbitrary set of exception types\nthrough the `ExceptionClassifier` abstraction. The policy works by calling on the\nclassifier to convert an exception into a delegate `RetryPolicy`. For example, one\nexception type can be retried more times before failure than another, by mapping it to a\ndifferent policy.\n\nYou might need to implement your own retry policies for more customized decisions. For\ninstance, if there is a well-known, solution-specific, classification of exceptions into\nretryable and not retryable.\n\n## Backoff Policies\n\nWhen retrying after a transient failure, it often helps to wait a bit before trying again,\nbecause (usually) the failure is caused by some problem that can be resolved only by\nwaiting. If a `RetryCallback` fails, the `RetryTemplate` can pause execution according to\nthe `BackoffPolicy`. The following listing shows the definition of the `BackoffPolicy`\ninterface:\n\n```java\npublic interface BackoffPolicy {\n\n    BackOffContext start(RetryContext context);\n\n    void backOff(BackOffContext backOffContext)\n        throws BackOffInterruptedException;\n\n}\n```\n\nA `BackoffPolicy` is free to implement the backoff in any way it chooses. The policies\nprovided by Spring Retry all use `Object.wait()`. A common use case is to\nback off with an exponentially increasing wait period, to avoid two retries getting into\nlock step and both failing (a lesson learned from Ethernet). For this purpose, Spring\nRetry provides `ExponentialBackoffPolicy`. Spring Retry also provides randomized versions\nof delay policies that are quite useful to avoid resonating between related failures in a\ncomplex system, by adding jitter.\n\n## Listeners\n\nIt is often useful to be able to receive additional callbacks for cross-cutting concerns across a number of different retries. \nFor this purpose, Spring Retry provides the `RetryListener` interface. \nThe `RetryTemplate` lets you register `RetryListener` instances, and they are given callbacks with the `RetryContext` and `Throwable` (where available during the iteration).\n\nThe following listing shows the `RetryListener` interface:\n\n```java\npublic interface RetryListener {\n\n\tdefault \u003cT, E extends Throwable\u003e boolean open(RetryContext context, RetryCallback\u003cT, E\u003e callback) {\n\t\treturn true;\n\t}\n\n\tdefault \u003cT, E extends Throwable\u003e void onSuccess(RetryContext context, RetryCallback\u003cT, E\u003e callback, T result) {\n\t}\n\n\tdefault \u003cT, E extends Throwable\u003e void onError(RetryContext context, RetryCallback\u003cT, E\u003e callback,\n\t\t\tThrowable throwable) {\n\t}\n\n\tdefault \u003cT, E extends Throwable\u003e void close(RetryContext context, RetryCallback\u003cT, E\u003e callback,\n\t\t\tThrowable throwable) {\n\t}\n\n}\n```\n\nThe `open` and `close` callbacks come before and after the entire retry in the simplest case, and `onSuccess`, `onError` apply to the individual `RetryCallback` calls; the current retry count can be obtained from the `RetryContext`.\nThe close method might also receive a `Throwable`.\nStarting with version 2.0, the `onSuccess` method is called after a successful call to the callback.\nThis allows the listener to examine the result and throw an exception if the result doesn't match some expected criteria.\nThe type of the exception thrown is then used to determine whether the call should be retried or not, based on the retry policy.\nIf there has been an error, it is the last one thrown by the `RetryCallback`.\n\nNote that when there is more than one listener, they are in a list, so there is an order.\nIn this case, `open` is called in the same order, while `onSuccess`, `onError`, and `close` are called in reverse order.\n\n### Listeners for Reflective Method Invocations\n\nWhen dealing with methods that are annotated with `@Retryable` or with Spring AOP intercepted methods, Spring Retry allows a detailed inspection of the method invocation within the `RetryListener` implementation.\n\nSuch a scenario could be particularly useful when there is a need to monitor how often a certain method call has been retried and expose it with detailed tagging information (such as class name, method name, or even parameter values in some exotic cases).\n\nStarting with version 2.0, the `MethodInvocationRetryListenerSupport` has a new method `doOnSuccess`.\n\nThe following example registers such a listener:\n\n```java\n\ntemplate.registerListener(new MethodInvocationRetryListenerSupport() {\n      @Override\n      protected \u003cT, E extends Throwable\u003e void doClose(RetryContext context,\n          MethodInvocationRetryCallback\u003cT, E\u003e callback, Throwable throwable) {\n        monitoringTags.put(labelTagName, callback.getLabel());\n        Method method = callback.getInvocation()\n            .getMethod();\n        monitoringTags.put(classTagName,\n            method.getDeclaringClass().getSimpleName());\n        monitoringTags.put(methodTagName, method.getName());\n\n        // register a monitoring counter with appropriate tags\n        // ...\n\n        @Override\n        protected \u003cT, E extends Throwable\u003e void doOnSuccess(RetryContext context,\n                MethodInvocationRetryCallback\u003cT, E\u003e callback, T result) {\n\n            Object[] arguments = callback.getInvocation().getArguments();\n\n            // decide whether the result for the given arguments should be accepted\n            // or retried according to the retry policy\n        }\n\n      }\n    });\n```\n\n## Declarative Retry\n\nSometimes, you want to retry some business processing every time it happens. The classic\nexample of this is the remote service call. Spring Retry provides an AOP interceptor that\nwraps a method call in a `RetryOperations` instance for exactly this purpose. The\n`RetryOperationsInterceptor` executes the intercepted method and retries on failure\naccording to the `RetryPolicy` in the provided `RepeatTemplate`.\n\n\n### \u003ca name=\"javaConfigForRetryProxies\"\u003e\u003c/a\u003e Java Configuration for Retry Proxies\n\nYou can add the `@EnableRetry` annotation to one of your `@Configuration` classes and use\n`@Retryable` on the methods (or on the type level for all methods) that you want to retry.\nYou can also specify any number of retry listeners. The following example shows how to do\nso:\n\n```java\n@Configuration\n@EnableRetry\npublic class Application {\n\n    @Bean\n    public Service service() {\n        return new Service();\n    }\n\n    @Bean public RetryListener retryListener1() {\n        return new RetryListener() {...}\n    }\n\n    @Bean public RetryListener retryListener2() {\n        return new RetryListener() {...}\n    }\n\n}\n\n@Service\nclass Service {\n    @Retryable(RemoteAccessException.class)\n    public service() {\n        // ... do something\n    }\n}\n```\n\nYou can use the attributes of `@Retryable` to control the `RetryPolicy` and `BackoffPolicy`, as follows:\n\n```java\n@Service\nclass Service {\n    @Retryable(maxAttempts=12, backoff=@Backoff(delay=100, maxDelay=500))\n    public service() {\n        // ... do something\n    }\n}\n```\n\nThe preceding example creates a random backoff between 100 and 500 milliseconds and up to\n12 attempts. There is also a `stateful` attribute (default: `false`) to control whether\nthe retry is stateful or not. To use stateful retry, the intercepted method has to have\narguments, since they are used to construct the cache key for the state.\n\nThe `@EnableRetry` annotation also looks for beans of type `Sleeper` and other strategies\nused in the `RetryTemplate` and interceptors to control the behavior of the retry at runtime.\n\nThe `@EnableRetry` annotation creates proxies for `@Retryable` beans, and the proxies\n(that is, the bean instances in the application) have the `Retryable` interface added to\nthem. This is purely a marker interface, but it might be useful for other tools looking to\napply retry advice (they should usually not bother if the bean already implements\n`Retryable`).\n\nIf you want to take an alternative code path when\nthe retry is exhausted, you can supply a recovery method. Methods should be declared in the same class as the `@Retryable`\ninstance and marked `@Recover`. The return type must match the `@Retryable` method. The arguments\nfor the recovery method can optionally include the exception that was thrown and\n(optionally) the arguments passed to the original retryable method (or a partial list of\nthem as long as none are omitted up to the last one needed). The following example shows how to do so:\n\n```java\n@Service\nclass Service {\n    @Retryable(retryFor = RemoteAccessException.class)\n    public void service(String str1, String str2) {\n        // ... do something\n    }\n    @Recover\n    public void recover(RemoteAccessException e, String str1, String str2) {\n       // ... error handling making use of original args if required\n    }\n}\n```\n\nTo resolve conflicts between multiple methods that can be picked for recovery, you can explicitly specify recovery method name.\nThe following example shows how to do so:\n\n```java\n@Service\nclass Service {\n    @Retryable(recover = \"service1Recover\", retryFor = RemoteAccessException.class)\n    public void service1(String str1, String str2) {\n        // ... do something\n    }\n\n    @Retryable(recover = \"service2Recover\", retryFor = RemoteAccessException.class)\n    public void service2(String str1, String str2) {\n        // ... do something\n    }\n\n    @Recover\n    public void service1Recover(RemoteAccessException e, String str1, String str2) {\n        // ... error handling making use of original args if required\n    }\n\n    @Recover\n    public void service2Recover(RemoteAccessException e, String str1, String str2) {\n        // ... error handling making use of original args if required\n    }\n}\n```\n\nVersion 1.3.2 and later supports matching a parameterized (generic) return type to detect the correct recovery method:\n\n```java\n@Service\nclass Service {\n\n    @Retryable(retryFor = RemoteAccessException.class)\n    public List\u003cThing1\u003e service1(String str1, String str2) {\n        // ... do something\n    }\n\n    @Retryable(retryFor = RemoteAccessException.class)\n    public List\u003cThing2\u003e service2(String str1, String str2) {\n        // ... do something\n    }\n\n    @Recover\n    public List\u003cThing1\u003e recover1(RemoteAccessException e, String str1, String str2) {\n       // ... error handling for service1\n    }\n\n    @Recover\n    public List\u003cThing2\u003e recover2(RemoteAccessException e, String str1, String str2) {\n       // ... error handling for service2\n    }\n\n}\n```\n\nVersion 1.2 introduced the ability to use expressions for certain properties. \nThe following example show how to use expressions this way:\n\n```java\n\n@Retryable(exceptionExpression=\"message.contains('this can be retried')\")\npublic void service1() {\n  ...\n}\n\n@Retryable(exceptionExpression=\"message.contains('this can be retried')\")\npublic void service2() {\n  ...\n}\n\n@Retryable(exceptionExpression=\"@exceptionChecker.shouldRetry(#root)\",\n    maxAttemptsExpression = \"#{@integerFiveBean}\",\n  backoff = @Backoff(delayExpression = \"#{1}\", maxDelayExpression = \"#{5}\", multiplierExpression = \"#{1.1}\"))\npublic void service3() {\n  ...\n}\n```\n\nSince Spring Retry 1.2.5, for `exceptionExpression`, templated expressions (`#{...}`) are deprecated in favor of simple expression strings (`message.contains('this can be retried')`).\n\nExpressions can contain property placeholders, such as `#{${max.delay}}` or `#{@exceptionChecker.${retry.method}(#root)}`. The following rules apply:\n\n- `exceptionExpression` is evaluated against the thrown exception as the `#root` object.\n- `maxAttemptsExpression` and the `@BackOff` expression attributes are evaluated once, during initialization. There is no root object for the evaluation, but they can reference other beans in the context\n\nStarting with version 2.0, expressions in `@Retryable`, `@CircuitBreaker`, and `BackOff` can be evaluated once, during application initialization, or at runtime.\nWith earlier versions, evaluation was always performed during initialization (except for `Retryable.exceptionExpression` which is always evaluated at runtime).\nWhen evaluating at runtime, a root object containing the method arguments is passed to the evaluation context.\n\n**Note:** The arguments are not available until the method has been called at least once; they will be null initially, which means, for example, you can't set the initial `maxAttempts` using an argument value, you can, however, change the `maxAttempts` after the first failure and before any retries are performed.\nAlso, the arguments are only available when using stateless retry (which includes the `@CircuitBreaker`).\n\nVersion 2.0 adds more flexibility to exception classification.\n\n```java\n@Retryable(retryFor = RuntimeException.class, noRetryFor = IllegalStateException.class, notRecoverable = {\n        IllegalArgumentException.class, IllegalStateException.class })\npublic void service() {\n    ...\n}\n\n@Recover\npublic void recover(Throwable cause) {\n    ...\n}\n```\n\n`retryFor` and `noRetryFor` are replacements of `include` and `exclude` properties, which are now deprecated.\nThe new `notRecoverable` property allows the recovery method(s) to be skipped, even if one matches the exception type; the exception is thrown to the caller either after retries are exhausted, or immediately, if the exception is not retryable.\n\n##### Examples\n\n```java\n@Retryable(maxAttemptsExpression = \"@runtimeConfigs.maxAttempts\",\n        backoff = @Backoff(delayExpression = \"@runtimeConfigs.initial\",\n                maxDelayExpression = \"@runtimeConfigs.max\", multiplierExpression = \"@runtimeConfigs.mult\"))\npublic void service() {\n    ...\n}\n```\n\nWhere `runtimeConfigs` is a bean with those properties.\n\n```java\n@Retryable(maxAttemptsExpression = \"args[0] == 'something' ? 3 : 1\")\npublic void conditional(String string) {\n    ...\n}\n```\n\n#### \u003ca name=\"Additional_Dependencies\"\u003e\u003c/a\u003e Additional Dependencies\n\nThe declarative approach to applying retry handling by using the `@Retryable` annotation\nshown earlier has an additional runtime dependency on AOP classes that need to be declared\nin your project. If your application is implemented by using Spring Boot, this dependency\nis best resolved by using the Spring Boot starter for AOP. For example, for Gradle, add\nthe following line to your `build.gradle` file:\n\n```\n    runtimeOnly 'org.springframework.boot:spring-boot-starter-aop'\n```\n\nFor non-Boot apps, you need to declare a runtime dependency on the latest version of\nAspectJ's `aspectjweaver` module. For example, for Gradle, you should add the following\nline  to your `build.gradle` file:\n\n```\n    runtimeOnly 'org.aspectj:aspectjweaver:1.9.20.1'\n```\n### Further customizations\n\nStarting from version 1.3.2 and later `@Retryable` annotation can be used in custom composed annotations to create your own annotations with predefined behaviour.\nFor example if you discover you need two kinds of retry strategy, one for local services calls, and one for remote services calls, you could decide\nto create two custom annotations `@LocalRetryable` and `@RemoteRetryable` that differs in the retry strategy as well in the maximum number of retries.\n\nTo make custom annotation composition work properly you can use `@AliasFor` annotation, for example on the `recover` method, so that you can further extend the versatility of your custom annotations and allow the `recover` argument value\nto be picked up as if it was set on the `recover` method of the base `@Retryable` annotation.\n\nUsage Example:\n```java\n@Service\nclass Service {\n    ...\n    \n    @LocalRetryable(include = TemporaryLocalException.class, recover = \"service1Recovery\")\n    public List\u003cThing\u003e service1(String str1, String str2){\n        //... do something\n    }\n    \n    public List\u003cThing\u003e service1Recovery(TemporaryLocalException ex,String str1, String str2){\n        //... Error handling for service1\n    }\n    ...\n    \n    @RemoteRetryable(include = TemporaryRemoteException.class, recover = \"service2Recovery\")\n    public List\u003cThing\u003e service2(String str1, String str2){\n        //... do something\n    }\n\n    public List\u003cThing\u003e service2Recovery(TemporaryRemoteException ex, String str1, String str2){\n        //... Error handling for service2\n    }\n    ...\n}\n```\n\n```java\n@Target({ ElementType.METHOD, ElementType.TYPE })\n@Retention(RetentionPolicy.RUNTIME)\n@Retryable(maxAttempts = \"3\", backoff = @Backoff(delay = \"500\", maxDelay = \"2000\", random = true)\n)\npublic @interface LocalRetryable {\n    \n    @AliasFor(annotation = Retryable.class, attribute = \"recover\")\n    String recover() default \"\";\n\n    @AliasFor(annotation = Retryable.class, attribute = \"value\")\n    Class\u003c? extends Throwable\u003e[] value() default {};\n\n    @AliasFor(annotation = Retryable.class, attribute = \"include\")\n\n    Class\u003c? extends Throwable\u003e[] include() default {};\n\n    @AliasFor(annotation = Retryable.class, attribute = \"exclude\")\n    Class\u003c? extends Throwable\u003e[] exclude() default {};\n\n    @AliasFor(annotation = Retryable.class, attribute = \"label\")\n    String label() default \"\";\n\n}\n```\n\n```java\n@Target({ ElementType.METHOD, ElementType.TYPE })\n@Retention(RetentionPolicy.RUNTIME)\n@Documented\n@Retryable(maxAttempts = \"5\", backoff = @Backoff(delay = \"1000\", maxDelay = \"30000\", multiplier = \"1.2\", random = true)\n)\npublic @interface RemoteRetryable {\n    \n    @AliasFor(annotation = Retryable.class, attribute = \"recover\")\n    String recover() default \"\";\n\n    @AliasFor(annotation = Retryable.class, attribute = \"value\")\n    Class\u003c? extends Throwable\u003e[] value() default {};\n\n    @AliasFor(annotation = Retryable.class, attribute = \"include\")\n    Class\u003c? extends Throwable\u003e[] include() default {};\n\n    @AliasFor(annotation = Retryable.class, attribute = \"exclude\")\n    Class\u003c? extends Throwable\u003e[] exclude() default {};\n\n    @AliasFor(annotation = Retryable.class, attribute = \"label\")\n    String label() default \"\";\n\n}\n```\n\n### XML Configuration\n\nThe following example of declarative iteration uses Spring AOP to repeat a service call to\na method called `remoteCall`:\n\n```xml\n\u003caop:config\u003e\n    \u003caop:pointcut id=\"transactional\"\n        expression=\"execution(* com..*Service.remoteCall(..))\" /\u003e\n    \u003caop:advisor pointcut-ref=\"transactional\"\n        advice-ref=\"retryAdvice\" order=\"-1\"/\u003e\n\u003c/aop:config\u003e\n\n\u003cbean id=\"retryAdvice\"\n    class=\"org.springframework.retry.interceptor.RetryOperationsInterceptor\"/\u003e\n```\n\nFor more detail on how to configure AOP interceptors, see the [Spring Framework Documentation](https://docs.spring.io/spring/docs/current/spring-framework-reference/index.html).\n\nThe preceding example uses a default `RetryTemplate` inside the interceptor. To change the\npolicies or listeners, you need only inject an instance of `RetryTemplate` into the\ninterceptor.\n\n## Micrometer Support\n\nStarting with version 2.0.8, the `MetricsRetryListener` implementation is provided to be injected into a `RetryTemplate` or referenced via `@Retryable(listeners)` attribute.\nThis `MetricsRetryListener` is based on the [Micrometer](https://docs.micrometer.io/micrometer/reference/index.html) `MeterRegistry` and exposes a `spring.retry` timer from `open()` till `close()` listener callbacks.\nSuch a timer, essentially, covers the whole retry operation and, in addition to the `name` tag based on `RetryCallback.getLabel()` value, it adds tags like `retry.count` (`0` if no any retries entered - first call is successful) and `exception` (if all the retry attempts have been exhausted, so the last exception is thrown back to the caller).\nThe `MetricsRetryListener` can be customized with static tags, or via `Function\u003cRetryContext, Iterable\u003cTag\u003e\u003e`.\nSee `MetricsRetryListener` Javadocs for more information.\n\n## Contributing\n\nSpring Retry is released under the non-restrictive Apache 2.0 license\nand follows a very standard Github development process, using Github\ntracker for issues and merging pull requests into the main branch. If you want\nto contribute even something trivial, please do not hesitate, but do please\nfollow the guidelines in the next paragraph.\n\nAll commits must include a __Signed-off-by__ trailer at the end of each commit message to indicate that the contributor agrees to the Developer Certificate of Origin.\nFor additional details, please refer to the blog post [Hello DCO, Goodbye CLA: Simplifying Contributions to Spring](https://spring.io/blog/2025/01/06/hello-dco-goodbye-cla-simplifying-contributions-to-spring).\n\n## Getting Support\nCheck out the [Spring Retry tags on Stack Overflow](https://stackoverflow.com/questions/tagged/spring-retry). [Commercial support](https://spring.io/support) is available too.\n\n## Code of Conduct\n\nThis project adheres to the [Contributor Covenant](https://github.com/spring-projects/spring-retry/blob/main/CODE_OF_CONDUCT.adoc).\nBy participating, you  are expected to uphold this code. Please report unacceptable behavior to\nspring-code-of-conduct@pivotal.io.\n","funding_links":[],"categories":["Java","容错组件","\u003ca name=\"Java\"\u003e\u003c/a\u003eJava"],"sub_categories":[],"project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fspring-projects%2Fspring-retry","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fspring-projects%2Fspring-retry","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fspring-projects%2Fspring-retry/lists"}