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