[rabbitmq-discuss] flow control and erlang client(s)

[Geib, Mark]

Matthias,

I actually suspected that was the case. Would it be expensive then to have the publisher of the message check the number of messages in the queue prior to publishing. The publisher actually binds the queue to make sure that messages are not dropped when no subscriber has bound the queue yet. This would all be from erlang.

Thanks again for the help,
Mark.


-----Original Message-----
From: Matthias Radestock [mailto:matthias at lshift.net]
Sent: Tue 6/23/2009 8:07 PM
To: Geib, Mark
Cc: rabbitmq-discuss at lists.rabbitmq.com
Subject: Re: [rabbitmq-discuss]  flow control and erlang client(s)
 
Mark,

Mark Geib wrote:
> I have seen in the erlang client test code that #'channel.flow'{active = 
> false} is supported for flow control related to memory high/low water 
> marks. However I need to limit the number of message published to a 
> queue on a broker and need to know if in 1.6 it is supported and if so 
> how to create the queue for support flow control, that is stopping 
> message publishing until message are dequeued...

What you are asking for is actually conceptually impossible.

In AMQP producers publish messages to an *exchange* (note that they are 
not "connected" to that exchange; each publish command can potentially 
go to a different exchange), which then routes them to *zero or more* 
queues, depending on the type of exchange, routing key in the message, 
and existing bindings between queues and the exchange.

So there is no way for the broker to know which of its connected clients 
might next send a message that ends up getting routed to a particular 
queue. Hence it cannot throttle clients based on any queue-based limits.

If there were per-queue message count limits (and this is something 
which has been discussed, though it's not part of the AMQP spec and not 
something RabbitMQ currently implements), the best the broker could do 
is reject, return or discard any messages that arrive after the limit 
has been reached.


Regards,

Matthias

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20090623/0dfd1702/attachment.htm