TIMEOUT requests && then Duplicate Requests && then Threads block
jmaimon at ttec.com
Fri Oct 14 23:16:09 CEST 2005
Alan DeKok wrote:
> Joe Maimon <jmaimon at ttec.com> wrote:
>> request->options |= RAD_REQUEST_OPTION_STOP_NOW;
>>/* This is the line I have added?? */
>> request->finished = TRUE;
> And the server will likely core dump.
> The "finished" flag is used also as a "it's OK to free() the
> request" flag. If the thread is still accessing it, it's a SEGV.
> The solution is to take those "dead" requests, and move them to a
> *separate* list, which is cleaned up periodically. That way old
> requests don't prevent new ones from coming in.
> Alan DeKok.
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
No segvs, instead the requests are being cleaned up.
Examining the request structure suggests that the TIMEOUT requests never
hit rad_decode() or rad_respond()
(username is null .....)
I am working on the theory now that they were never dequeued.
This appears to be a thread spawning issue since it doesnt appear to
happen under -s
How can I tell how many entries are in the queue?
(theory: at the time of the semaphore there are more requests in the
queue than waiting threads)
does not appear to return anything other than an ever incrementing number.
More information about the Freeradius-Devel