Re: (ITS#5985) replication lockout with syncrepl

[quanah@zimbra.com]

--On Monday, March 02, 2009 7:59 PM +0000 ando@sys-net.it wrote:

> quanah@OpenLDAP.org wrote:
>> Full_Name: Quanah Gibson-Mount
>> Version: 2.3/2.4/HEAD
>> OS: Linux 2.6
>> URL: ftp://ftp.openldap.org/incoming/
>> Submission from: (NULL) (75.111.29.239)
>>
>>
>> I noticed back in testing with OpenLDAP 2.3 that if a master gets a high
>> rate of changes, and you have 3+ replicas, usually 2 replicas will end
>> up getting all of the changes while the 3rd+ replicas have to wait until
>> those 2 finish before getting changes.  If the high rate of changes goes
>> on for a long enough period of time, this can cause the other replicas
>> to get so far out of sync that it is more efficient to reload them than
>> to wait on them to re-sync.  I discussed this with Howard, and in
>> reviewing the code, he sees there's an underlying design issue with
>> updates that is causing this.  His comments:
>>
>> Once a thread for a psearch wakes up, it sends all the changes that were
>> queued so it may hog an entire thread for a long time before the next
>> psearch comes off the queue
>
> Is this supposed to hit 2.4 as well, as you indicated in the ITS'
> "Version"?

Yes.  It affects OL2.3, OL2.4, and remains this way in current HEAD.

--Quanah



--

Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra ::  the leader in open source messaging and collaboration