[Other] Understanding transient_nonexcl_queues feature deprecation (queues that are both non-durable and non-exclusive)
#13161
-
Community Support Policy
RabbitMQ version used4.0.3 How is RabbitMQ deployed?Community Docker image Steps to reproduce the behavior in question
I am trying to understand why this feature was deprecated: it seems to be a valid use case, for example for a worker queue with ephemeral tasks (messages are no longer relevant after a broker restart). I am guessing the assumption is that such a queue would be a well-known (static) named queue, and therefore the consumers may still be running when the broker restarts, and may not redeclare the queue? Related to #12972, but it does not explain the motivation or guidance on why this might be a poor choice w.r.t. app design. |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment
-
|
@loucadufault because all transient entities will go away together with Mnesia later in the You can always add TTL of, say, 24 hours to a durable classic queue. For as long as the queue has consumers, it will be considered to be "in use", and then after 24 hours it will be deleted by TTL. |
Beta Was this translation helpful? Give feedback.
@loucadufault because all transient entities will go away together with Mnesia later in the
4.xseries. Khepri does not offer transient storage. The only exception is exclusive queues.You can always add TTL of, say, 24 hours to a durable classic queue. For as long as the queue has consumers, it will be considered to be "in use", and then after 24 hours it will be deleted by TTL.