hyc@OpenLDAP.org wrote:
Full_Name: Howard Chu Version: HEAD/RE24 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.94.188.8) Submitted by: hyc
In syncrepl_updateCookie() the cookie received from the provider is dup'd as-is. If the provider is stopped and restarted, this same cookie will be sent back on the next refresh attempt. In refreshAndPersist mode the cookies sent from the provider will only contain a single CSN; CSNs from other MMR servers are omitted. During a restart, because the consumer sends a cookie with only one CSN, the provider will consider the consumer out of date.
A fix is coming shortly.
For the record...
I spent some time considering whether this should actually be fixed in the provider or the consumer. I decided on fixing in the consumer for the sake of network bandwidth/efficiency - in persist mode, a cookie may be sent with every single write operation. Generally only one CSN will be relevant for any given write op, so it would be a waste to send all of the other unchanged CSNs every time.
On the consumer side, the consumer must always send all of the context info it has available. This might involve more volume in a request but ordinarily the actual consumer request is only a tiny fraction of the total network traffic.
Purists might say that this goes against RFC4533 which states that consumers should treat sync cookies as opaque items, but the OpenLDAP implementation has always relied on exact knowledge of the sync cookie format; this was always required in order to support cascaded replication if nothing else. Also this ITS is specific to MMR, which is not addressed at all in RFC4533.