(ITS#6489) replication problem - new valuable information, nearly solved

[frank.offermanns@caseris.de]

Hello,

after digging very deep to find out, what the problem could be, I found 
interesting facts:
1)
With our new client-DLL the master/slave replication problem seems to be 
solved. (our old DLL wrote each attribute separately, our new writes all 
in a row), but
2)
So I switched back to Master/Master in hope that this works also, but I 
found out the following.
- my client-DLL first create a new user entry and then it does a add with 
all attributes.
- at the second master server I activated replication log and saw the 
following short message (the important part is surounded with ________):
"do_syncrep2: rid=001 
cookie=rid=001,sid=001,csn=20100914081312.596142Z#000000#00
1#000000
syncrepl_entry: rid=001 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)
syncrepl_entry: rid=001 be_search (0)
syncrepl_entry: rid=001 cn=10008,o=BAD_CLIENT3,ou=users,o=caesar
slap_queue_csn: queing 09369668 20100914081312.596142Z#000000#001#000000
syncprov_matchops: skipping original sid 001
slap_graduate_commit_csn: removing 09377b10 
20100914081312.596142Z#000000#001#00
0000
syncrepl_entry: rid=001 be_add cn=10008,o=BAD_CLIENT3,ou=users,o=caesar 
(0)
slap_queue_csn: queing 09369668 20100914081312.596142Z#000000#001#000000
syncprov_matchops: skipping original sid 001
slap_graduate_commit_csn: removing 09377b10 
20100914081312.596142Z#000000#001#00
0000
do_syncrep2: rid=001 cookie=
syncrepl_entry: rid=001 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY)
__________________________________________________________________
dn_callback : new entry is older than ours 
cn=10008,o=BAD_CLIENT3,ou=users,o=cae
sar ours 20100914081312.596142Z#000000#001#000000, new 
20100914081312.100780Z#00
0000#001#000000
___________________________________________________________________
syncrepl_entry: rid=001 be_search (0)
syncrepl_entry: rid=001 cn=10008,o=BAD_CLIENT3,ou=users,o=caesar
syncrepl_entry: rid=001 entry unchanged, ignored 
(cn=10008,o=BAD_CLIENT3,ou=user
s,o=caesar)"

Is it a bug, or a result of a bad time synchronization (I only have 
windows standard time synchronization)
But if it would be a time synchronization problem, in recent posts I asked 
when the time synchronization is important. I got the answer (if 
understood correctly) that
the time synchronization only matters if concurrent write operations are 
made.  So it should'nt be an issue here, since I made my write operations 
only at one master. 

Best regards,
Frank