we use RabbitMQ to communicate between our components. For some reason some components could not communicate with the server any more tonight. On the server the issue looked like that:
...
=ERROR EVENT==== Tue, 06 Dec 2022 21:18:15 GMT ===
2022-12-06 21:18:15.144351+00:00 [erro] <0.9186.1093> closing AMQP connection <0.9186.1093> (123.123.123.123:26688 -> 234.234.234.234:5671 - rabbitConnectionFactory#1f48fa72:0):
2022-12-06 21:18:15.144351+00:00 [erro] <0.9186.1093> missed heartbeats from client, timeout: 60s
=ERROR EVENT==== Tue, 06 Dec 2022 21:18:17 GMT ===
2022-12-06 21:18:17.549345+00:00 [erro] <0.4340.1090> closing AMQP connection <0.4340.1090> (123.123.123.123:39360 -> 234.234.234.234:5671 - rabbitConnectionFactory#e4348c0:0):
2022-12-06 21:18:17.549345+00:00 [erro] <0.4340.1090> missed heartbeats from client, timeout: 60s
=ERROR EVENT==== Tue, 06 Dec 2022 21:18:27 GMT ===
2022-12-06 21:18:27.177133+00:00 [erro] <0.5137.403> closing AMQP connection <0.5137.403> (123.123.123.123:39360 -> 234.234.234.234:5671 - rabbitConnectionFactory#6f071d0c:0):
2022-12-06 21:18:27.177133+00:00 [erro] <0.5137.403> missed heartbeats from client, timeout: 60s
=ERROR EVENT==== Tue, 06 Dec 2022 21:18:31 GMT ===
2022-12-06 21:18:31.701088+00:00 [erro] <0.25212.1093> closing AMQP connection <0.25212.1093> (123.123.123.123:30528 -> 234.234.234.234:5671 - some-component):
2022-12-06 21:18:31.701088+00:00 [erro] <0.25212.1093> missed heartbeats from client, timeout: 60s
=ERROR EVENT==== Tue, 06 Dec 2022 21:18:36 GMT ===
2022-12-06 21:18:36.922101+00:00 [erro] <0.10334.685> closing AMQP connection <0.10334.685> (123.123.123.123:24960 -> 234.234.234.234:5671 - SpringAMQP#1a61721e:0):
2022-12-06 21:18:36.922101+00:00 [erro] <0.10334.685> missed heartbeats from client, timeout: 60s
...
The components reconnected, and continued their operation, though for one queue some messages were deadlettered. Which took me some time to find out why they were deadlettered and are delayed in the processing by a few hours as they were manually shoveled back to the in-queue after the investigation.
I assume that these deadlettered messages might have been unacked at the time of the disconnect.
My quesion, how can I prevent that behaviour, so that the messages are reqeued and then processed normally (either by some other instance that has still a connection or the same instance when it reestablishes the connection) (Analog if the consumer would nack the message with requeue=true?
