Stefan Eissing
<green/>bytes GmbH Hafenweg 16 48155 Münster www.greenbytes.de > Am 27.05.2020 um 15:05 schrieb Ruediger Pluem <rpl...@apache.org>: > > > > On 5/27/20 1:10 PM, Stefan Eissing wrote: >> The whole thing initially handled processing of several streams in parallel. >> That is why it has more states than currently necessary. >> >> h2_proxy_session_process() returns from H2_PROXYS_ST_WAIT state to the >> caller in mod_proxy_http2.c#255. That one checks the aborted state of the >> "master" connection. So, when our frontend connection goes away, >> mod_proxy_http2 processing also aborts. (Which raises the question if >> c->aborted can ever be set on a HTTP/1.1 connection during this, uhmm.) > > If you don't write to the frontend I doubt that c->aborted will be set. > >> >> But, as I reread it now, the h2_proxy_session_process() will not timeout >> when the frontend connection stays and the backend just does not send >> anything back at all. So, any "ProxyTimeout" seems to be ignored atm. > > So I seem to read this correct. This gets me to the next question: Is this > the desired behavior? I would expect it to obey > ProxyTimeout or timeout worker settings. Any particular reason why we have > that timeout starting with 25ms and increasing up to > 100ms and not just using the current timeout set on the socket? I mean even > in case it would process several streams in parallel > it could block reading from the socket until ProxyTimeout and give up if > nothing was delivered until then. Or does it need to wake > up quicker in the multi stream scenario as a request for a new stream by the > proxy_handler needs to be processed by the blocking > thread? I think respecting ProxyTimeout is the correct behaviour, now that we one handle one request at a time. However, due to the nature of h2, we cannot always do a blocking read with that timeout. For example, while a request body needs to be send, we might be in the same processing loop and need to check regularly for new data arriving on the frontend connection. But we can track how long we have neither sent nor received and compare that to ProxyTimeout. And that includes writing and reading to the frontend connection (or slave connection when the fronend is h2 itself). > > OTOH I understand that in the multiple stream scenario which we currently > don't use users might expect that the ProxyTimeout > applies to each single stream and hence doing a blocking socket read with a > ProxyTimeout could lead to streams waiting for much > longer than ProxyTimeout if there are active streams on the connection. I > guess this would require a stream specific > last_frame_received that would need to checked on a regular basis. > > Having said this any proposal how to move on? Should we do a blocking read > with ProxyTimeout and bail out if it times out for now? > > Regards > > Rüdiger >
