[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: ITS#3971 Fix
> In comments to ITS#3971, it is stated that backglue works only with
> global rwm. In fact, backglue doesn't work with global rwm at all;
test039 uses the glue infrastructure with a global rwm to glue together
several proxies, and has been working fine (at least from this point of
view) for months.
> see
> my previous message
> (http://www.openldap.org/lists/openldap-software/200510/msg00019.html).
> That hang is caused by double (chained) invocation of rwm_op_search on a
> single op instance; rwm callback (which is a singleton) is being
> inserted to a callback chain twice (rwm.c:729), thus turning it into a
> cycle, and making cleanup code (result.c:462) enter an infinite loop. My
> second patch offers a kind of workaround for this: iterate over callback
> chain, and if rwm callback instance is already there, do nothing.
>
> Even with this patch backglue and global rwm do not work together in
> subordinate relays configuration. That's because glue makes no chance
> for a global rwm instance to act on subordinates, after relaying is
> done. The nature of this misbehaviour seems to be a little bit deeper,
> so I didn't investigate this.
The problem with slapo-rwm is that it was designed when overlays didn't
provide a consistent cleanup infrastructure, so I decided to let it
__change__ the Operation's data (in a consistent fashion) since the
overlay wouldn't have gotten a chance to have a second look at it, say, in
case of errors or abnormal termination conditions. If I were to redesign
it now, I'd make it alter temporary data, which would then be destroyed
after completion or after an error.
Unfortunately, I don't want to redesign it now because we're about to
enter production with a system that heavily relies on it and doesn't
require glueing. I'll keep it as a future homework when this project
freezes.
p.
--
Pierangelo Masarati
mailto:pierangelo.masarati@sys-net.it
SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497