directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lécharny <elecha...@gmail.com>
Subject Re: Detecting staled replicas
Date Mon, 14 Jan 2013 14:59:45 GMT
Le 1/14/13 3:41 PM, Howard Chu a écrit :
> Kiran Ayyagari wrote:
>>
>>
>> On Sun, Jan 13, 2013 at 11:17 PM, Emmanuel Lécharny <elecharny@gmail.com
>> <mailto:elecharny@gmail.com>> wrote:
>>
>>     Hi guys,
>>
>>     I'm currently working on a system to detect the staled replicas (ie
>>     replicas that have been once connected, disconnected, and haven't be
>>     reconnected, or have tried to reconnect with an empty cookie).
>>
>>     The idea is to create a thread associated with the LdapServer that
>>     periodically check all the registered replicas, and discard those
>> whic
>>     have not been read for more than a period of time. I was thinking
>> that
>>     checking every hour, and discarding all the replicas that are 2 days
>>     behind would be enough (the suggested values are the default
>> values, it
>>     will be configurable, of course).
>>     Detecting that a replica has not been read for more than N days
>> is just
>>     a matter of reading the oldest modification it stores in its
>> associated
>>     Journal.
>>
>> what I would like to see is a policy per replica rather than single
>> policy for
>> all replicas
>> initially we apply the default values when a log gets created but we
>> allow the
>> admin
>> to change them if needed. We need two new configuration ATs in the
>> config schema
>> to map the time and/or count based detection.
>
> I don't understand why you are maintaining a distinct log per replica.
> Any provider should need only one log for the entire context, and each
> consumer should track their own position in the log (using the sync
> cookie).

This is a temporary solution. We have discussed lengthly about the fact
that we need only one single log, but the current code is not build this
way. Let's say we *know* that our current code works, and that we are to
release urgently because of errors in the configuration, so we don't
have any timeframe to switch to something different.

We are buying time, here :/


-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com 


Mime
View raw message