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

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?