Why RabbitMQ Delayed Messages Fail After a Certain Timeout and How to Fix It

While writing a Spring Cloud Stream tutorial, the author introduced how to use RabbitMQ delayed messages for scheduled tasks, but later discovered that some delayed messages were consumed immediately without any delay.

Problem Identification

Only certain messages exhibited the missing‑delay behavior, leading to the hypothesis that an excessively long delay caused the failure. To verify, the original example was modified to add a delay request parameter for controlling the delay time.

<ol><li><code>@GetMapping("/sendMessage")</code></li><li><code>public String messageWithMQ(@RequestParam String message, @RequestParam Long delay) {</code></li><li><code>    log.info("Send: " + message);</code></li><li><code>    testTopic.output().send(MessageBuilder.withPayload(message).setHeader("x-delay", delay).build());</code></li><li><code>    return "ok";</code></li><li><code>}</code></li></ol>

Two curl requests were then executed:

Request 1 : delay 5000 ms – the message was delayed by 5 seconds and then consumed correctly.

<ol><li><code>curl localhost:8080/sendMessage?message=hello&delay=5000</code></li></ol>

Request 2 : delay 31536000000 ms (1 year) – the message was consumed immediately, showing no delay effect.

<ol><li><code>curl localhost:8080/sendMessage?message=hello&delay=31536000000</code></li></ol>

Conclusion

The root cause is RabbitMQ's message TTL limit. The expiration must be a non‑negative 32‑bit integer (0 ≤ n ≤ 2³²‑1) expressed in milliseconds, so the maximum allowable delay is 4294967295 ms.

Boundary testing confirms that a delay of 4294967295 ms works, while 4294967296 ms results in immediate consumption.

Therefore, when using RabbitMQ delayed messages, ensure the delay does not exceed 4294967295 ms; otherwise, adopt alternative scheduling mechanisms.

Code Example

The full source code can be found in the GitHub and Gitee repositories.