Implications of changing the channel-tick-interval setting to something shorter than 60 seconds

[victorarbuesmallada]

Community Support Policy

• I have read RabbitMQ's Community Support Policy
• I run RabbitMQ 4.x, the only series currently covered by community support
• I promise to provide all relevant information (versions, logs from all nodes, rabbitmq-diagnostics output, detailed reproduction steps)

RabbitMQ version used

4.1.1

Erlang version used

27.3.x

Operating system (distribution) used

Linux

How is RabbitMQ deployed?

Community Docker image

rabbitmq-diagnostics status output

not required.

Logs from node 1 (with sensitive values edited out)

not required.

Logs from node 2 (if applicable, with sensitive values edited out)

No response

Logs from node 3 (if applicable, with sensitive values edited out)

No response

rabbitmq.conf

not required.

Steps to deploy RabbitMQ cluster

We use the RabbitMQ K8S operator CRDs

Steps to reproduce the behavior in question

not required.

advanced.config

[{rabbit, [ {channel_tick_interval, 1000} ]}].

Application code

No response

Kubernetes deployment file

No response

What problem are you trying to solve?

We are trying to reduce the ack timeout to something lower than a minute.
Our queue policies already use consumer-timeout values, but the fact that channel-tick-interval is defaulted to 60 seconds makes that timeout longer than what we expect.
Would it be a good idea to lower that value, since it seems to affect other internal processes within RabbitMQ? Is there any other way we can configure this value besides the advance settings which seems to sit at server level.
We could see this approach as answer on this other discussion, but wanted to know if there is any drawback to that solution.

[michaelklishin]

@victorarbuesmallada going below a minute doesn't make much sense, not just because certain parts of channel state are only evaluated once a minute but also because the delivery acknowledgement timeout feature, as the docs explain, is a server protection mechanism, not a way to manage your consumers.

If you want your consumers to report an error if processing takes more than, say, 30 seconds, you have to do it in your own code, and report relevant metrics as you see fit.

[victorarbuesmallada]

thanks! Our thinking was to use the consumer_timeout setting to nack a message automatically after a brief period of time, in cases in which consumers fail to process a particular message.
As you mentioned, this is something we'll need to do in our own code instead.