Skip to content

rabbit_db: Eliminate the delete_queue Khepri transaction (backport #14902)#15954

Merged
dumbbell merged 2 commits intov4.3.xfrom
mergify/bp/v4.3.x/pr-14902
Apr 8, 2026
Merged

rabbit_db: Eliminate the delete_queue Khepri transaction (backport #14902)#15954
dumbbell merged 2 commits intov4.3.xfrom
mergify/bp/v4.3.x/pr-14902

Conversation

@mergify
Copy link
Copy Markdown

@mergify mergify Bot commented Apr 8, 2026

… by using keep_while conditions on bindings and auto-delete exchanges.

Why

The delete_queue transaction's anonymous function has to be extracted by Horus, like any Khepri transaction. This is an expensive operation, but Horus uses caching to avoid most work after the first extraction.

Unfortunately, even with this caching, this transaction is still very expensive when there are massive simultaneous deletions of queues. For instance when the queues' lifetime is linked to that of many clients, and all these clients get disconnected at once.

How

This patch removes the transaction entirely. Instead, it uses keep_while conditions on bindings and auto-delete exchanges to let Khepri handle the deletion of semantically related tree nodes. RabbitMQ just has to make a simle "delete this queue" command.

To maintain backward compatibility, we introduce the replaced_delete_queue_transaction feature flag. Its enable callback will take care of rewriting all bindings and auto-delete exchanges record in the store to add the new keep_while conditions.

The binding deletion transaction is also simplified because it benefits from the keep_while conditions. We may be able to replace this transaction is the future as well in the same manner.


This is an automatic backport of pull request #14902 done by Mergify.

dumbbell added 2 commits April 8, 2026 06:54
... by using `keep_while` conditions on bindings and auto-delete
exchanges.

[Why]
The `delete_queue` transaction's anonymous function has to be extracted
by Horus, like any Khepri transaction. This is an expensive operation,
but Horus uses caching to avoid most work after the first extraction.

Unfortunately, even with this caching, this transaction is still very
expensive when there are massive simultaneous deletions of queues. For
instance when the queues' lifetime is linked to that of many clients,
and all these clients get disconnected at once.

[How]
This patch removes the transaction entirely. Instead, it uses
`keep_while` conditions on bindings and auto-delete exchanges to let
Khepri handle the deletion of semantically related tree nodes. RabbitMQ
just has to make a simle "delete this queue" command.

To maintain backward compatibility, we introduce the
`tie_binding_to_dest_with_keep_while_cond` feature flag. Its `enable`
callback will take care of rewriting all bindings and auto-delete
exchanges record in the store to add the new `keep_while` conditions.

The binding deletion transaction is also simplified because it benefits
from the `keep_while` conditions. We may be able to replace this
transaction is the future as well in the same manner.

(cherry picked from commit de43879)
@dumbbell dumbbell marked this pull request as draft April 8, 2026 06:54
@dumbbell dumbbell added this to the 4.3.0 milestone Apr 8, 2026
@dumbbell dumbbell marked this pull request as ready for review April 8, 2026 07:24
@dumbbell dumbbell merged commit fc2b6ec into v4.3.x Apr 8, 2026
185 checks passed
@dumbbell dumbbell deleted the mergify/bp/v4.3.x/pr-14902 branch April 8, 2026 07:24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant