Closed ianawilson closed 10 years ago
For a little more info, it looks like empty queues will stop sending messages
after a while if they remain empty. They will start returning messages
again after you ask the empty queue for messages. Then, after a while, they seem to stop sending the key out again.
Thanks for this, and sorry for the delayed reply.
I can't seem to replicate this in any post-3.0.0 version of RabbitMQ, though I can't find a specific reference to this issue being 'fixed' in the changelog (http://www.rabbitmq.com/changelog.html).
In the past, I have tried not to consider pyrabbit as something that would actually alter what the API would do, but rather a nicer, easier to use interface for interacting with it. So, just like the webui talking to the API directly has to account for the missing key, so would an application talking to the api via pyrabbit.
I'm open to debate on this, but it can quickly become ambiguous where the line is drawn between what is a shortcoming of an api, and what is a preference of an api consumer. I'd also like very much to avoid the condition where applications become dependent on a preference that is later obviated by evolution of the api. The cleanest solution that should result in the most stable api-supporting module is to try hard to track the api, and as little else as possible.
Sometimes, it seems, Rabbit will omit the
messages
key from/api/queues/vhost/name
for empty queues.I don't really understand this behavior, and its not documented in RabbitMQ's HTTP API docs, but I've observed it a few times, both with pyrabbit and with the Network tab of the Chrome Inspector while using the HTTP Management webui. Since their webui doesn't seem to mind its omission, I figured pyrabbit should also not mind this, and assume that the queue is empty when
messages
is not reported.