Reconnecting/Retry mechanism

[vveludan]

Good afternoon Dave.
While we were using spring-amqp 1.0.0.M1, we had an option to embed retry mechanism (if the broker was down) by overriding
org.springframework.amqp.rabbit.connection.SingleC onnectionFactory.prepareConnection(Connection con) as follows:
protected void prepareConnection(Connection con) throws IOException {
con.addShutdownListener(new ShutdownListener(){
@Override
public void shutdownCompleted(final ShutdownSignalException cause) {
//resetConnection();
boolean isConnected = false;
int retry = 0;
int maxRetry = 5;
while(!isConnected && retry < maxRetry) {
try {
//initConnection();
isConnected = true;
System.out.println("isConnected: "+isConnected);
} catch(Exception e) {
e.printStackTrace();
System.out.println("Exception occurred with retry: "+retry);
retry++;
try {
Thread.currentThread().sleep(5000);
} catch (InterruptedException e1) {
e1.printStackTrace();
}
}
}

}
});
}

After we have moved to spring-amqp 1.0.0.M3 version we have been using CachingConnectionFactory.
But there is no more prepareConnection() method to override to implment Retry mechanism.

Could you please let me know if spring-amqp framework itself provides Retry mechanism (Reconnecting mechanism) or
is there any work around.

Thanks
Venkat

[Dave Syer]

M3 is old now (one milestone behind the last release). I would move to a snapshot if I were you because we should be ready to release 1.0 soon.

RC1 introduced the ConnectionListener interface which you can use to modify the physical connection when it is opened (I think there was also a bug which meant that it got called on logical open as well, fixed in snapshots). So you could use that in the same way you were using your override in M1.

But the CachingConnectionFactory should reconnect itself on failure. It doesn't have the loop that you have (so you have to keep trying if you get an exception to force it to reconnect), but please try it and see if it works for you. If it doesn't there are other features you should look at. The SimpleMessageListenerContainer also does its own reconnect, and that is a loop with a back off, so maybe that fits your use case anyway. Plus there are a couple of *RetryOperationsInterceptorFactoryBean implementations (see unit tests and javadocs for details on how to use them) that allow you huge flexibility in declaring the properties of the retry (backoff, exceptions types, max attempts etc.). You can use that to wrap the RabbitTemplate or the MessageListener.

[vveludan]

Good afternoon Dave.
I appreciate and thank you for your feedback.

Thanks
Venkat