[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: (ITS#3671) disconnecting a syncrepl consumer deadlocks the provider
- To: Ralf Haferkamp <rhafer@suse.de>
- Subject: Re: (ITS#3671) disconnecting a syncrepl consumer deadlocks the provider
- From: Howard Chu <hyc@symas.com>
- Date: Fri, 10 Jun 2005 23:26:27 -0700
- Cc: openldap-devel@OpenLDAP.org
- In-reply-to: <200505191532.43390.rhafer@suse.de>
- References: <200505191532.43390.rhafer@suse.de>
- User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050606
Ralf Haferkamp wrote:
hyc@symas.com wrote:
> Ralf Haferkamp wrote:
>> On Thursday 28 April 2005 12:26, rhafer@suse.de wrote:
>>> I just tested HEAD again. Now it shows a different behaviour.
>>> The first ldapadd that I started after pulling the network plug
>>> still stops progressing after a few entries. The improvement is
>>> that the provider keeps processing search requests and
>>> addtional add request (only the first ldapadd is locked).
> There is no way to avoid this first request getting locked.
Really? That'd be bad. Might it be possible to have the syncprov
overlay always queue the results in syncops->s_res a let a separate
thread send them to the consumers? That should decouple the thread
that's handling the ADD/MOD Request and the syncrepl Provider. Is
that feasible and would it be worth the effort (I'd guess that'll add
quite a bit of overhead to the syncprov overlay).
I agree that always queueing would be better. I haven't had time to look
into this yet though.
--
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
http://www.symas.com http://highlandsun.com/hyc
Symas: Premier OpenSource Development and Support