openstack team mailing list archive

[Sylvain Bauza <sylvain.bauza@xxxxxxxxxxxx>]

Have you tried to look at the RabbitMQ web interface to see what could 
be stuck ?
Activating it is quite straightforward, as per Ops Guide :
http://docs.openstack.org/trunk/openstack-ops/content/logging_monitoring.html#rabbitmq

-Sylvain


Le 12/04/2013 17:48, Lowery, Mathew a écrit :
> 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@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp