[rabbitmq-discuss] Checking queue size in bytes
james.gardner at noaa.gov
Wed Jul 10 17:32:53 BST 2013
I +1 that feature request. I love that AMQP apps are able to create
their own entities (queues, etc) but don't like the idea that they are
potentially unbounded in size if you allow them to do so. For apps that
use our RMQ broker but are outside our immediate department this could
be problematic and compromise the broker's operation by swallowing
server resources. This weakness makes me want to manage app writer's
queues for them, which seems to go against the spirit of AMQP. The kind
of suggestion below would fix that issue. Forced 'x-expires' would also
be great for us.
I'd like to see more use of the policy mechanism in general, esp. in
limiting the characteristics of queues/exchanges created on the broker,
such as forcing a queue to be exclusive or auto-delete, etc; I assume
that was what the poster below was also referring to. But also for
applying to users; max connections, channels, etc ?, which I believe was
touched upon in other recent posts.
Looks like an email '[rabbitmq-discuss] total number of queues allowed'
just appeared on the mailing list that somewhat mirrors our concerns. We
also may expose our broker to the public at some point.
I get the wider impression that RMQ (maybe because of the nature of
AMQP?) was designed under an assumption of a certain level of good or
orderly behavior from the client, that may not always exist, so it
strikes me that this is an area in which RMQ has yet to mature. Let me
know if you think I'm off-base there.
James Gardner (NWS)
On 07/10/2013 02:36 AM, Matthias Radestock wrote:
>> On a related note, would it be possible for some future version of
>> RabbitMQ to allow queue policies like "x-max-length" and "x-message-ttl"
>> in addition to the queue declaration arguments?
> Yes. It's on our todo list, but not a priority.
More information about the rabbitmq-discuss