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

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

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.

Ciao, p.

   SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497