[rabbitmq-discuss] Checking queue size in bytes

[James Gardner]

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.
Thanks,

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.