hi
I face a weird situation with my LDAP syncrepl consumer [1],
please advise ...
on "delete" sync state control receiving, I'm trying to search for accesslog object with the just deleted object to use it in further processing, but it is not available yet
though if I set delay (sleep) for 1 sec just before the search, then I successfully receive the object
so, is it intended behavior?
here is this search: https://github.com/z-eos/regather/blob/master/lib/App/Regather.pm#L439
[1] https://github.com/z-eos/regather
On Mon, Sep 12, 2022 at 11:55:06PM +0300, Zeus Panchenko wrote:
hi
I face a weird situation with my LDAP syncrepl consumer [1],
please advise ...
on "delete" sync state control receiving, I'm trying to search for accesslog object with the just deleted object to use it in further processing, but it is not available yet
though if I set delay (sleep) for 1 sec just before the search, then I successfully receive the object
Hi Zeus, are you sure you are contacting the same server? If configured, the accesslog entry gets committed during write processing, so you shouldn't be able to detect any delay at all.
Also looking at the code, I think you're a little confused. The server isn't sending LDAP_SYNC_DELETE for attribute deletion as you believe but because the entry doesn't match your search anymore (maybe it was deleted, moved away from the scope, no longer matches the filter or ACLs now hide it from your view). Also if you're interested in accesslog, you might want to switch to syncrepl on the log db instead.
I suppose you'll try to remember the cookie eventually so you can resume. Then it's also worth keeping in mind that in OpenLDAP's implementation you cannot treat the cookie as opaque string when doing refreshAndPersist in multiprovider environments, merging the ones you receive in persist mode, rather than discarding the old one every time you've received a new.
Regards,
openldap-technical@openldap.org