Hi there,<br><br>I know there is nothing in the protocol supporting book-keeping information such as queue lengths etc.<br>However, basic get ok returns a message count which is more or less correct, except when consumers are<br>
still attached to the queue (there&#39;s no connection closing until the very end of the experiment, we are reusing<br>a few connections). I have been using rabbitmqctl to check to the queue lengths and according to rabbitmqctl<br>
the consumer processes do not keep up with the message generation rate but the external poller process gets<br>a message count of zero. As soon as the consumers disconnect, message count reports the right number of<br>unhandled messages again.<br>
<br>Is this something that you have seen before/would expect? My polling strategy is: consume a single message<br>from a queue with no_ack=false, read the message count, send no ack and disconnect.<br><br>regards, Michael<br>
<br>