Incompatibility between app instances: prevent rabbitmq to consume messages with particular header

I have two instances of the same java application using spring and rabbitmq. An instance sends a message to a queue but I can't predict which instance will consume it (as expected).

I updated the java application. For some reasons, the is no compatibility between the old and the new version: the new version can't consume the messages from the old one and vice versa.

We can't offer disruption of service while deploying a new version, so we can't stop both instances at the same time. We have to stop instance A, restart instance A with updates, then stop B and restart it with updates.

When I have the new instance of A and the old instance of B, A cannot consume the messages as expected if they were produced by B.

To solve this, the idea was to add a header to the rabbitmq messages. I created a custom rabbitmq template:

@Override
protected Message convertMessageIfNecessary(final Object object) {
    Message message = super.convertMessageIfNecessary(object);
    MessageProperties messageProperties = new MessageProperties();
    messageProperties.setHeader("version", version);        
    return new Message(message.getBody(), messageProperties);
}

This adds a new header with the version of the application. Then I would like to check this header before ack a message.

E.g.:

A sends a message with version 4
B receives the message -> does not consume nor ack because B version is 3.
A receives the message -> consumes because A version is 4.

Is such a configuration possible?

I also had a look at @RabbitListener group properties but I am not sure what to do with this.

Thanks for any help

Solution

You could do that, but it wouldn't be very efficient. When a B(3) instance rejects the message, there's no guarantee that the redelivery will go to a B(4) instance; while it's likely that will eventually happen, depending on circumstances, it might go to a B(3) many times first.

It's probably easier/better to simply bind a new queue to the exchange; have A(4)s publish to the new queue and B(4)s consume from it while the old B(3)s consume from the old queue.

When all A(3) instances have been undeployed, and all messages consumed from the old queue, remove the last B(3) and delete the queue.