1
votes

I have gone through rabbitmq documentation, https://www.rabbitmq.com/confirms.html#publisher-confirms

Using standard AMQP 0-9-1, the only way to guarantee that a message isn't lost is by using transactions -- make the channel transactional then for each message or set of messages publish, commit. In this case, transactions are unnecessarily heavyweight and decrease throughput by a factor of 250. To remedy this, a confirmation mechanism was introduced. It mimics the consumer acknowledgements mechanism already present in the protocol.

To enable confirms, a client sends the confirm.select method. Depending on whether no-wait was set or not, the broker may respond with a confirm.select-ok. Once the confirm.select method is used on a channel, it is said to be in confirm mode. A transactional channel cannot be put into confirm mode and once a channel is in confirm mode, it cannot be made transactional.

Currently I am using RabbitTemplate.convertAndSend of spring-rabbit library to send message. I am using transactional channel to publish messages to rabbitmq, As per the document its slower and I can can improve the throughput by using publisher-confirm.

But I am not much clear about it.

If I want to enable confirm then what are changes required and how do I handle exception? What will be my retrial mechanism? Does this publisher confirm work in asynchronous way? And does transaction work in synchronously?

Any suggestion is highly appreciated.

1

1 Answers

2
votes

Using publisher confirms will not improve performance significantly over transactions if you wait for the confirm for each individual send. They help significantly if you send many messages and wait for the confirms later.

Transactions are synchronous. Confirms are completely asynchronous.

See Confirms and Returns.

When you enable confirms, you provide a callback to the template which will be called when the confirm is received. You add correlation data to the send, which is provided in the callback so you can determine which send this confirm is for. Furthermore, the correlation data (in recent versions) provides a Future<?> which you can wait on to receive the confirm in a synchronous manner.

That's where you would handle any exception(s).

I hope that helps.

There is a confirms and returns sample Spring Boot application in the samples repo but it was created before the future was added to the CorrelationData. That will be fixed soon.

The correlation data can contain the original message, enabling retry.