rlm_sql: zero session length
joe at vrspace.org
Mon Jun 17 18:05:20 CEST 2013
Arran Cudbard-Bell wrote:
> On 17 Jun 2013, at 13:49, Arran Cudbard-Bell <a.cudbardb at freeradius.org> wrote:
>>> Why is this if statement there anyway, some buggy NASes?
>> Almost certainly.
>>> If so, why not just let user handle it in unlang?
>> The rlm_sql module was written before unlang, so that's why the code is there.
>>> IMHO that needs to be removed, or if written for a good reason, made configurable. With rfc-compliant default:)
>> I'll remove it. It's easy enough to do the check in unlang.
> It's already gone in 3.0, and you can disable it if you build from source in 2.x.x.
> It should probably be left as is for 2.2.1 for users which rely on this behaviour.
In the meantime, I've analyzed what I have.
Including 2 and 3 source.
And the catch is, I should never ever get that warning, because it activates only 'if (numaffected < 1)'.
IOW, when update is executed, but no rows were updated.
I have 8% sessions with the same starttime and stoptime.
And of those, 0.13% gave us 'zero session length' warning.
Turned on sqltrace, and I do see insert for start packet first, then update for stop.
One right after another, amongst all other requests.
But does that mean insert was executed first, and then update?
I think it was only scheduled to execution in that order.
Local scheduler or a database hickup might delay first query just a few milliseconds too long...
Wonders of parallelization;)
More information about the Freeradius-Devel