[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: firstname.lastname@example.org
- Date: Fri, 14 Jan 2011 20:11:21 GMT
- Auto-submitted: auto-generated (OpenLDAP-ITS)
Rein Tollevik wrote:
> On 13.01.11 21.31, email@example.com wrote:
>> firstname.lastname@example.org wrote:
>>> On Sun, Dec 12, 2010 at 06:22:38PM +0100, Rein Tollevik wrote:
>>>> On 11/19/10 23:55 , email@example.com 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
>>> #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
> More on possible fixes in my reply to your other message.
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/