Open Stack

What happens in a very fast system if two sub-processes create a message 
at the same time and therefore contain the same timestamp?

david

On 25/04/2013 15:41, Davanum Srinivas wrote:
> Now i see it. you are right. we don't need it.
>
> -- dims
>
> On Thu, Apr 25, 2013 at 10:26 AM, Simo Sorce <simo at redhat.com> wrote:
>> On Thu, 2013-04-25 at 10:12 -0400, Davanum Srinivas wrote:
>>> Please see below:
>>
>>> Dropping the counter/nonce for the first cut sounds good to me.
>>
>> Ok then I will just drop it, I am writing some code to play with and the
>> counter is just annoying and requires more state to be kept. I'll change
>> the page and get rid of it.
>>
>>>>> 5. Can we please use ISO 8601 timestamps instead of unixtime?
>>>>
>>>> At the moment I am experimenting with python time.time() values that
>>>> have sub-second resolution. ISO8601 timestamp do not really make sense
>>>> here, This timestamp is not for human consumption, and having to parse
>>>> it back and forth is unnecessary. Also ISO 8601 does not have sub-second
>>>> resolution, while we may want to use it so that we can also drop the
>>>> counter as the chance of 2 message being sent to the same target to end
>>>> up with the same timestamp are low, and we can make it 0 by simply
>>>> keeping around the old timestamp and increasing it by 1 if the new one
>>>> matches exactly.
>>>
>>> ISO8601 here is not for human consumption. In my environment, we make
>>> sure all components are synced using NTPD and we like adding code to
>>> reject messages outside of a time window.
>>
>> And you really should use NTP, but what has that to do with how you
>> represent time in the metadata?
>>
>> time.time() gives you the numbers of seconds since the epoch in UTC, int
>> his case with subseconds as well. If you can help me find better
>> language to define the format I'll be happy to. But I think number of
>> seconds since the epoch is fine, we do not need a structured date format
>> here.
>>
>> Simo.
>>
>> --
>> Simo Sorce * Red Hat, Inc * New York
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>