Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Message-ID: <5582A857.3010001@open-net.biz>
Date: Thu, 18 Jun 2015 14:15:35 +0300
From: Kiril Stankov <kiril@open-net.biz>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
 rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: user@couchdb.apache.org
Subject: Re: CouchDB utc_id behavior
References: <24777207.252.1434465506965.JavaMail.Joan@RITA>
 <91DCA9B0-C1C1-432F-9D96-9FB6478F9D9F@open-net.biz>
 <CAGHTdUVFEqmYJWHbk_L78kv7Sw=_hQwg_r6Pr9DU4jhFOxbD1A@mail.gmail.com>
 <C16E2F9A-3024-44A5-897E-85B28611880A@open-net.biz>
 <7FB4C4CB-39CA-4897-8C18-7905AD0FA88B@apache.org>
In-Reply-To: <7FB4C4CB-39CA-4897-8C18-7905AD0FA88B@apache.org>
Content-Type: multipart/alternative;
 boundary="------------050303050209070907090807"

--------------050303050209070907090807
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Yes, the one from 12:59 is Ok. The one from 12:51 is not.
I will try now to delay the start of Couchdb with a minute after all 
other daemons started and see if it will help.
May be the hardware clock is "off" and it takes time until ntpd syncs it 
and CouchDB starts in between.


------------------------------------------------------------------------
*With best regards,*
Kiril Stankov,

On 17-Jun-15 6:41 PM, Adam Kocoloski wrote:
> Do you happen to know if either one of these was correct-ish? Do you see any timestamps in the access logs that are also “off”?
>
> 05188de92ef02f -> Mon, 15 Jun 2015 12:51:05 GMT
> 05188e0805067f -> Mon, 15 Jun 2015 12:59:42 GMT
>
> Adam
>
>> On Jun 16, 2015, at 12:44 PM, Kiril Stankov <kiril@open-net.biz> wrote:
>>
>> Ubuntu, couch 1.6.1, apt-get update few days ago.
>> -- 
>> Regards,
>>
>> Kiril Stankov,
>> OpenNet Software ltd.
>>
>>
>> -------- Original Message --------
>> From: Nick North <north.n@gmail.com>
>> Sent: June 16, 2015 7:41:50 PM GMT+03:00
>> To: user@couchdb.apache.org, Joan Touzet <wohali@apache.org>
>> Subject: Re: CouchDB utc_id behavior
>>
>> Thanks for the correction Joan - I had forgotten about the possibility of
>> the clock jumping backwards. However, in this case the obvious causes don't
>> seem to apply, and I'm slightly at a loss. I can't hypothesise a mechanism
>> that would cause now() to return these times if the OS clocks are in sync.
>> Kiril - what setup are you running on?
>>
>> Nick
>>
>> On Tue, 16 Jun 2015 at 15:48 Kiril Stankov <kiril@open-net.biz> wrote:
>>
>>> Hi,
>>> As I wrote, ntpd is running and both machines have synced time. They were
>>> not down for weeks.
>>> --
>>> Regards,
>>>
>>> Kiril Stankov,
>>> OpenNet Software ltd.
>>>
>>>
>>> -------- Original Message --------
>>> From: Joan Touzet <wohali@apache.org>
>>> Sent: June 16, 2015 5:38:28 PM GMT+03:00
>>> To: user@couchdb.apache.org
>>> Subject: Re: CouchDB utc_id behavior
>>>
>>> now() is not guaranteed to be monotonically increasing if the system
>>> clock rolls backwards, which various things can cause.
>>>
>>> You should look into setting up ntpd for your two machines at the very
>>> least.
>>>
>>> -Joan
>>>
>>> ----- Original Message -----
>>>> From: "Nick North" <north.n@gmail.com>
>>>> To: user@couchdb.apache.org
>>>> Sent: Monday, June 15, 2015 12:14:50 PM
>>>> Subject: Re: CouchDB utc_id behavior
>>>>
>>>> The utc_id algorithm uses Erlang's now() function for generating
>>>> timestamps. This is guaranteed to be monotonic increasing, but not
>>>> necessarily to be in very close correspondence with the operating
>>>> system
>>>> clock all the time, especially if you call it very frequently.
>>>> However, I'm
>>>> surprised that calls seconds apart are giving this problem. Are your
>>>> machines VMs? There can be clock problems when they are suspended and
>>>> reactivated, with clocks initially having the time when the machine
>>>> was
>>>> suspended, and then jumping forward, but that's unlikely if they are
>>>> in
>>>> fairly constant use. For what it's worth, I use utc_id timestamps for
>>>> sorting documents, and have not seen this problem, but that doesn't
>>>> help
>>>> you very much.
>>>>
>>>> Nick
>>>>
>>>> On Mon, 15 Jun 2015 at 16:42 Kiril Stankov <kiril@open-net.biz>
>>>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> nope, this is not the case.
>>>>> The newer document has older ID, this is the problem.
>>>>>
>>>>> 05188de92ef02f < 05188e0805067f
>>>>>
>>>>> But
>>>>> 05188de92ef02f
>>>>> was created after
>>>>> 05188e0805067f
>>>>>
>>>>>
>>>>>
>>> ------------------------------------------------------------------------
>>>>> *With best regards,*
>>>>> Kiril Stankov,
>>>>>
>>>>> On 15-Jun-15 6:08 PM, Alexander Shorin wrote:
>>>>>> Time resolution is in microseconds, so difference in one second
>>>>>> generated notable "leap" forward.
>>>>>> --
>>>>>> ,,,^..^,,,
>>>>>>
>>>>>>
>>>>>> On Mon, Jun 15, 2015 at 5:10 PM, Kiril Stankov
>>>>>> <kiril@open-net.biz>
>>>>> wrote:
>>>>>>> Hi all,
>>>>>>>
>>>>>>> I have two CouchDB (v1.6.1) servers, fully synchronized between
>>>>>>> them
>>>>>>> (master-to-master).
>>>>>>> The uuids algorithm is utc_id.
>>>>>>> The servers are synchronized via ntp and there is practically no
>>>>>>> time
>>>>> offset
>>>>>>> between them.
>>>>>>> I notice a strange behavior of the ID's of newly posted
>>>>>>> documents.
>>>>>>> In some cases, posting to server1, will generate ID, which is
>>>>>>> later
>>>>> than a
>>>>>>> subsequent post to server 2.
>>>>>>> E.g., posting to server 1 generates ID:
>>>>>>> 05188e0805067f_1
>>>>>>> and then, few seconds later, posting to server 2 generates:
>>>>>>> 05188de92ef02f_2
>>>>>>> As you see, the timestamp of the second message is earlier than
>>>>>>> the
>>>>> first
>>>>>>> (_1 & _2 are suffixes for the two servers).
>>>>>>> This is causing me a big mess, as I use the timestamp to sort
>>>>>>> and order
>>>>>>> documents.
>>>>>>> Any idea why this happens?
>>>>>>> Can someone, please, shed more light on how CouchDB "reads" the
>>>>>>> time
>>>>> for the
>>>>>>> generation of the ID?
>>>>>>> Or if you have an idea what may be causing this behavior.
>>>>>>>
>>>>>>> Thanks in advance!
>>>>>>>
>>>>>>>
>>> ------------------------------------------------------------------------
>>>>>>> *With best regards,*
>>>>>>> Kiril Stankov,
>>>>>>>
>>>>>


--------------050303050209070907090807--