rein@OpenLDAP.org wrote:

On 09.12.10 09.09, masarati@aero.polimi.it wrote:

...

I think the best (blind) fix consists in only performing that test if sl_mincsn is assigned a value; something like

I'm looking at an extended fix. The problem with the current implementation is that is assumes the entries arrives in CSN order, which isn't necessarily true in a MMR configuration.

My fix drops sl_mincsn, keeps the log queue in CSN order and compares with the head entry. It also wipes the log if it receives any changes without CSN (i.e during refresh).

I'm not sure this latter is a good idea, in an MMR setup. In that case, we should ensure that only CSNs matching the current SID are added to the log, and we should always leave the log intact. I.e., the server is always authoritative about its own writes.

But this kind of begs the question of whether the log should actually maintain N mincsns, one for each known SID, the same way we do now for contextCSN.

There might still be a theoretical problem there, if the sid of an entry in the log is not in the set sent by the consumer. But since we know they have the same number of CSNs this can only happen during initial setup of a multi-master configuration. In which case the admins real problem is that he didn't bring the servers online in a controlled order..

Rein