Debugging request handlers in hunchentoot

Question

At some point after my webapp starts up, I start getting Can't handle a new request, too many request threads already warnings from hunchentoot, with the corresponding http-service-unavailable response in the browser. Problem is that this never returns back to normal request processing, i.e. as if some request handler "hangs" without ever returning so when enough of those handlers are called, the maximum thread count is hit and stays that way. How can I get a list of current threads and examine the current call stack of one of them so that I can examine where is the problem? Does this even make sense? I get no other warnings. Any advice on how to start investigating?

Answer 1

I'm seeing the same behaviour with SBCL (on Windows). The problem seems to be the client is sending the Keep-Alive header, which hunchentoot honours by keeping the worker-thread running after the request has been processed. It sits idle awaiting further input but unfortunately it seems that the socket never times out and the thread never gets terminated so I very rapidly hit a non-functioning server. This seems to be a Windows-specific problem because the same code works fine under (Ubuntu) Linux.

@Paralife you can pause a thread and check its call stack with

(bt:interrupt-thread thread #'break)

You can get the thread you want using (bt:all-threads).