Sequence ID Behavior

[Bill Crowell]

Hi!  I am using classic queues in RabbitMQ 4.x.  When do sequence IDs reset back to one?  I did find some AI information when sequence IDs are reset, but I am not sure if it is accurate:

"These sequence IDs are bound strictly to the life of the AMQP channel. They get reset back to 1 whenever a channel is closed and reopened, or if the underlying TCP connection drops and recovers.  They are purely in-memory counters maintained by the client library and the specific broker channel process. They are not persistent; restarting the broker or closing the client application completely wipes and resets them."

I am not finding anything in the RabbitMQ documentation.  There is some info in the RabbitMQ GitHub pull requests, but nothing very concrete.  The reason I am asking this is from a crash/recovery perspective.  If these sequence IDs get too large, then it causes recovery (with Mnesia) to take several minutes because all of the segments have to be traversed to rebuild the meta data store.  I do know Khepri is the default meta data store in RabbitMQ 4.x, but there are users out there that are still using Mnesia.

Regards,

William Crowell

[Sohaib Alqasem]

Hi Bill, Is the slow recovery you are seeing after a clean rabbitmqctl stop, or only after a kill / crash ? Thanks!

[Bill Crowell]

Hi,

It is after a kill/crash

--
You received this message because you are subscribed to the Google Groups "rabbitmq-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rabbitmq-user...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/rabbitmq-users/aeb909d1-768f-4e41-8c3f-688e0f9e295dn%40googlegroups.com.

[Sohaib Alqasem]

Thanks, thats the classic-queue index scan on a dirty restart, not Mnesia. The AI answer is about delivery tags most likely, and Khepri won't help here either, its a separate subsystem. on a clean stop the queue saves its state and skips the scan. only a dirty shutdown walks the segment files. Its inherent to classic queues, not a bug. For large durable backlogs where crash recovery time matters, quorum queues or streams don't have this scan. If its also slow after a clean rabbitmqctl stop, thats a different cause I think.

Thanks!

[Bill Crowell]

Sohaib,

Thanks for your helpful reply.  Any way to get the segment file walk (index scan) to speed up?  I am working with someone who is stuck on the idea of classic queues because they say quorum does not perform well (which I don't agree with).  I am guessing they would need faster disk.  This is on Kubernetes using a Helm chart for deployment which I am encouraging the use of the RabbitMQ Cluster Operator instead.

Thanks again,

William Crowell

To view this discussion visit https://groups.google.com/d/msgid/rabbitmq-users/36ca38d0-64f8-47d3-9f65-c83d46df4f99n%40googlegroups.com.

[Michal Kuratczyk]

Hi,

I don't think a high sequence ID alone would cause that. Most likely, there are many messages in the queues (and/or the disks are slow),

so resetting the ID, even if it were possible, wouldn't fix anything.

Please provide more details:

- the exact version

- how many queues there are

- how many messages per queue (and the size of the messages if you know - messages are stored differently based on size)

- logs from the recovery process

But yes, generally speaking, the recovery process from an unclean shutdown will be significantly slower than after a clean shutdown.

Understanding why unclean shutdowns occur and avoiding them could be the most beneficial action.

Best,

To view this discussion visit https://groups.google.com/d/msgid/rabbitmq-users/CAONx21haNT9yOxscLHekkEEy%3Du%3DYt2TjZ7bWRe7t6mcwMwyhMQ%40mail.gmail.com.

--

Michal

RabbitMQ Team