How to use in spring integration a retry policy?

[Alvaro V.G.]

Hi,

Currently I am working with Spring Integration framework and I need to apply a retry policy in a service (Service activator) that persists information in DB.

In the case of exception I want the system to retry the operation again using the same inforamtion/parameters that I used before.

Please, could you help how could I face the problem?.

Regards

A

[oleg.zhurakousky]

How many times do you want to retry?
ALso, are you waiting for the reply or its totally async?

[Alvaro V.G.]

Hi,

I want to implement the 'retry policy' in both cases.

Right now it is not a priority the number of times. I prefer to think how to face the problem.
I was thinking to use 'ReplyTemplate' in the services tight with the service activators to see how it works and later on redesign the flow in a proper way.

What do you suggest?. Cheers

[Cleric]

Hello, Oleg
I've got the same task.
I configured poller as transactional and I use PlatformTransactionManager.
And also I added JdbcMessageStore for my queues.
So, if I'll get MessagingException in my async process, the transaction around receive() will be rollbacked and my message will remain in DB. Am I right?
And I think in that case my message will be avaliable in the next polling period.

Thanks,
Artem

[igor.bljahhin]

I do it almost in same way, like the user "clerik": I have added the field "retryCount" to my message object and in case of exception, I increment the value of this field, and save the message back into database. Before processing any message, I check the value of "retryCount" and filter it out, if the value is more than 10.

[oleg.zhurakousky]

Well, for the time being you can use a simple AOP-based approach to wrap your processor (e.g., service-activator, transformer etc) with some RetryInterceptor proxy, however for SI 2.1 we are planning to incorporate it into the framework.
https://jira.springsource.org/browse/INT-343. Add yourselves as followers to be notified when its done.

[Alvaro V.G.]

Hi,

Tx a lot Oleg for the idea.

I have been testing with stateless RetryPolicy in a RetryTemplate and the test was ok. Now I am going to focus my tests in a stateful RetryPolicy.
As soon as I have something I will let you know how it was.

Cheers.

[Alvaro V.G.]

Hi, keep working in the idea of this thread I have a question about stateful RetryTemplate.

Let say that we have the following code:

final MyTransferObject to = new MyTransferObject();
......
RetryCallback<MyTransferObject> callback = new RetryCallback<MyTransferObject>() {
public MyTransferObject doWithRetry(RetryContext context) throws Exception {
return myService.doSomthing(to);
}
};


Assuming that doSomething is a transactional method that is going to persist something in DB and sets some properties in MyTransferObject.

Assuming that we could define something like this:

RetryPolicy retryPolicy = new SimpleRetryPolicy(3, Collections.<Class<? extends Throwable>, Boolean> singletonMap(Exception.class, true));
RetryTemplate retryTemplate = new RetryTemplate();
retryTemplate.setRetryPolicy(retryPolicy);
RetryState state = new DefaultRetryState(to);

Assuming that the first retryTemplate.execute(callback, state); the service method throws an exception ( we catch it).
Is possible to execute retryTemplate.execute(callback, state) a second time with to exactly the same values than the first time?.

Cheers

[ravikr02]

Oleg what happens if I drop a message in a filter or an interceptor. In a filter I would return false and return null in a interceptor. If I am right?
Say the retry threshold was reached for a message, I drop the message, will the message be deleted from the persistent message store?

[oleg.zhurakousky]

Ideally all you need to do to is to fake the success. THis way transactional resource would think that everything went fine and the message will be removed from the message store. Is that what you are asking? I mean there is currently no support for it in SI at the component level and we may introduce it in the future, but there are many different ways to do it and they are all different depending on the use case.