You can also monitor the number of unconfirmed messages (do not confuse with "unacked") to prevent broker overload. See "publisher confirms".<br><br><div class="gmail_quote">On Wed, Mar 14, 2012 at 1:03 PM, stone <span dir="ltr"><<a href="mailto:zmstone@gmail.com">zmstone@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi<div><br></div><div>You can retrieve the information of an existing queue by declaring it with passive option set to true.</div>
<div>I had the same problem as you do, and found this link the other day, haven't tried out though.<br>
</div><div><br></div><div><a href="http://stackoverflow.com/questions/1038318/check-rabbitmq-queue-size-from-client" target="_blank">http://stackoverflow.com/questions/1038318/check-rabbitmq-queue-size-from-client</a></div>
<div><br></div>
<div>BRs</div><div>/stone</div><div><br><div class="gmail_quote">2012/3/14 Jerry Kuch <span dir="ltr"><<a href="mailto:jerryk@vmware.com" target="_blank">jerryk@vmware.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi, Paul: You could use the management HTTP API to keep a track on<br>
queue depths and then have your producer dynamically adjust its<br>
behavior if it notices that consumption isn't keeping up, but you<br>
should really think about whether this is something you want to do.<br>
<br>
It ends up building a lot of of hand holding awareness of the messaging<br>
mechanics into your endpoint applications, which in some ways goes against<br>
the spirit of using a messaging service in between your producers and<br>
consumers in the first place. You might be better off monitoring the<br>
system, and spinning up additional consumers to drain especially busy<br>
queues than building the sort of logic you describe...<br>
<br>
Best regards,<br>
Jerry<br>
<div><div><br>
----- Original Message -----<br>
From: "Paul M. Bell" <<a href="mailto:pbell@syncsort.com" target="_blank">pbell@syncsort.com</a>><br>
To: <a href="mailto:rabbitmq-discuss@lists.rabbitmq.com" target="_blank">rabbitmq-discuss@lists.rabbitmq.com</a><br>
Sent: Tuesday, March 13, 2012 3:26:15 PM<br>
Subject: [rabbitmq-discuss] Throttling when Fast Producer, Slow Consumer<br>
<br>
Hi All,<br>
<br>
What are the Rabbit "best practices" ways of handling a situation where the consumer is v-e-r-y slow and the producer is super-fast. IOW: I am trying to understand the best ways to throttle the producer in such a case. Assume that neither queue nor its topic exchange are durable.<br>
<br>
Can producer obtain information about the state of the queue, e.g., the number of unACKed messages, its size in bytes or number of messages, etc? Or is another approach indicated?<br>
<br>
Thanks very much.<br>
<br>
-Paul<br>
<br>
<br>
<br>
<br>
ATTENTION: -----<br>
<br>
The information contained in this message (including any files transmitted with this message) may contain proprietary, trade secret or other confidential and/or legally privileged information. Any pricing information contained in this message or in any files transmitted with this message is always confidential and cannot be shared with any third parties without prior written approval from Syncsort. This message is intended to be read only by the individual or entity to whom it is addressed or by their designee. If the reader of this message is not the intended recipient, you are on notice that any use, disclosure, copying or distribution of this message, in any form, is strictly prohibited. If you have received this message in error, please immediately notify the sender and/or Syncsort and destroy all copies of this message in your possession, custody or control.<br>
_______________________________________________<br>
rabbitmq-discuss mailing list<br>
<a href="mailto:rabbitmq-discuss@lists.rabbitmq.com" target="_blank">rabbitmq-discuss@lists.rabbitmq.com</a><br>
<a href="https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss" target="_blank">https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss</a><br>
_______________________________________________<br>
rabbitmq-discuss mailing list<br>
<a href="mailto:rabbitmq-discuss@lists.rabbitmq.com" target="_blank">rabbitmq-discuss@lists.rabbitmq.com</a><br>
<a href="https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss" target="_blank">https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss</a><br>
</div></div></blockquote></div><br></div>
<br>_______________________________________________<br>
rabbitmq-discuss mailing list<br>
<a href="mailto:rabbitmq-discuss@lists.rabbitmq.com">rabbitmq-discuss@lists.rabbitmq.com</a><br>
<a href="https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss" target="_blank">https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br>Eugene Kirpichov<br>Principal Engineer, Mirantis Inc. <a href="http://www.mirantis.com/" target="_blank">http://www.mirantis.com/</a><br>Editor, <a href="http://fprog.ru/" target="_blank">http://fprog.ru/</a><br>