Hi all, I am using OpenStack Folsom with nova-network. In the logs I observed some RPC call timeouts during associate_floating_ip. I assume the timeout is actually a timeout experienced by RabbitMQ when trying to push the associate_floating_ip message to a chosen consumer and not a timeout from nova.network.API when trying to publish the associate_floating_ip message in the first place. Could this be possible? If so, how can I tell what consumer RabbitMQ chose (i.e. the "down" consumer)?
Furthermore, I'm seeing multiple thousands of exchanges (associate_floating_ip was called a lot) with UUIDs as their names. Is it possible that these exchanges were created to receive responses from the down consumer? Who is responsible for cleaning these exchanges up? I do see an "auto-delete" flag set to true. Finally, it appears that when an RPC call times out, the original message, at least is some cases like 'network.hostname' queue, is left in place to be consumed when a consumer is available. This seems like an odd design--if I take corrective action in response to an RPC timeout, I don't think I want that message processed ever. I am somewhat new to message queues so feel free to simply share links that might explain some of these observations. Thanks in advance. Mat
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
