| 2013-05-15 02:33:56 |
Michael H Wilson |
bug |
|
|
added bug |
| 2013-05-16 20:29:02 |
Michael H Wilson |
summary |
qpid fanout queue reconnect breaks on busy qpid servers |
qpid fanout queue reconnect race condition |
|
| 2013-05-21 22:55:43 |
Michael H Wilson |
summary |
qpid fanout queue reconnect race condition |
Trying to reconnect to an exclusive queue doesn't work |
|
| 2013-05-21 23:54:48 |
Michael H Wilson |
description |
It looks to me like qpidd decides queue exclusivety with a session rather than a client IP or username or anything like that. I'm not really sure, but I know that when you reconnect and the old queue hasn't been auto-deleted yet you will get an error from the qpid server indicating that the queue is exclusive and you are not it's exclusive owner.
The solution is fairly simple, we need to override the reconnect method in the FanoutConsumer class of the qpid impl and use a new name instead of re-useing the old one.
The other option would be to ditch the old consumers on reconnect and create new ones, but I think the latter is cleaner. |
It looks to me like qpidd decides queue exclusivety with a session rather than a client IP or username or anything like that. I'm not really sure, but I know that when you reconnect and the old queue hasn't been auto-deleted yet you will get an error from the qpid server indicating that the queue is exclusive and you are not it's exclusive owner. I found this bug originally on qpid, but after reading over the AMQP spec I believe it probably applies to rabbit as well.
The solution is fairly simple, we need to override the reconnect method in the FanoutConsumer class of the qpid impl and use a new name instead of re-useing the old one.
The other option would be to ditch the old consumers on reconnect and create new ones, but I think the latter is cleaner. |
|
| 2013-05-22 16:49:33 |
Michael H Wilson |
description |
It looks to me like qpidd decides queue exclusivety with a session rather than a client IP or username or anything like that. I'm not really sure, but I know that when you reconnect and the old queue hasn't been auto-deleted yet you will get an error from the qpid server indicating that the queue is exclusive and you are not it's exclusive owner. I found this bug originally on qpid, but after reading over the AMQP spec I believe it probably applies to rabbit as well.
The solution is fairly simple, we need to override the reconnect method in the FanoutConsumer class of the qpid impl and use a new name instead of re-useing the old one.
The other option would be to ditch the old consumers on reconnect and create new ones, but I think the latter is cleaner. |
It looks to me like qpidd decides queue exclusivety with a session rather than a client IP or username or anything like that. I'm not really sure, but I know that when you reconnect and the old queue hasn't been auto-deleted yet you will get an error from the qpid server indicating that the queue is exclusive and you are not it's exclusive owner. I found this bug originally on qpid, but after reading over the AMQP spec I believe it probably applies to rabbit as well.
The solution is fairly simple, we need to override the reconnect method in the FanoutConsumer class and use a new name instead of re-useing the old one.
The other option would be to ditch the old consumers on reconnect and create new ones, but I think the latter is cleaner. |
|
| 2013-06-03 13:53:06 |
Michael H Wilson |
description |
It looks to me like qpidd decides queue exclusivety with a session rather than a client IP or username or anything like that. I'm not really sure, but I know that when you reconnect and the old queue hasn't been auto-deleted yet you will get an error from the qpid server indicating that the queue is exclusive and you are not it's exclusive owner. I found this bug originally on qpid, but after reading over the AMQP spec I believe it probably applies to rabbit as well.
The solution is fairly simple, we need to override the reconnect method in the FanoutConsumer class and use a new name instead of re-useing the old one.
The other option would be to ditch the old consumers on reconnect and create new ones, but I think the latter is cleaner. |
According the the AMQP spec an exclusive queue should only ever be usable by a single client. In our AMQP impls (rabbit and qpid) we try to reconnect to our exclusive fanout queues when connection drops. This works most of the the time because the server auto-delete's the queue quickly enough that by the time you reconnect you are able to create a "new" queue with the same name as the old one. However, in busy environments where the broker isn't able to delete the queue quickly enough you will run into errors about not being able to bind to an exclusive queue.
The solution is fairly simple, we need to override the reconnect method in the FanoutConsumer class and use a new name instead of re-useing the old one.
The other option would be to ditch the old consumers on reconnect and create new ones, but I think the latter is cleaner. |
|
| 2013-06-03 13:53:35 |
Michael H Wilson |
summary |
Trying to reconnect to an exclusive queue doesn't work |
We try to reconnect to fanout (exclusive) queues |
|
| 2013-06-04 22:52:14 |
Michael H Wilson |
description |
According the the AMQP spec an exclusive queue should only ever be usable by a single client. In our AMQP impls (rabbit and qpid) we try to reconnect to our exclusive fanout queues when connection drops. This works most of the the time because the server auto-delete's the queue quickly enough that by the time you reconnect you are able to create a "new" queue with the same name as the old one. However, in busy environments where the broker isn't able to delete the queue quickly enough you will run into errors about not being able to bind to an exclusive queue.
The solution is fairly simple, we need to override the reconnect method in the FanoutConsumer class and use a new name instead of re-useing the old one.
The other option would be to ditch the old consumers on reconnect and create new ones, but I think the latter is cleaner. |
According the the AMQP spec an exclusive queue should only ever be usable by a single client. In the qpid amqp impl we try to reconnect to our exclusive fanout queues when connection drops. This works most of the the time because the server auto-delete's the queue quickly enough that by the time you reconnect you are able to create a "new" queue with the same name as the old one. However, in busy environments where the broker isn't able to delete the queue quickly enough you will run into errors about not being able to bind to an exclusive queue.
The solution is fairly simple, we need to override the reconnect method in the FanoutConsumer class and use a new name instead of re-useing the old one.
The other option would be to ditch the old consumers on reconnect and create new ones, but I think the latter is cleaner. |
|
| 2013-06-04 22:54:15 |
OpenStack Infra |
oslo: status |
New |
In Progress |
|
| 2013-06-04 22:54:15 |
OpenStack Infra |
oslo: assignee |
|
Michael H Wilson (geekinutah) |
|
| 2013-06-26 11:41:22 |
OpenStack Infra |
oslo: status |
In Progress |
Fix Committed |
|
| 2013-07-17 12:45:48 |
Thierry Carrez |
oslo: status |
Fix Committed |
Fix Released |
|
| 2013-07-17 12:45:48 |
Thierry Carrez |
oslo: milestone |
|
havana-2 |
|
| 2013-10-17 09:19:04 |
Thierry Carrez |
oslo: milestone |
havana-2 |
2013.2 |
|
