Interesting. I have an issue on github from someone who observes, sometimes, a hanging HTTP/2 connection, where mod_http2 calls ap_pass_brigade() with ~120KB which never returns. Client, after a while, closes its end of the connection. Connection remains in CLOSE_WAIT.
Might this be related to the issue reported here? Anyhow I can help? -Stefan > Am 03.02.2016 um 11:29 schrieb Plüm, Rüdiger, Vodafone Group > <ruediger.pl...@vodafone.com>: > > Which MPM is used? Event or something different? > There a differences on how c->data_in_input_filters is handled by different > MPM's. > On sync MPM's like worker there is an explicit flush if > c->data_in_input_filters is zero, > the event MPM though only relies on WRITE_COMPLETION. > If event is used, does switching to worker MPM make the issue go away? > > Regards > > Rüdiger > >> -----Original Message----- >> From: Yann Ylavic [mailto:ylavic....@gmail.com] >> Sent: Mittwoch, 3. Februar 2016 11:22 >> To: httpd-dev >> Subject: Re: HTTPS connections lock-up with 2.4.18 >> >> On Wed, Feb 3, 2016 at 10:14 AM, Joachim Achtzehnter <joac...@kraut.ca> >> wrote: >>> Late at night here and I'm not at work, but see the embedded responses >> to >>> clarify some things... >>> >>> On 2016-02-03 12:43 AM, Yann Ylavic wrote: >>>> >>>> I can't tell about the underlying HTTP data here, but I suspect there >>>> is more than a single HTTP request sent by the client, >> >> Actually I didn't notice that ssltrace-v3.txt contained the plain HTTP >> request (thought it was the text version of the raw capture). >> >>> >>> No, there is definitely only one request for this test. In the real >>> application there is an HTML page, which triggers multiple requests for >>> style sheets, scripts, images, etc., and these may well be pipelined or >>> submitted via parallel connections. This still locked-up, 100% >> reproducible. >>> The test I use to collect the traces and logs is retrieving a single >> small >>> style sheet. No other files are involved. In order to allow Wireshark to >>> decrypt the SSL data I used Firefox, but for my own testing and >> debugging I >>> usually submit the request with curl. The outcome is the same with both >>> Firefox and curl. >> >> OK, so there must be an issue in the check_pipeline() function... >> >>> >>>> which makes httpd believe requests are pipelined, >>> >>> >>> How does it make this determination? >> >> By reading the pipe (non-blocking) before entering keepalive state, >> and if that succeeds (ignoring blank lines since 2.4.18, another >> change introduced in this version) the next request is processed >> immediatly without flushing output. >> IOW, pipelined requests imply batched responses. >> >> Could you please provide the output of this new patch on top of the >> previous (latest) one? >> >> Index: modules/http/http_request.c >> =================================================================== >> --- modules/http/http_request.c (revision 1727923) >> +++ modules/http/http_request.c (working copy) >> @@ -254,6 +254,10 @@ static void check_pipeline(conn_rec *c, apr_bucket >> "Can't consume pipelined empty lines"); >> c->keepalive = AP_CONN_CLOSE; >> } >> + else { >> + ap_log_cerror(APLOG_MARK, APLOG_NOTICE, rv, c, >> + "check_pipeline: no data"); >> + } >> break; >> } >> >> @@ -284,6 +288,10 @@ static void check_pipeline(conn_rec *c, apr_bucket >> break; >> } >> >> + ap_log_cerror(APLOG_MARK, APLOG_NOTICE, rv, c, >> + "check_pipeline: got 0x%x", >> + (int)(cr ? buf[1] : buf[0])); >> + >> if (mode == AP_MODE_READBYTES) { >> mode = AP_MODE_SPECULATIVE; >> cr = 0; >> @@ -319,6 +327,11 @@ static void check_pipeline(conn_rec *c, apr_bucket >> c->keepalive = AP_CONN_CLOSE; >> } >> } >> + >> + ap_log_cerror(APLOG_MARK, APLOG_NOTICE, rv, c, >> + "check_pipeline: data_in_input_filters = %i", >> + c->data_in_input_filters); >> + >> } >> >> -- >> >> Thanks, >> Yann.
