On 12/04/17 21:37, Eric Covener wrote:
Any chance the logs also report write timeouts that precede this?  Are
there "similar" threads waiting for writability of actual response
data (e.g. ap_invoke_handler in the stack)
I'm not aware of any write timeouts in the httpd logs but then, this was a productive system with a "low" log level. Unfortunately I have no longer access to them. I still have the stacks (printed with gstack) of all the HTTPD processes, there I see most of the worker threads are idle (waiting in ap_queue_pop_something ()), but some are indeed also blocked in a poll() triggered by apr_rflush() (flushing data to the client). But since they are worker threads this is just normal behaviour, I'd say. The problem here is that the listener thread is blocked, which should never happen. I think if the listener thread is calling a function that might block, it should dispatch this task to another thread instead doing it itself. Or the function start_lingering_close_nonblocking() *really* has to be nonblocking.


Reply via email to