On 13.01.11 21.48, hyc@symas.com wrote:

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.

That implies that all servers must be interconnected in order to sync, which is a requirement I really hope nor think you want to introduce..

In any properly configured setup where the sessionlog is used I assume it is used on all the servers, and that the log is large enough to hold all changes occurring during reasonable consumer downtimes. In which case there will rarely be any refresh phases and wiping of the queue.

My fix was more concerned with ensuring that replaying the log gave a correct synchronization than to use it in all possible cases.

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.

Yes, I've been wondering about that I too. I'm inclined to say that all entries in the log should hold the entire csn set as if was when the entry was added. The log could be initialized with an empty log entry holding the startup csn set, and kept in change fifo order.

Mods without csn (i.e refresh mods) could then be stored on the log as well. But once one of them reaches the head of the list and gets removed then the list must be truncated up to the point where all remaining entries have a csn. The log should be reinitialized with the current csn set if the truncation caused it to end up empty.

New consumers can replay the log if they present a csn set greater or equal to the set at the head of the log list.

Rein