Open Stack

On 8/5/13 8:40 AM, "Julien Danjou" <julien at danjou.info> wrote:

>On Mon, Aug 05 2013, Thomas Maddox wrote:
>
>> Thinking about it, the latter option seems to describe a very real
>>concern
>> going forward that didn't occur to me when I was wandering around the
>> code. Specifically regarding option 2a, if message 2 arrives at CM
>>before
>> message 1 because it ended up on a faster route, then message 1 will
>> overwrite the metadata from message 2 and we record an incorrect state.
>> Isn't the nature of network comms for messages at the application layer
>>to
>> potentially be out of order and in the case of UDP, even lost? What is
>>the
>> leftover purpose of resource-show when we can't trust its output to
>> represent the actual state of whatever resource is in question? It seems
>> that timestamps could be used to prevent overwriting of the latest state
>> by checking that the incoming notification doesn't have a timestamp less
>> than the already recorded one. I hope I'm not seeing a problem that
>> doesn't exist here or misunderstanding something. If so, please correct
>>me!
>
>No you're absolutely right. Checking the timestamp before we override
>resource metadata would be a great idea. Would you mind reporting a bug
>first, so we can schedule to fix it?

It's probably good to keep in mind that AMQP does not guarantee order of
delivery. 
At any point in the future, if we need to rely on ordering, we will need
to check timestamps too.

>
>-- 
>Julien Danjou
>;; Free Software hacker ; freelance consultant
>;; http://julien.danjou.info