[Date Prev][Date Next] [Chronological] [Thread] [Top]

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

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?

   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