directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pierre-Arnaud Marcelot ...@marcelot.net>
Subject Re: Configuration of replication consumers
Date Wed, 09 Jan 2013 13:58:55 GMT

On 9 janv. 2013, at 12:15, Emmanuel Lécharny <elecharny@gmail.com> wrote:

> Le 1/8/13 3:59 PM, Pierre-Arnaud Marcelot a écrit :
>> Hi guys,
>> 
>> While I was writing the UI for the replication consumers configuration, I came into
an interesting issue.
>> 
>> I opened a JIRA for it : DIRSERVER-1789 - Changes to an existing replication consumer
may not be taken into account
>> https://issues.apache.org/jira/browse/DIRSERVER-1789
>> 
>> Here's what's happening:
>> 
>> 1/ We configure on Server A a replication consumer over Server B, and we restart
Server A for the modifications to take effect.
>> 
>> 2/ Replication takes place and an entry is created on Server B under the branch "ou=consumers,
ou=system". This entry corresponds to the replication consumer of Server A and stores some
information about it (like the search base, referral information, etc.).
>> This information is required because Server B needs to maintain a queue of modifications
to send to the consumer of Server A (especially in the Refresh Only mode or when a disconnection
occurs).
>> 
>> 3/ We reconfigure on Server A the replication consumer and change one of its values
(search base, attributes, etc.) and we restart Server A for the modifications to take effect.
>> 
>> 4/ The replication is resumed, but, here's the problem... The configuration items
are not modified on the corresponding entry on Server A under "ou=consumers, ou=system"...
>> 
>> 
>> We thought about a solution to this problem with Kiran yesterday and we came up with
two solutions.
>> 
>> Solution 1:
>> We need a mechanism to detect any change of replication consumer configuration at
the boot of ApacheDS (probably by holding a copy of each replication consumer configuration
entry somewhere and comparing it to the current configuration).
>> If a difference is detected, then the server has to reset the replication consumer
and start the replication from scratch.
>> 
>> Solution 2:
>> We don't implement a change detection mechanism, but we include a specific attribute
in the entry of the replication consumer to indicate to the server that it has been updated
and should be reset (with a restart of the replication from scratch).
>> 
>> 
>> My personal preference is Solution 1, which is a little bit harder to implement on
the server side, but easier to use on the client side.
>> 
>> 
>> The impact on Server B by these two solutions is exactly the same. A new entry will
be created under "ou=consumers, ou=system" and the previous entry for the replication consumer
will be deleted once we reach the usual timeout.
>> 
>> What do you think of these solutions?
>> Which one would you pick?
> 
> This is not simple... At first, I thought that solution 1 was better :
> no need to transmit anything more than what the RFC says, we just detect
> the change when the consumer reconnects. the problem is that we have no
> idea if the consumer is the one which was registred before, unless it
> says so. The transmitted data are the connection itself (IP, port), plus
> the search request. If the config has changed, this is a new replication
> request, and we must delet the old one. Now, how do we determinate if
> the consumer was previously connected and should be deleted ? I don't
> see any way to do that efficiently.
> 
> I'm thinking on a third solution there : we regularly check the
> 'sleeping' registred consumers on the producer, and if they haven't be
> active for more than a determinated period of time, we simply delete
> them (say, after 7 days).
> 
> This way, we don't store many entries for nothing, and we don't need to
> send extra informations.
> 
> Does it sounds reasonnable ?

Actually, that's not really a third solution but a required path to make solution 1 or 2 work.

That's exactly what I meant by "and the previous entry for the replication consumer will be
deleted once we reach the usual timeout."

Kiran and I thought that process was already in place in the server, but it turns out it isn't.

Regards,
Pierre-Arnaud


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


Mime
View raw message