Open Stack

On 9 December 2013 01:43, Maru Newby <marun at redhat.com> 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 <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud