[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

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 :)


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