> On 27 Jul 2016, at 4:05 AM, Dmitry Mescheryakov <[email protected]> > wrote: > > > > 2016-07-26 2:15 GMT+03:00 Sam Morrison <[email protected] > <mailto:[email protected]>>: > 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
_______________________________________________ OpenStack-operators mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
