search

bkjones / pyrabbit

A Python module to communicate w/ the RabbitMQ HTTP Management API
http://pyrabbit.readthedocs.org
BSD 3-Clause "New" or "Revised" License
97 stars 86 forks source link

Added tests and fix for empty queues occasionally omitting the 'messages' key #19

Closed ianawilson closed 10 years ago

ianawilson commented 10 years ago

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.

ianawilson commented 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.

bkjones commented 10 years ago

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.