On Wed, Jan 9, 2013 at 4:45 PM, Emmanuel Lécharny <[email protected]>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
