directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pierre-Arnaud Marcelot>
Subject Configuration of replication consumers
Date Tue, 08 Jan 2013 14:59:38 GMT
Hi guys,

While I was writing the UI for the replication consumers configuration, I came into an interesting

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

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?


View raw message