[rabbitmq-discuss] spring-amqp

[Dave Syer]

> That said, what is the intended model for retry?  I don't see a "delayed
> retry" being part of AMQP.

Neither do I.  AMQP gives you redelivery of unacked messages.  That's
as far as we expect it to take us for now.  Rabbit happens to re-queue
unacked messages at the *back* of the queue, which gives you some
useful delay in practice under load, but not if volume is low.

We have a retry abstraction in Spring Batch, and it has moved to
Spring Commons so that Spring Data can use it for JDBC connection
retry in an Oracle cluster.  The Batch piece is used heavily by at
least one large client I know of purely to handle delayed retry (with
JMS in that case, but the idea is the same).  From Rabbit's point of
view I'dsay this is an "application" concern, but there are higher
level frameworks like the Spring family that can help to take the pain
out of implementing such concerns.  Spring AMQP could use Spring
Commons to implement a stateful retry (e.g. with a delay).  Out of the
box it is likely to use simple Java Thread APIs (e.g. sleeping) which
is best for short delays.  For longer delays of the sort that Jon was
talking about in that other thread you mentioned, we would need to
think about scheduling, triggers and persistence (all of which are
ingredients in existing Spring frameworks, so no reason why it
wouldn't be do-able - but maybe not the first thing we do).

Anyway, to summarize, if you want the AMQP behaviour (unacked message
= "rolled back" in Spring transaction terms, and re-delivered) you
will get that with no effort from Spring AMQP 1.0.0.M2.  More
complicated retry patterns will come later, and/or require some custom
components (e.g. implementation of retry policy or retry operations).