[Date Prev][Date Next]
Re: (ITS#6716) syncprov sessionlog 'sl_mincsn' not assigned a value.
- To: openldap-its@OpenLDAP.org
- Subject: Re: (ITS#6716) syncprov sessionlog 'sl_mincsn' not assigned a value.
- From: rein@OpenLDAP.org
- Date: Fri, 14 Jan 2011 17:26:42 GMT
- Auto-submitted: auto-generated (OpenLDAP-ITS)
On 13.01.11 21.48, email@example.com wrote:
> rein@OpenLDAP.org wrote:
>> On 09.12.10 09.09, firstname.lastname@example.org 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.