TIMEOUT requests && then Duplicate Requests && then Threads block

[Joe Maimon]

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)

lrad_hash_table_num_elements(thread_pool.queue)

does not appear to return anything other than an ever incrementing number.

Joe