[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