[rabbitmq-discuss] General approaches for tracking unreclaimed memory

[Matthias Radestock]

Garrett,

Garrett Smith wrote:
> Let's say I restart a process and terminate a connection on an
> exclusive queue. I'm interested in the messages -- I'm gonna come back
> online after the restart. I don't want to delete the queue. Trust me
> :)
> 
> Let's say, on the other hand, that I decommission the queue owner and
> (admittedly sloppily) don't delete the queue. Messages pile up and I
> run out of memory/processes.
> 
> I understand this is entirely application specific. It's like running
> out of disk space when you keep writing to a database. I understand
> that and will deal with it easily enough, though I do think that
> protections against resource exhaustion are important.

Understood. However, message expiry is entirely in the control of the
client, so it's not something a server can rely on for keeping resources
bounded unless it can trust the clients and clients have been correctly
coded to supply a reasonable expiry time.

Also, you'd still want a mechanism to delete the queue in your scenario,
because otherwise the system will waste resources on publishing and then
deleting messages from it.

It seems like what you are really after is a server-controlled "time to
live when unused" setting for a queue, i.e. the server would
automatically delete the queue after it hasn't been used for a while.
And you'd probably want to put limits on queue sizes too. etc, etc.


Regards,

Matthias.