Re: How the backend knows it's being searched by syncprov?

[Howard Chu <hyc@symas.com>]

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