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.

Ok. Then I'd have a config keyword something like
   subordinate <dn> [async]
to indicate that searches to this backend can/should be run in a 
separate thread. I believe it may be sufficient for the glue overlay to 
just check for available threads and submit the background operations to 
the existing thread pool. Then you just bump up the number of threads in 
slapd overall if you want. Sound ok?

maybe
   glue-sub <dn>      for regular backends and
   glue-async <dn>   for asynchronous backends

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