Ok, assuming that you've run that query against the 5 stuck queues I
would expect the following results:
* if an active listener for a queue lives on one of compute hosts:
that queue was created by compute service initiating rpc command.
Since you didn't restart them during switchover, the comput
On 03/24/2014 01:27 PM, Dmitry Mescheryakov wrote:
I see two possible explanations for these 5 remaining queues:
* They were indeed recreated by 'compute' services. I.e. controller
service send some command over rpc and then it was shut down. Its
reply queue was automatically deleted, since it
I see two possible explanations for these 5 remaining queues:
* They were indeed recreated by 'compute' services. I.e. controller
service send some command over rpc and then it was shut down. Its
reply queue was automatically deleted, since its only consumer was
disconnected. The compute services
On 03/24/2014 02:59 AM, Dmitry Mescheryakov wrote:
Chris,
In oslo.messaging a single reply queue is used to gather results from
all the calls. It is created lazily on the first call and is used
until the process is killed. I did a quick look at oslo.rpc from
oslo-incubator and it seems like it u
Chris,
In oslo.messaging a single reply queue is used to gather results from
all the calls. It is created lazily on the first call and is used
until the process is killed. I did a quick look at oslo.rpc from
oslo-incubator and it seems like it uses the same pattern, which is
not surprising since o
Hi,
If I run "rabbitmqadmin list queues" on my controller node I see 28
queues with names of the form "reply_".
From what I've been reading, these queues are supposed to be used for
the replies to rpc "calls", they're not "durable', and they all have
auto_delete set to "True".
Given the ab
