On Fri, Jan 17, 2020 at 07:42:31PM +0100, Michael Ströder wrote:
I guess you mean conflicts when generating entryCSN values? Good point.
It never hits the other server's overlay stack, so syncprov won't see the modification and won't forward it to any of its active consumers. Many other things in syncprov will break for the same reason.
The problem to be solved:
If a back-sock listener configured as overlay also needs access to some LDAP entries then I have a loop in the frontend LDAP thread pool. This possibly blocks. So my plan was to setup a shadow slapd and access the database via this (separate LDAP thread pool).
In the simplest form there would only be read access. But OATH-LDAP's HOTP validator would also need to update some attributes.
Maybe use 'readonly on' on the database or send referrals towards the writable slapd.
You then still have the HOTP validator send writes to the writable replica so you are back to the original problem if all worker threads are busy in slapo-sock already.