Cleanup of Unused Queues
In an use-case like an mqtt client connects with CleanStart: No and Durable: Yes, the queue will be created and msgs are consumed as per the subscriptions. But when we restart the client, with a different session name will lead to creation of new queue. Now, both the old and new queues will have the same subscriptions. From this point, all the new msgs published to that subscription falls into both the queues. The msgs in the old queue will keeps piling without any consumer.
How can we deal with this situation by clean-up the unused queues for a specific period, like by configuring ttl at queue level specifically in an env like eks. Is there any solution available in Solace or do I need to implement an in-house solution like setting some cron job. Any references would be really appreciated.
Answers
-
Hey @Vinod_vema, welcome to the Community..!
First obvious question: can you not subscribe/connect back to the broker with the same session name so the broker knows to reassign the auto-created queue back to this app?
EDIT: I heard back from one of our top engineers at Solace who pointed me in the right direction:
MQTT5 allows a client to specify a "session expiry interval" in the MQTT CONNECT properties. This will cause the broker to clean up any unused MQTT session queues after the client's disconnection.
Do some Googling, there's quite a few pages explaining this feature. 👍🏼
0 -
Hey @Aaron, Thanks for the information.
I am maintaining Solace brokers and my smart developers use different mqtt sessions for their dev/testing activities, sometimes with clean session:true/ false and move on. As an administrator, I see the leftover sessions, queues and even msgs in the queues for the subscriptions. Nobody cares for these resources. Now I want to implement a cleanup measure, irrespective of the type of implementation of pub/sub clients.
Is there any way to implement at the solace broker level to clear all the sessions/clients/queues existing unused beyond a defined TTL.
0 -
Thank you @Aaron for all your time. Will explore that way.
0 -
BTW: when you say "beyond a defined TTL", I just want to make sure you're saying what I'm thinking you're saying (but also for anyone stumbling on this later):
Often, queues in dev fill up because devs are publishing away, but not necessarily consuming from them. Queues fill up, can cause spool full issues, stop your broker from accepting any new Guaranteed messages. A great way to keep developer queues "trimmed" is to ensure that queues created in dev have a "max TTL" set to something reasonable (e.g. 3 days), and "respect TTL" is enabled.
For admin-created queues, this can be done by the broker administrator. But for any application-created queues, this policy can be enforced by the use of queue templates, associated with the developer's application's client profile.
1
