[Openstack-operators] [oslo] RabbitMQ queue TTL issues moving to Liberty

Sam Morrison sorrison at gmail.com
Tue Jul 26 23:20:34 UTC 2016


> On 27 Jul 2016, at 4:05 AM, Dmitry Mescheryakov <dmescheryakov at mirantis.com> wrote:
> 
> 
> 
> 2016-07-26 2:15 GMT+03:00 Sam Morrison <sorrison at gmail.com <mailto:sorrison at gmail.com>>:
> The queue TTL happens on reply queues and fanout queues. I don’t think it should happen on fanout queues. They should auto delete. I can understand the reason for having them on reply queues though so maybe that would be a way to forward?
> 
> Or am I missing something and it is needed on fanout queues too?
> 
> I would say we do need fanout queues to expire for the very same reason we want reply queues to expire instead of auto delete. In case of broken connection, the expiration provides client time to reconnect and continue consuming from the queue. In case of auto-delete queues, it was a frequent case that RabbitMQ deleted the queue before client reconnects ... along with all non-consumed messages in it.

But in the case of fanout queues, if there is a broken connection can’t the service just recreate the queue if it doesn’t exist? I guess that means it needs to store the state of what the queue name is though?

Yes they could loose messages directed at them but all the services I know that consume on fanout queues have a re sync functionality for this very case.

If the connection is broken will oslo messaging know how to connect to the same queue again anyway? I would’ve thought it would handle the disconnect and then reconnect, either with the same queue name or a new queue all together?

Sam


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20160727/b8b68f7a/attachment.html>


More information about the OpenStack-operators mailing list