rwirth at demandware.com
Tue Oct 26 17:40:27 BST 2010
Dave Syer wrote:
> We haven't implemented rollback in the asynch case yet in Spring AMQP
> (sync works but it's less useful) - it's on the list of things to do for
> M2. The intention really is that for basic use cases like this you
> shouldn't care which version of the low-level Rabbit client you are using.
> You shouldn't need to know how or when to call basicRecover() because the
> listener container will do it for you.
Thanks! I am merely trying to be able to cause a onMessage() retry after a
failure, which I wasn't able to achieve with M1 (and amqp-rabbit 1.8.1) so I
have to decide if I should look into using the rabbit java API instead of
AMQP, or wait for AMQP M2.
That said, what is the intended model for retry? I don't see a "delayed
retry" being part of AMQP. Some blogs suggest to have the application do its
own retry, always consuming the message and never throwing -- other MQ's
have the notion of a retryDelay/Limit, a convenience I got used to.
I now see a thread on exactly that topic:
View this message in context: http://old.nabble.com/spring-amqp-tp29209324p30059425.html
Sent from the RabbitMQ mailing list archive at Nabble.com.
More information about the rabbitmq-discuss