<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7652.24">
<TITLE>RE: [rabbitmq-discuss] flow control and erlang client(s)</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<P><FONT SIZE=2>Matthias,<BR>
<BR>
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.<BR>
<BR>
Thanks again for the help,<BR>
Mark.<BR>
<BR>
<BR>
-----Original Message-----<BR>
From: Matthias Radestock [<A HREF="mailto:matthias@lshift.net">mailto:matthias@lshift.net</A>]<BR>
Sent: Tue 6/23/2009 8:07 PM<BR>
To: Geib, Mark<BR>
Cc: rabbitmq-discuss@lists.rabbitmq.com<BR>
Subject: Re: [rabbitmq-discuss] flow control and erlang client(s)<BR>
<BR>
Mark,<BR>
<BR>
Mark Geib wrote:<BR>
> I have seen in the erlang client test code that #'channel.flow'{active =<BR>
> false} is supported for flow control related to memory high/low water<BR>
> marks. However I need to limit the number of message published to a<BR>
> queue on a broker and need to know if in 1.6 it is supported and if so<BR>
> how to create the queue for support flow control, that is stopping<BR>
> message publishing until message are dequeued...<BR>
<BR>
What you are asking for is actually conceptually impossible.<BR>
<BR>
In AMQP producers publish messages to an *exchange* (note that they are<BR>
not "connected" to that exchange; each publish command can potentially<BR>
go to a different exchange), which then routes them to *zero or more*<BR>
queues, depending on the type of exchange, routing key in the message,<BR>
and existing bindings between queues and the exchange.<BR>
<BR>
So there is no way for the broker to know which of its connected clients<BR>
might next send a message that ends up getting routed to a particular<BR>
queue. Hence it cannot throttle clients based on any queue-based limits.<BR>
<BR>
If there were per-queue message count limits (and this is something<BR>
which has been discussed, though it's not part of the AMQP spec and not<BR>
something RabbitMQ currently implements), the best the broker could do<BR>
is reject, return or discard any messages that arrive after the limit<BR>
has been reached.<BR>
<BR>
<BR>
Regards,<BR>
<BR>
Matthias<BR>
<BR>
</FONT>
</P>
</BODY>
</HTML>