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

[Eugene Kirpichov]

You can also monitor the number of unconfirmed messages (do not confuse
with "unacked") to prevent broker overload. See "publisher confirms".

On Wed, Mar 14, 2012 at 1:03 PM, stone <zmstone at gmail.com> wrote:

> 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
>>
>
>
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>
>


-- 
Eugene Kirpichov
Principal Engineer, Mirantis Inc. http://www.mirantis.com/
Editor, http://fprog.ru/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20120314/a183c2d5/attachment.htm>