https://bugs.openldap.org/show_bug.cgi?id=9705
--- Comment #1 from Howard Chu hyc@openldap.org --- Eugeny Gil wrote:
Hi guys,
There is an issue with syncrepl and syncprov working together in parallel. The issue can be seen in provider LDAP server logs of test059-consumer-config. For linux this problem does not cause the test to malfunction, but it may cause replication to malfunction on other systems (or possibly on linux in a different situation from the test). In case of OpenVMS we have this issue.
The problem is detected under the following circumstances, followed by a step-by-step description of the actions in test 059 that lead to malfunction:
I cannot comment on your actual problem, but your analysis is incorrect.
this registers new syncInfo structure with the parameter rid=002 inside the syncrepl engine. Should also be added info into cookies of this structure but this is the issue. The info about {1}mdb,cn=config,cn=consumer is added to the cookie of structure with rid=001 (!!!). Thus the cookie about {1}ldif is overrides by this new cookie data. It can be seen in provider server logs (was run on linux):
That is not what the logs say.
……
61275c7d ldif_back_add: "olcDatabase={1}mdb,cn=config,cn=consumer"
61275c7d oc_check_required entry (olcDatabase={1}mdb,cn=config,cn=consumer), objectClass "olcMdbConfig"
……
61275c7d slap_get_csn: conn=1007 op=3 generated new csn=20210826091853.649104Z#000000#001#000000 manage=1
61275c7d slap_queue_csn: queueing 0x7fcdf4106bc0 20210826091853.649104Z#000000#001#000000
61275c7d ldif_write_entry: wrote entry "olcDatabase={1}mdb,cn=config,cn=consumer"
61275c7d ldif_back_add: err: 0 text:
61275c7d send_ldap_result: conn=1007 op=3 p=3
61275c7d send_ldap_result: err=0 matched="" text=""
61275c7d conn=1007 op=3 syncprov_matchops: recording uuid for dn=olcDatabase={1}mdb,cn=config,cn=consumer on opc=0x7fcdf4001608
……
61275c7d slap_graduate_commit_csn: removing 0x7fcdf4106bc0 20210826091853.649104Z#000000#001#000000
61275c7d conn=1004 op=1 syncprov_sendresp: cookie=*rid=001*,sid=001,csn=20210826091853.649104Z#000000#001#000000
61275c7d conn=1004 op=1 syncprov_sendresp: sending LDAP_SYNC_ADD, dn=olcDatabase={1}mdb,cn=config,cn=consumer
……
rid=002 should be there!
No. The rid identifies a consumer. If you search back in your log for the operations on conn=1004 in this case, you'll see that the consumer on that connection used rid=001, therefore rid=001 is what must be sent back to it.
Whatever other problem you may be seeing, this log snippet is not evidence of any bug.