On 05/24/2016 07:00 PM, thierry bordaz wrote:
>
>
> On 05/24/2016 05:24 PM, Ludwig Krispenz wrote:
>>
>> On 05/24/2016 04:20 PM, thierry bordaz wrote:
>>> Hi Ludwig,
>>>
>>> Thanks for your explanation. The design looks very good. I think it
>>> would be good to put into the code (especially
>>> clcache_adjust_anchorcsn) the reference to the related design
>>> paragraph.
>>>
>>> There is something I do not understand in clcache_skip_change.
>>> My understanding is that this is the only place where the
>>> consumer_maxcsn is updated.
>>> But there are several conditions, if we decide to skip the update
>>> that the consumer_maxcsn is not updated.
>>> One of them is 'rid == buf->buf_consumer_rid'.
>>> Does that mean that the consumer_maxcsn remains unchanged for the
>>> RID of the consumer ?
>>
>> the condition is:
>> if( rid == buf->buf_consumer_rid && buf->buf_ignoreConsumerRID)
>>
>> so it will only be skipped if we determined that we don't need to
>> send anything for the consumers own rid
>
> Ok. I get it. thanks.
>
>
> An other question regarding the update of buf_consumer_ruv.
> My understanding is that it contains the initial consumer RUV.
> But later it is used in
> clcache_refresh_consumer_maxcsns/clcache_refresh_local_maxcsn to fill
> consumer_maxcsn.
>
> consumer_maxcsn are updated with the non skipped updates to reflect
> the current status of the consumer.
> But when consumer_maxcsns/clcache_refresh_local_maxcsn are called my
> understanding is that consumer_maxcsn are reset with buf_consumer_ruv
> (initial consumer RUV).
> Do I get it right ?
no :-) At least I think I have implemented it differently.
The consumer_maxcsn is set in /clcache_refresh_consumer_maxcsns(),
which is only called at the first buffer load, not at the relaod.
In //clcache_refresh_local_maxcsns it is only set if we have to add a
RID to the cscb list, but then no change for this rid was sent before.
/
/OK thanks for the explanation.
I was wondering if consumer_maxcsn could go back to buf_consumer_ruv but
in those cases (first load and first update on known RID) it is right.
Just minor comments on clcache_load_buffer.
/
* /'rc' should be tested against CLC_STATE_* values not 0.///
* /if clcache_initial_anchorcsn or clcache_adjust_anchorcsn return
let's say CLC_STATE_CSN_GT_RUV, in /clcache_load_buffer it will
return a CLC_STATE_* value not a DB_* value.
* clcache_refresh_consumer_maxcsns is only called at first load, why
not including/inlining it into clcache_initial_anchorcsn
Thanks
thierry
//
//
>
> thanks
> thierry
>>
>>>
>>> thanks
>>> thierry
>>>
>>>
>>>
>>>
>>> On 05/24/2016 09:22 AM, Ludwig Krispenz wrote:
>>>> Hi,
>>>>
>>>> On 05/23/2016 06:29 PM, thierry bordaz wrote:
>>>>>
>>>>>
>>>>> On 05/23/2016 03:06 PM, Ludwig Krispenz wrote:
>>>>>> This is the latest version of the "changelog buffer
processing"
>>>>>> fixes.
>>>>>>
>>>>>>
>>>>>>
https://fedorahosted.org/389/ticket/48766
>>>>>>
>>>>>>
https://fedorahosted.org/389/attachment/ticket/48766/0001-reworked-clcach...
>>>>>>
>>>>>>
>>>>>> The background for the fix is here, I would like to get feedback
>>>>>> on this as well to clarify what is unclear
>>>>>>
http://www.port389.org/docs/389ds/design/changelog-processing-in-repl-sta...
>>>>>>
>>>>>>
>>>>>
>>>>> Hello Ludwig,
>>>>>
>>>>> I have not yet reviewed the patch. I was looking at the design.
>>>>>
>>>>> Regarding your note:
>>>>>
http://www.port389.org/docs/389ds/design/changelog-processing-in-repl-sta....
>>>> If you refer to this part:
>>>>
>>>>
>>>> Special case: RID of the consumer in the current
>>>> replication session
>>>>
>>>> If the consumer in the replication session is also a master its
>>>> RID will be contained at least in the consumerRUV. If it is also
>>>> in the supplier RUV the question is if it should be considered in
>>>> the decision if updates should be sent. Normally a master has the
>>>> latest changes applied to itself, so there would be no need to
>>>> check and send updates for its RID. But there can be scenarios
>>>> where this is not the case: if the consumer has been restored from
>>>> an older backup the latest csn for its own RID might be older than
>>>> changes available on other servers.
>>>>
>>>> |NOTE: The current implementation ignores anchorCSNs based on the
>>>> consumer RID. If, by chance, the anchor csn used is older than
>>>> this csn, the changes will be sent, but they also ca nbe lost. |
>>>>
>>>> this referres to the "current" implementation before the fix,
the
>>>> doc started as a post-design doc, and it shoul dbe correctedd
>>>> with the fix the if the supplier has newer changes for the
>>>> consumerRID than the consumer it will be reflected in the anchor
>>>> csn calculation.
>>>>
>>>>
>>>>>
>>>>> It is said that the anchorCSN will not be the from the
>>>>> consumerRID. What is the mechanism that guaranty that the
>>>>> consumer will receive all the updates it was the originator ?
>>>>>
>>>>> thanks
>>>>> thierry
>>>>> --
>>>>> 389-devel mailing list
>>>>> 389-devel(a)lists.fedoraproject.org
>>>>>
http://lists.fedoraproject.org/admin/lists/389-devel@lists.fedoraproject.org
>>>>>
>>>>
>>>> --
>>>> Red Hat
GmbH,http://www.de.redhat.com/, Registered seat: Grasbrunn,
>>>> Commercial register: Amtsgericht Muenchen, HRB 153243,
>>>> Managing Directors: Paul Argiry, Charles Cachera, Michael Cunningham,
Michael O'Neill
>>>>
>>>>
>>>> --
>>>> 389-devel mailing list
>>>> 389-devel(a)lists.fedoraproject.org
>>>>
http://lists.fedoraproject.org/admin/lists/389-devel@lists.fedoraproject.org
>>>
>>>
>>>
>>> --
>>> 389-devel mailing list
>>> 389-devel(a)lists.fedoraproject.org
>>>
http://lists.fedoraproject.org/admin/lists/389-devel@lists.fedoraproject.org
>>
>> --
>> Red Hat
GmbH,http://www.de.redhat.com/, Registered seat: Grasbrunn,
>> Commercial register: Amtsgericht Muenchen, HRB 153243,
>> Managing Directors: Paul Argiry, Charles Cachera, Michael Cunningham, Michael
O'Neill
>>
>>
>> --
>> 389-devel mailing list
>> 389-devel(a)lists.fedoraproject.org
>>
http://lists.fedoraproject.org/admin/lists/389-devel@lists.fedoraproject.org
>
>
>
> --
> 389-devel mailing list
> 389-devel(a)lists.fedoraproject.org
>
http://lists.fedoraproject.org/admin/lists/389-devel@lists.fedoraproject.org
--
Red Hat
GmbH,http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Paul Argiry, Charles Cachera, Michael Cunningham, Michael
O'Neill
--
389-devel mailing list
389-devel(a)lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/389-devel@lists.fedoraproject.org