In the future, please try to provide something we can just execute. We had at least a few issue reports a day and
putting together the reproduction steps is really time consuming. The more we do that, the less time we have
for RabbitMQ development.
This is a test case I put together:
# publish a single message
perf-test -ad false -f persistent -qa x-queue-version=2,x-consumer-timeout=300000 -u q5m -y 0 -C 1
# start a consumer with very high latency
date; perf-test -ad false -f persistent -qa x-queue-version=2,x-consumer-timeout=300000 -u q5m -x 0 -D 1 -L 1000000000;date
# start another consumer that should get the message after the high-latency consumers times out
date; perf-test -ad false -f persistent -qa x-queue-version=2,x-consumer-timeout=300000 -u q5m -x 0 -D 1; date
It works, but it seems to be taking 1 minute longer to time out than expected (6 instead of 5, 11 instead of 10, when I used 600000).
This one extra minute seems to be a bug that I don't fully understand. However, this feature was never meant to be used with such low values.
The default is 30 minutes and people keep asking how to extend it, which is why this per-queue/per-consumer option was added.
While the extra minute seems to be a bug, the timeout is also not meant to be precise. So we might fix it, but please don't expect
that whatever you set will be enforced down to the second. The consumer timeout is a mechanism to make sure we can make progress
even if a consumer stopped responding, not to guarantee delivery in a certain time.
Best,