directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kiran Ayyagari <kayyag...@apache.org>
Subject Re: Configuration of replication consumers
Date Wed, 09 Jan 2013 13:08:37 GMT
On Wed, Jan 9, 2013 at 4:45 PM, 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).
>
> we have all the configuration options needed to support this, all we need
now is some
code to hook them together

> 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
>
>


-- 
Kiran Ayyagari
http://keydap.com

Mime
View raw message