[Date Prev][Date Next]
Re: (ITS#3671) disconnecting a syncrepl consumer deadlocks the provider
- To: Ralf Haferkamp <firstname.lastname@example.org>
- Subject: Re: (ITS#3671) disconnecting a syncrepl consumer deadlocks the provider
- From: Howard Chu <email@example.com>
- Date: Fri, 10 Jun 2005 23:26:27 -0700
- Cc: openldap-devel@OpenLDAP.org
- In-reply-to: <firstname.lastname@example.org>
- References: <email@example.com>
- User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050606
Ralf Haferkamp wrote:
> Ralf Haferkamp wrote:
>> On Thursday 28 April 2005 12:26, firstname.lastname@example.org 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
Symas: Premier OpenSource Development and Support