[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openldap-devel
Subject:    Re: How the backend knows it's being searched by syncprov?
From:       Howard Chu <hyc () symas ! com>
Date:       2004-12-04 22:46:03
Message-ID: 41B23E2B.6040607 () symas ! com
[Download RAW message or body]

Pierangelo Masarati wrote:

> Howard Chu wrote:
>
>> By the way, on the topic of syncrepl not working with backglue 
>> (ITS#3133) I think the solution here is to turn backglue into an 
>> overlay itself. Then it will be possible to arrange the order of the 
>> overlays on the stack and get the correct behavior. (I.e., currently 
>> backglue sits at the top of the execution stack, no matter what. In 
>> order for the syncprovider overlay to function correctly over a glued 
>> set of databases, syncprov must run at the top of the stack, with 
>> backglue presenting a view of a single database to it.)
>>
>> I envision changing the slapd.conf syntax with this change as well; 
>> the "subordinate" keyword would no longer be a globally recognized 
>> config keyword since it properly belongs to the backglue code. More 
>> likely, on the backend where "overlay glue" is configured, there will 
>> be a "subordinate <dn>" keyword specifying the suffix of some other 
>> backend to attach.
>
>
> Talkig about backglue reworking, one nice feature would be to split 
> the search operation handler into a sort of async search, i.e. a 
> search_init and a search_done operation with the original be_search 
> being a wrap that calls them in sequence.  Then backglue cold call all 
> search_init funcs on separate threads (the last could be the original 
> thread, and the other internal to the backglue instance) and then wait 
> for all threads to conclude.  This would mimic the current back-meta 
> behavior that spawns all searches simultaneously and sends the results 
> as they are returned.  This behavior should be configurable (e.g. I 
> don't see any potential performance improvements from spawning 
> multiple searches on different local instances of back-bdb), and the 
> number of local threads should be limited and configurable as well; if 
> there are no threads available, the searches could run serially as 
> they do now.
>
There is a slight complication here, to enforce the sizelimit of a 
search. Doing so requires all of the threads to increment a 
mutex-protected counter. We could just decide that only unlimited 
searches can be run in parallel.

-- 
  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support

[prev in list] [next in list] [prev in thread] [next in thread]