STOMP RabbitMQ redeliver message the subscriber if not acknowledged

Question

The client uses STOMP version 1.2 over RabbitMQ version 3.9.3.
The client is used for a chat app as a subscriber for incoming messages.

a["CONNECTED\nserver:RabbitMQ/3.9.3\nsession:session-paGrRWWiEsYECaWdVdqkXQ\nheart-beat:4000,4000\nversion:1.2\nuser-name:6208370595c29c4357f9b81c\n\n\u0000"]

The ack header on subscription is client-individual.
The client is able to acknowledge a message without any exceptions from RabbitMQ.

The problem is, when the client doesn't acknowledge, the message isn't redelivered to the client.
I want to have the message redelivered to the subscriber if the subscriber didn't acknowledged the message.

Is it possible to create such a feature using STOMP and RabbitMQ built-in solutions, without doing any custom acknowledges?

The alternative worse solution I tried was that I set up consumer_timeout to 10000 in rabbitmq.conf, which should disconnect a subscriber which doesn't ack a message for 10s, then the client would reconnect to the client and fetch the missed messaged. The problem with this solution is that it takes 1 minute, not 10 seconds to disconnect a subscriber after not sending ack.

Answer 1

How nack messages are handled is decided by the message broker, in your case RabbitMq. They can either be dropped, sent to a dead letter queue or re-enqueued.
The docs will help you out: https://www.rabbitmq.com/nack.html

In order to use requeuing mechanism you have to use basic.reject or basic.nack in case of bulk. How you set it depends on the client library api you use.

Also refer to: https://www.rabbitmq.com/confirms.html#consumer-nacks-requeue

Sometimes a consumer cannot process a delivery immediately but other instances might be able to. In this case it may be desired to requeue it and let another consumer receive and handle it. basic.reject and basic.nack are two protocol methods that are used for that.

The methods are generally used to negatively acknowledge a delivery. Such deliveries can be discarded by the broker or requeued. This behaviour is controlled by the requeue field. When the field is set to true, the broker will requeue the delivery (or multiple deliveries, as will be explained shortly) with the specified delivery tag.

Answer 2

Well...there's lots to discuss about which configuration to choose when using rabbitmq. I will recommend the following setup (to begin with)

Use fanout model (as described in the docs). This will allow you to:

• Define an exchange (for instance: for all broadcast or public messages)
• Define a queue per service (thus allowing you solution to scale without having a duplication for the same service running simultaneity on several instances)
• Set manual acknowledge (seems more suitable for your use case) or negative acknowledgement (e.g. - when something wrong happen - return message back to broker). This topic is covered here

In short: yes, there is a configuration which suits your needs In depth: you should carefully craft your setup to suit all your needs (including high availability) in order to ensure that your code and deployment will hold as your project progress