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, > >> > >
