Hello- I was originally running FreeRADIUS 2.1.10 that came with CentOS 6.2, but I've since compiled my own 2.1.12. It looks like the thread management isn't quite working like I expect it to. If I flood the server with a ton of concurrent requests, it will spawn new threads up to "max_servers". Then, if I slowly hit the server with requests (to allow the cleanup mechanism time to work), the number of threads does not go down to "max_spare_servers". Has anyone else seen this? I instrumented threads.c, and it appears that a thread's "request" field doesn't get set to NULL after it handles a requests*. This is a problem, because the thread reaper uses the condition (handle->request == NULL) to mark a thread as THREAD_CANCELLED. I tested a small patch that appears to allow threads to cleanup, but I'm not sure if it's the right way to proceed with this. I tried to setup a pull request on github, but it looks like it tired to push my entire 2.1.x branch onto master (https://github.com/alandekok/freeradius-server/pull/51). I understand that you normally request that people provide the output of "radiusd -X", but "single server" mode handles threading differently (i.e. I don't see the problem). Basically, I'm using the default "thread pool" settings, but all my requests go through an rlm_perl "authorize" module that sets Auth-Type to 'Accept' (for testing). Let me know if you still want this output to see some of my settings. I also understand that some of this code has been re-worked for MASTER. I understand if you don't plan on releasing another 2.1.x, but I would appreciate it if you let me know if this is an appropriate fix on 2.1.x. We are probably going to stick with this series for a while. Thanks for your time- ~Matt * I added the following code in threads.c in thread_pool_manage() if (handle->request != NULL) { DEBUG2("Threads: thread %d NOT canceled, processing %i\n",handle->thread_num,handle->request->number); }