On 9 December 2013 01:43, Maru Newby <[email protected]> wrote: > >>> If AMQP service is set up not to lose notification, notifications will be >>> piled up >>> and stress AMQP service. I would say single node failure isn't catastrophic. >> >> So we should have AMQP set to discard notifications if there is noone > > What are the semantics of AMQP discarding notifications when a consumer is no > longer present? Can this be relied upon to ensure that potentially stale > notifications do not remain in the queue when an agent restarts?
If the queue is set to autodelete, it will delete when the agent disconnects. There will be no queue until the agent reconnects. I don't know if we expose that functionality via oslo.messaging, but it's certainly something AMQP can do. >> listening: when an agent connects after an outage, it first starts >> listening, then does a poll for updates it missed. > > Are you suggesting that processing of notifications and full state > synchronization are able to cooperate safely? Or hoping that it will be so > in the future? I'm saying that you can avoid race conditions by a combination of 'subscribe to changes' + 'give me the full state'. -Rob -- Robert Collins <[email protected]> Distinguished Technologist HP Converged Cloud _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
