Thanks again for your help.<br><br>I have changed our polling strategy to read the message count from queue.declare, it makes more sense, obviously. I am using the Erlang client for the polling process. Previous answers such as 'not supported by the protocol' had put me in a 'dirty'-solution mindset, which explains the initial polling strategy (I used the first thing I had seen which gave me that sort of information).<br>
<br>The problem, as you have guessed already, is the number we really want is messages_unacknowledged. The number I get from the message count is messages_ready. I have been trying to make a producer process self-regulate its firing rate in case the consumers are not keeping up (to avoid ram exhaustion until the new persister comes along -- sorry Matthew :-)<br>
<br>Our Java consumers re-use their channels and consume messages 'by subscription' (it's obviously a better approach) without disconnecting at any point while the system is running. When even a single consumer connects to the queue in question (it's a multiple consumers for a single queue round-robin scenario) in this mode, all 'ready' messages become 'unacknowledged' messages, even though there is no way our Java threads have processed them this fast (do the messages go into an internal Java client buffer perhaps? or is this more of a responsibility transfer case?). So our polling process constantly gets zero (messages_ready), unless all consumers disconnect, in which case messages_ready shoots up to whatever messages_unacknowledged is when this happens. Is this what you would expect?<br>
<br>For our purposes, anything less than an ack means our consumers are not keeping up, so we have enforced a qos setting of 1 for each consumer. This way, the message_ready value returned to the polling process will, of course, be off by a few messages each time but, at least, its order of magnitude indicates if our consumers are keeping up.<br>
<br>Best regards,<br><br>Michael<br><br><div class="gmail_quote">2009/11/18 Michael Nacos <span dir="ltr"><<a href="mailto:m.nacos@gmail.com">m.nacos@gmail.com</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
thanks... more testing tomorrow<br><br><div class="gmail_quote">2009/11/18 Matthew Sackman <span dir="ltr"><<a href="mailto:matthew@lshift.net" target="_blank">matthew@lshift.net</a>></span><div><div></div><div class="h5">
<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div>On Wed, Nov 18, 2009 at 05:18:53PM +0000, Matthew Sackman wrote:<br>
> That's odd. However, you're really much much better off using<br>
> queue.declare to redeclare the existing queue - the declare-ok that you<br>
> get back contains the number of messages in the queue. This is a much<br>
> neater strategy than below. I would recommend you switch to using this<br>
> and repeat your test.<br>
<br>
</div>What's actually wrong with what you were doing is that the rabbitmqctl<br>
list_queues contains both the ready messages and the unack'd msgs (as<br>
well as uncommitted msgs). Thus if your consumers aren't acking msgs<br>
quickly enough (and have an unbounded qos setting) then it will appear<br>
that they're not keeping up. Use:<br>
<br>
rabbitmqctl list_queues name messages_ready messages_unacknowledged<br>
<div><div></div><div><br>
Matthew<br>
<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="http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss" target="_blank">http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss</a><br>
</div></div></blockquote></div></div></div><br>
</blockquote></div><br>