Resolves: bug 459850FedoraDirSvr_1_1_2_RC2FedoraDirSvr_1_1_2_20080904FedoraDirSvr_1_1_2

Bug Description: replica_generate_next_csn opcsn adjustment errors during concurrent MMR load
Reviewed by: nhosoi (Thanks!)
Fix Description: In csngen_adjust_time, even if the time diff <= remote_offset, we still need to
keep track of it and use it so that we generate CSNs that have the same
timestamp as the remote CSN.  We use the local_offset to store that time diff.
This sort of fits the semantics of local_offset as the diff is usually caused
by the sampled time update thread running slightly behind, not in sync with the remote server.
The code in _csngen_adjust_local_time will take the local_offset into
consideration when updating the sampled time.  One thing we have to be careful
of is to _not_ reset the sequence number if the new generated time will be the
same as the old generated time.  If the old time is the same as the new time,
we have to preserve the sequence number so that the next CSN generated will be greater than the previous one.
The sequence number must be reset if
the time was increased.  The right thing to do is set the sequence number to
the remote sequence number + 1, in the case where we have advanced the time.
If we have not advanced the time, we can't make the sequence number less,
because we would then issue CSNs less than or equal to CSNs already issued.

In csngen_adjust_time, we have to take care to reset the seqnum properly - if the new timestamp is greater than the old timestamp, we
set the sequence number to be the remote + 1, regardless of whether or not the
remote seq is < or > than the current seq.

With this patch, running the replication stress test, I do not see any time
skew, I do not see any generate_next_csn error messages, I do not see any
duplicate or retrograde CSN issuance.
Platforms tested: RHEL5, Fedora 8, Fedora 9
Flag Day: no
Doc impact: no

0 files changed, 0 insertions, 0 deletions