https://bugs.openldap.org/show_bug.cgi?id=10080
--- Comment #9 from Hiroyuki Homma homma@allworks.co.jp --- Created attachment 978 --> https://bugs.openldap.org/attachment.cgi?id=978&action=edit Patch file
Hi Ondřej, I have created a patch, although it is not complete. Could you review it and let me know if there are any problems?
(1) When the glue overlay is not explicitly configured, the refresh stage of persistent sync request now completes successfully. I made the following changes for this case:
syncprov_search_cb: Set op->o_no_subordinate_glue=1 on completion of search to prevent the glue overlay from processing subordinates. syncprov_op_search: Returns SLAPD_NO_REPLY if a refreshDone intermediate message was successfully sent. glue_op_search: Do not send any response if the search resut for one backend is SLAPD_NO_REPLY. glue_sub_search: Once the search for one backend is complete, remove any callbacks added while processing that backend.
With these changes, sync requests will only search the primary backend. This is sufficient for our use case as we do not need to replicate the subordinate database.
(2) When the glue overlay is explicitly configured above the syncprov overlay, modifications on the subordinate backend will no longer cause a segfault. The changes for this case are:
syncprov_matchops: Saves the request DN before the rwm overlay rewrites it, and use the saved DN to get the entry after the modification. rwm_response: Rewrite back the DN and attributes of the added entry op->ora_e.
Although these changes avoid the segfault, the following issues remain:
- Modifications on the subordinate backend will result in an error 'got empty or invalid syncUUID' on the consumer, because overlay_entry_get_ov() does not return the entryUUID attribute when the backend is back-ldap.
- When the syncprov overlay is enabled on the remote databese, the refresh stage of persistent search never completes if the provider contextCSN is ahead of the consumer contextCSN. This is because an unnecessary Sync Request control is sent to the remote server.
- If I use back-relay pointing to back-mdb instead of back-ldap, modifications on the subordinate database are replicated as expected, but the contextCSN is not updated properly.
It seems that the syncprov overlay does not work well with the ldap or relay backend. This seems to be a separate issue from the glue and rwm overlay issue.
I have confirmed that this patch passes all of the 'make test', but I am not sure if it does not adversely affect other operations...
Regards,