Consumer timeout setting

3,013 views
Skip to first unread message

Nicolas Mercado

unread,
May 20, 2021, 1:41:41 PM5/20/21
to rabbitmq-users
Hi,

We have an implementation that uses RabbitMQ version 3.8.11.
Some of our jobs might run in a few seconds, some will take several minutes, even hours.
So, the issue we're having is that the consumer_timeout setting is closing channels for jobs that take too long to acknowledge messages.
Is there a way to:
- Disable this setting at runtime?
- Configure this at a queue / channel level ?

Would you have any architectural changes to suggest? We could acknowledge the message preemptively but then that would introduce other problems like republishing messages back in the case of process termination, etc.

Thanks!

Hans-Martin Mosner

unread,
May 24, 2021, 4:58:21 PM5/24/21
to rabbitmq-users
It's likely not possible to configure that at the level of queue or channel.
However, you should be relatively safe by setting it globally to a very high value, such as 24 hours. (https://www.rabbitmq.com/consumers.html#acknowledgement-timeout).
The only negative effect it could have is that the broker will not detect a consumer that is somehow stuck in processing a message. Your client should be able to wrap the message processing in some kind of timeout handler of its own and close the channel when a timeout is exceeded.
A situation where your client is really stuck but still sends heartbeat frames should be pretty rare. If the client process is stuck and does not send heartbeats anymore, the connection will be closed anyway.

Cheers,
Hans-Martin

Nicolas Mercado

unread,
May 24, 2021, 11:46:53 PM5/24/21
to rabbitm...@googlegroups.com
Hi, Hans.

Thanks for your answer.
Yes, I saw the configuration setting. However, we're using the AWS managed version of RabbitMQ (AmazonMQ) which does not allow customizing configuration settings. You need to import definitions manually via the management console (which is also not available for all our environments).
I am seeing that preemptively acknowledging long running jobs seems like the recommended approach here. Or else, the long running job could be split across smaller jobs passing over different stages.

modus
Nicolás Mercado
PHP Backend Engineer
Modus
Nicaragua 4768 - C1414BVJ - CABA
T:4831-5497
C:54-9-11-5995-0564


--
You received this message because you are subscribed to a topic in the Google Groups "rabbitmq-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/rabbitmq-users/izCTe-Ag3cU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to rabbitmq-user...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/rabbitmq-users/c5edcc43-1001-421a-9b9f-2e1b2f4c9d11n%40googlegroups.com.
Reply all
Reply to author
Forward
0 new messages