Re: (ITS#6716) syncprov sessionlog 'sl_mincsn' not assigned a value.

[hyc@symas.com]

Rein Tollevik wrote:
> On 13.01.11 21.31, hyc@symas.com wrote:
>> cmikk@qwest.net wrote:
>>> On Sun, Dec 12, 2010 at 06:22:38PM +0100, Rein Tollevik wrote:
>>>> On 11/19/10 23:55 , cmikk@qwest.net wrote:
>>>>
>>>>> will evaluate to true in cases where it should not. A quick fix would be to
>>>>> compare directly against the CSN of the sessionlog's head:
>>>>
>>>> An extended version of this fix, which also ensures that the
>>>> sessionlog is kept in csn order, is now in head.  Please test,
>>>> syncprov.c revision 1.320.
>>>
>>> Looks good to me. Thank you.
>>>
>>> I discovered this bug while trying to reproduce ITS#6717.
>>>
>>> I've attached a patch to that ITS which appears to fix
>>> that problem. If you have the time, I'd appreciate some
>>> feedback on that patch. The issue makes it very inefficient
>>> to run a slave in refreshOnly mode with a multimaster /
>>> mirrormode master.
>>>
>>> Best Regards,
>>
>> The current code is broken.
>
> Which current code?  My patch for this its, or his patch for its#6717?

We're only talking about this specific ITS here, and that comment applied to 
the ITS before my last patch. I reopened the ITS, patched again, and then 
marked it Test again.

>>> Other than the patch I suggested (using the list head's
>>> CSN value directly), I can think of two other approaches:
>>>
>>> 	1) When adding an entry to the sessionlog, check
>>> 	if sl_mincsn is empty. If it is, update sl_mincsn
>>> 	to the new entry's CSN.
>>>
>>> 	2) When initializing the sessionlog, set sl_mincsn
>>> 	to the maximum contextCSN value of the underlying
>>> 	database.
>>>
>>> #2 seems ideal from an efficiency standpoint, although it
>>> differs from the algorithm the current code appears to be
>>> intended to implement.
>>
>> We should have gone with #2. The problem scenario:
>>
>> 1: Provider and consumer in sync, both started fresh, sessionlog is empty.
>> 2: stop consumer
>> 3: write on provider
>> 4: start consumer
>>
>> Result: the sessionlog is ignored, because the sl_head is newer than the
>> consumer's cookie.
>>
>> After the consumer syncs, you can repeat steps 2-4 and see that the sessionlog
>> is used from then on.
>
> Initializing sl_mincsn from the maximum csn won't do much good here, as
> long as the (current) requirement to use the log is that the consumers
> mincsn is greater or equal to sl_mincsn.  Assuming there is more than
> one csn in the set that is..

> Initializing with the minimum csn should cause the current log to be
> used in this scenario.  But, if the provider restarts between 3 and 4 it
> would incorrectly appear that replaying the log would be sufficient to
> bring the consumer in sync.   A situation far worse than doing a refresh
> when replaying the log would have been sufficient.

Which is why I chose the maximum CSN. It will work fine in most cases. In the 
rare cases where it doesn't work, the log will be ignored and no harm is done.

I.e., when writes are always received in order, the max CSN is the only one 
that matters.

> More on possible fixes in my reply to your other message.
>
> Rein
>


-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/