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: Configuration of replication consumers
Date Wed, 09 Jan 2013 11:15:09 GMT
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 ?


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


Mime
View raw message