[prev in list] [next in list] [prev in thread] [next in thread]
List: freeradius-devel
Subject: Re: Module return codes
From: Alan DeKok <aland () deployingradius ! com>
Date: 2013-10-21 13:10:24
Message-ID: 526527C0.2040707 () deployingradius ! com
[Download RAW message or body]
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.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic