Ubuntu, couch 1.6.1, apt-get update few days ago. -- Regards, Kiril Stankov, OpenNet Software ltd.
-------- Original Message -------- From: Nick North <[email protected]> Sent: June 16, 2015 7:41:50 PM GMT+03:00 To: [email protected], Joan Touzet <[email protected]> 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 <[email protected]> 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 <[email protected]> > Sent: June 16, 2015 5:38:28 PM GMT+03:00 > To: [email protected] > 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" <[email protected]> > > To: [email protected] > > 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 <[email protected]> > > 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 > > > > <[email protected]> > > > 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, > > > >> > > > > > > > > >
