[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Syncrepl and chain Overlay
Ralf Haferkamp wrote:
On Friday 10 December 2004 17:18, Pierangelo Masarati wrote:
[moved from -software to -devel]
Anyway, I've removed all the syncrepl related stuff from my config and
inserted a normal referral into the database. With that the chain overlay
seems to work fine. So seems to be indeed some integration issue with
syncrepl.
The chain overlay responds when the server is __returning__ a referral, so
there shouldn't be any interaction with syncrepl.
What I tried to achieve was to let the chain overlay chase the "updateref"
referral that is returned by the syncrepl consumer when it receives write
operations (a modify in my case). And this somehow does not work with the
current code.
As I already wrote I think it's because when send_ldap_result() with the
"updateref" referral is called from fe_op_modify() no response callback is
registerd in op->callback. I just veryfied again by adding some printf
debugging to the code.
That's correct; in fact, the overlay is called (actually, is stacked on
the callback sequence) only if execution gets to the be_<write>() call,
which doesn't occurr if the DSA shadows that portion of the naming
context. In this case, the global overlay approach would be the best,
but I need to check it out. For instance, in case of adds, callbacks
likely don't get to see the entry at all, or if they do, it diddn't
undergo all the massaging provided by slap_mods_opattrs() (which may be
a good thing), and it doesn't make it to slap_mods2entry(). In this
sense, I'm considering the opportunity to anticipate as much as possible
of this massaging __before__ calling the global database operation hook
(which can be intercepted by overlays) at the cost of wasting few cycles
if the DSA ends up being a shadow. Maybe we can even move the updateDN
and so stuff to an overlay, to be stacked onto shadow databases :)
p.
SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497