RE: overlay and failover

["Howard Chu" <hyc@highlandsun.com>]

> -----Original Message-----
> From: Pierangelo Masarati [mailto:ando@sys-net.it]
> Sent: Monday, March 08, 2004 10:05 PM

> > The current approach means, of course, that you should not call a
> > function that will wind up re-invoking the current overlay function,
> > otherwise it will loop until the stack overflows.
>
> The problem is much simpler and trickier: if I try to send
> a result, the over_back_response() casts a BackendInfo *, which
> is really pointing to a slap_overinst *, into a slap_overinfo *
> and dies because what it pretends to be a list of slap_overinst *
> is actually bogus.  I see a few approaches:

The over_back_response() no longer does this; now over_op_func() explicitly
stores the slap_overinfo* in the callback's sc_private so it is reliably
accessible in over_back_response(). I think this takes care of sending
results from inside the overlay. But you still need to restore the correct
bd_info field before calling any backend.c functions.

> 1) return a specific error code (e.g. SLAP_CB_FAILOVER) which
> instructs over_op_func() to issue the error
> 2) rearrange slap_overinfo so that it actually is a slap_overinst
> plus the BackendInfo data structure so that either cast succeeds

I thought about this option, but it looks too messy to me at the moment.
Maybe it will become clearer later...

> 3) as you said, when calling a result function from inside
> an overlay, restore the correct op->o_bd->bd_info field, relying
> on the fact that if I'm inside an overlay function I can do it
> safely :)
>
> With option 3 my rwm overlay works like a charm
> also when an error occurs :)

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support