[rabbitmq-discuss] Throttling when Fast Producer, Slow Consumer

stone zmstone at gmail.com
Wed Mar 14 09:03:52 GMT 2012


Hi

You can retrieve the information of an existing queue by declaring it with
passive option set to true.
I had the same problem as you do, and found this link the other day,
haven't tried out though.

http://stackoverflow.com/questions/1038318/check-rabbitmq-queue-size-from-client

BRs
/stone

2012/3/14 Jerry Kuch <jerryk at vmware.com>

> Hi, Paul:  You could use the management HTTP API to keep a track on
> queue depths and then have your producer dynamically adjust its
> behavior if it notices that consumption isn't keeping up, but you
> should really think about whether this is something you want to do.
>
> It ends up building a lot of of hand holding awareness of the messaging
> mechanics into your endpoint applications, which in some ways goes against
> the spirit of using a messaging service in between your producers and
> consumers in the first place.  You might be better off monitoring the
> system, and spinning up additional consumers to drain especially busy
> queues than building the sort of logic you describe...
>
> Best regards,
> Jerry
>
> ----- Original Message -----
> From: "Paul M. Bell" <pbell at syncsort.com>
> To: rabbitmq-discuss at lists.rabbitmq.com
> Sent: Tuesday, March 13, 2012 3:26:15 PM
> Subject: [rabbitmq-discuss] Throttling when Fast Producer, Slow Consumer
>
> Hi All,
>
> 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.
>
> 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?
>
> Thanks very much.
>
> -Paul
>
>
>
>
> ATTENTION: -----
>
> 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.
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20120314/f6182458/attachment.htm>


More information about the rabbitmq-discuss mailing list