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? Thanks! Pierre-Arnaud
