Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Subject: Re: blocking listener thread during SSL shutdown
To: dev@httpd.apache.org
References: <16eafa88-43b2-2af4-04f0-759af7d89fd3@ergon.ch>
 <9779c1d9-b913-382a-09ee-83b65069f7b6@apache.org>
 <CALK=YjO1do1A8ppSRr9VANLk=EPnKi9pZrSMScRJB+4_P4wsmA@mail.gmail.com>
From: Frank Meier <frank.meier@ergon.ch>
Message-ID: <6fc7805d-a021-5ec1-20e2-56e96683efa0@ergon.ch>
Date: Thu, 13 Apr 2017 14:47:57 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <CALK=YjO1do1A8ppSRr9VANLk=EPnKi9pZrSMScRJB+4_P4wsmA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
archived-at: Thu, 13 Apr 2017 12:48:07 -0000

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.