Phil Mayers wrote:
Where did we get with this? At the moment, I can't proceed with a migration to 3.x in the absence of last return code, and I don't want to use my local patch if it's not going upstream.
I just merged it.
It doesn't look easy to do this with an xlat; the "last" return code only exists as local variable(s) in modcall_* functions, so we'd need to grow the request object to store it. Even the highest-prio code only exists on the relevant modcall_stack_entry_t struct, and an xlat has no easy way to know the position in the modcall stack/tree.
For 3.1, we'll add the modcall stack, and current stack index to the REQUEST structure. It's very useful to have it there. It allows things like proxying in a module, and then resumption from where it left off.
I would appreciate a steer; we have serious problems with load spikes and time spent on this in 2.x is wasted IMO, so I need to get onto 3.x and then tackle the problem.
Grab v3.0.x now, it has your patch. The load spikes are a bit different, of course. I suspect that 3.0 will have better debugging than 2.0. You should also be able to set triggers (SNMP or "exec") on certain events. If there isn't a trigger for an event you want, adding one is ~2 lines of code. Alan DeKok.