[Date Prev][Date Next]
Re: (ITS#8444) Out-of-sync issue with memberOf overlay, Delta-syncrepl MMR and >2 nodes
- To: openldap-its@OpenLDAP.org
- Subject: Re: (ITS#8444) Out-of-sync issue with memberOf overlay, Delta-syncrepl MMR and >2 nodes
- From: firstname.lastname@example.org
- Date: Thu, 08 Jun 2017 17:36:19 +0000
- Auto-submitted: auto-generated (OpenLDAP-ITS)
A more self-contained log of the same issue, available at
(line numbers below are against current master, commit
There are some things that occur in all the failures I have seen so far:
- the server that received the operation (#1) sends the accesslog entry
with no CSN in the cookie, then another provider (#2) picks up this
message and relays it to its consumers, this one with a CSN in the
- a consumer picks up these two in short succession, in the log above,
processing of the one from #2 is finished first (they are being
Usually, once one of them gets processed, the new CSN should be noted
and the other threads should just skip it (syncrepl.c:943 and onwards).
In this one, having no CSN in the cookie seems to allow both to process
so far as to run syncrepl_message_to_op(), and one of them will then
inevitably fail to add the entry.
I don't understand yet why server #1 sends the operations without a CSN
in the cookie and (especially if I reorder the overlays to set up
memberof last), the race goes the other way around and the operation to
fail is the one from server #2.
My take on it was that in a delta-sync environment all entries would be
passed with a new CSN and that should end up in the cookie, allowing
syncrepl.c:986 to do its job.
Senior Software Engineer
Symas Corporation http://www.symas.com
Packaged, certified, and supported LDAP solutions powered by OpenLDAP