[rabbitmq-discuss] Improved queue status

[Chris Van Pelt]

Yeah, I picked 1000 because that seemed like a reasonable max... at some
point the TCP buffer fills up?  Basic.qos sounds like it is the answer to
all my concerns.  I look forward to seeing this feature!

Cheers,

Chris

On Fri, Oct 3, 2008 at 4:03 PM, Matthias Radestock <matthias at lshift.net>wrote:

> Chris,
>
> Chris Van Pelt wrote:
>
>> if I do a passive declare on a queue my message count is 0 even though I
>> may have 1000 items waiting in the TCP buffer of my consumer.  This becomes
>> a big issue if my items are taking more than 5 seconds to complete.  The
>> reason I want this information is so that I can intelligently add more
>> consumers as load fluctuates.
>>
>
> By the time there are 1000 items in the TCP buffer of the existing consumer
> isn't it too late to add more consumers?
>
>  The simplest way to solve this issue in my mind would be for rabbitmq to
>> be able to return the number of un-acked items in a given queue.  Has there
>> been any discussion of this?
>>
>
> With basic.qos (which has been on our todo list for a while - sorry, some
> other items have higher priority) one can limit the number of unacknowledged
> messages per channel. Down to one if you wanted to, i.e. a client would have
> to ack a message before the server sends it another one.
>
> That provides a fine degree of control over the maximum number of messages
> to keep in flight, and allows messages to stay queued up where they belong -
> at the server. It also makes the message count returned by queue.declare a
> reasonable parameter to guide consumer creation in the way you envisage.
>
>  Also, rabbitmq kicks ass!!
>>
>
> Thanks. Glad you like it. Keep the questions coming.
>
>
> Regards,
>
> Matthias.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20081005/b7c1941e/attachment.htm