On 10/29/2012 09:47 PM, Brian Candler wrote:
Any ideas what the problem might be? This is freeradius-2.2.0 plus the redis patches.
The log message does say "rlm_rediswho"
Well, I just wondered under what circumstances the server might stop answering queries.
If all the threads are blocked, primarily.
If a particular server thread becomes unresponsive, is there some functionality in the core which kills that thread and starts a new one? Or would the server eventually grind to a halt?
As Alan says, killing threads is highly problematic because they share your memory space (you risk destroying a thread which has a lock held, or is mutating a shared data structure). It's one of the unfortunate side effects of shared-state concurrency. Maybe one day STM will save us all, but I have my doubts... ;o) Basically anything you do from FreeRADIUS needs to be "virtually non-blocking". There's no absolute answer to this, but I like to use "50 milliseconds" as a good rule of thumb. If it takes less than that, you're relatively safe. If it takes more than that, well - start thinking about your offered load and thread pool size very carefully... If you can catch it in the "locked" state, you might be able to break in with GDB and inspect the state. Most likely there's a deadlock hidden somewhere inside or "underneath" rlm_redis (e.g. in hiredis). I'll be honest - I started to get quite excited about redis, but the state of the client APIs is rapidly putting me off :o(