Alan DeKok wrote:
Joe Maimon <jmaimon@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