1 Introduction
Sometimes when invoking a web service, we may be interested in retrying the operation in case an error occurs. When using Spring Integration, we can achieve this functionality with RequestHandlerRetryAdvice class. This class will allow us to retry the operation for a specified number of times before giving up and throwing an exception. This post will show you how to accomplish this.
The test application will invoke a web service and if it fails to respond, it will wait for a specified time and try it again until it receives a response or it reaches a retry limit. If the limit is reached, the failed request will be stored into a database. Mainly, this post shows an example of the following:
The source code of the application can be found at github.
You can also get the source code of the web service project that is called by the application at github.
2 Web service invocation
Use case: The client invokes the web service and receives a response.
The request enters the messaging system through the "system entry" gateway. It then reaches the outbound gateway, invokes the web service and waits for the response. Once received, the response is sent to the response channel.
The above image is the result of this configuration:
Mapped to the response channel there's a service activator which just logs the result.
TestInvocation.java: Sends the request to the entry gateway
With this configuration, if the service invocation fails, a MessagingException will be raised and sent to the error channel. In the next section, we will add the retry configuration.
3 Adding the retry advice
Use case: The initial request failed because the service is not active. We will retry the operation until a response is received from the service.
In this case, we need to add the retry advice to the web service outbound gateway:
Now the web service outbound gateway will delegate the invocation to the retry advice, which will try the operation as many times as specified until it gets a response from the service.
Let's define the retry advice:
To accomplish its objective, the advice uses a RetryTemplate, which is provided by the Spring Retry project. We can customize its behavior by defining backoff and retry policies.
Backoff policy: Establishes a period of time between each retry. The more interesting types are:
- FixedBackOffPolicy: Used in our example. It will wait for the same specified amount of time between each retry.
- ExponentialBackOffPolicy: Starting with a determined amount of time, it will double the time on each retry. You can change the default behavior by establishing a multiplier.
Retry policy: Establishes how many times will retry the failed operation. Some of the types:
- SimpleRetryPolicy: Used in our example. Specifies a retry attempts limit.
- ExceptionClassifierRetryPolicy: Allows us to establish a different maxAttempts depending on the exception raised.
- TimeoutRetryPolicy: Will keep retrying until a timeout is reached.
4 No luck, logging the failed request
Use case: The service won't recover, storing the request to the database.
The final part of the configuration is the following:
The service activator subscribed to the error channel will retrieve the failed message and send it to the outbound adapter, which will insert it to a mongoDB database.
The service activator:
If we not succeed in obtaining a response from the service, the request will be stored into the database:
6 Conclusion
We've learnt how Spring Integration gets support from the Spring Retry project in order to achieve retry of operations. We've used the int-ws:request-handler-advice-chain, but the 'int' namespace also supports this element to add this functionality to other types of endpoints.
I'm publishing my new posts on Google plus and Twitter. Follow me if you want to be updated with new content.Labels: Integration, mongoDB, Spring, web services
