-
Notifications
You must be signed in to change notification settings - Fork 3.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
QQs: support if-empty and if-unused deletion parameters #10543
Comments
It appears as if IfUnused and IfEmpty are ignored for streams - https://github.com/rabbitmq/rabbitmq-server/blob/main/deps/rabbit/src/rabbit_stream_queue.erl#L197. Regarding user experience. The numbers shown have different source depending on the queue type. Classic queues go thru process dictionary for all ch records and use the same mechanics for implementing IfUnused. Quorum queues show consumers via queue_metrics and ets:lookup_element. Stream queue uses yet another way of getting consumer count - it enumerates queue nodes and does rpc. So regarding guarantees and behaviours I have these question:
|
I don't think so, specially if they are just ignored at the moment. Streams are expected to have data all the time when, at least, one message is published. Perhaps it could support I can't comment on your other questions since I have little-to-none context on those areas 🙃 |
Is your feature request related to a problem? Please describe.
Classic Queues and Streams support "fail-safe" parameters in queue deletion requests. Quorum Queues could benefit from the same parameters, with some limitations, given the nature of QQs. The intention is to prevent accidental queue deletions when a queue has data and/or consumers.
Observe the following snippet:
Delete queues using
rabbitmqctl delete_queue
Describe the solution you'd like
Add support for
if-empty
andif-unused
in queue deletion requests. Given the distributed nature of Quorum Queues, our guarantees forif-empty
would be as follows: when a queue deletion request arrives, check if there are ready or pending messages. If there are non-zero ready or pending messages, return a failed queue delete response. If there are zero, proceed then with the delete request.Our guarantees for
if-unused
would be as follows: when a queue deletion request arrives, check if any member has consumers attached. If there are non-zero consumers, return a failed queue delete response. If there are zero, then proceed with the delete request.Those guarantees do not prevent the scenario where a message or a consumer arrives after the check has happened, and before the queue deletion is completed. Given the distributed and uncoupled nature of Quorum Queues, I believe this edge case is acceptable. The intention is not to make an atomic "if-empty/unused" queue deletion, but to prevent accidental queue deletions of queues with data or consumers.
Describe alternatives you've considered
No response
Additional context
This came up as part of a contribution to the Topology Operator rabbitmq/messaging-topology-operator#759
Given the lack of support for
if-empty
/if-unused
, the Topology Operator would have to perform aqueue.get
operation, check if it has messages or consumers, then proceed with the delete request (of the Kubernetes object) accordingly. This workaround has a much larger window where messages or consumers may "sneak in", and it would only benefit Kubernetes users. I believe everyone could benefit from this feature being built-in the core.The text was updated successfully, but these errors were encountered: