On 11/15/10 16:39 , rein(a)OpenLDAP.org wrote:
New syncprov consumers connecting to a forwarding server and
apperently up-to-date cookie will loose any mods that have already taken place
on the forwarding server if it itself is refreshing from its provider. This
should not be a problem if the forwarding server have a sufficiently large
syncprov log, but a fix for servers without is coming.
The currently committed fix
for this its leaves one problem open. If a
forwarding server restarts in the middle of the refresh phase, after
making some changes but before updating the csn, new consumers
connecting with an apparently up to date csn set after the server comes
up again will not know that the context is dirty and will loose these
changes. The same problem arise if the server restarts between the time
a locally initiated delete operation is performed in the database and
the accompanying csn set is saved.
A fix could be to always assume the context is dirty after start up, and
thereby forcing all clients to undergo the refresh phase even if they
are in sync until some operation that updates the csn set is performed.
An unnecessary refresh is probably better than loosing changes..