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.
