Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Subject: Re: No H2 Window updates!
To: dev@httpd.apache.org
References: <02f401d12912$fcba4130$f62ec390$@qqmail.nl>
 <030501d12916$cf7e1120$6e7a3360$@qqmail.nl>
From: Stefan Eissing <stefan.eissing@greenbytes.de>
Message-ID: <56599792.3060402@greenbytes.de>
Date: Sat, 28 Nov 2015 13:01:22 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101
 Thunderbird/38.4.0
MIME-Version: 1.0
In-Reply-To: <030501d12916$cf7e1120$6e7a3360$@qqmail.nl>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit

I am not really here, but...

the window updates are sent out via update_window(), line 1001, 
h2_session.c. If you do not see any window updates with a client, it may 
be that the server app you called does not read its input. I have 
several test cases with uploads and they work with nghttp and curl.

Basics of mod_http2 flow control:
- the auto udates of nghttp2 are disabled because nghttp2 would 
continously update the window for the client, letting the client sent 
more and more - until we run out of memory.
- instead, input reads from workers against the h2_mplx io are recorded 
and lead to regular window update being sent out. So clients can only 
send more when the data is actually consumed by someone.

What is not well tested, I think, is the timeout/cleanup behaviour on 
this. So, as long as the connection is alive, individual stream could 
appear to hang infinitely *if* no one ever reads the data. Maybe you see 
something like this?

//Stefan

Am 27.11.2015 um 14:23 schrieb Bert Huijben:
>> -----Original Message-----
>> From: Bert Huijben [mailto:bert@qqmail.nl]
>> Sent: vrijdag 27 november 2015 13:56
>> To: bert@qqmail.nl
>> Subject:
>>
>>                  Hi,
>>
>> I finally took the time to diagnose that segfault I had, and I think it
>> points to a serious bug in httpd.
>>
>> To summarize this: I don�t receive window updates.
>>
>> In this specific test we set a very huge amount of small requests (bodies
> of
>> 95 and 113 bytes), until we get out of the 65535 (or 65536) bytes of
> window
>> space I get from httpd at the connection level.
>> (Each stream doesn�t get near its limit. I can try if I can receive window
>> updates there� but currently I can�t reproduce ever receiving a window
>> update)
>>
>>
>> Originally this caused a segfault in my code, but I fixed that one. But
> now
>> I�m just stuck waiting to receive a window update from httpd�
>>
>>
>> My last testing was against 2.4.x (to get the 2.4.18 goodness)
> And I think the combination of:
>
> === h2_session.c around line 707 ===
> /* We need to handle window updates ourself, otherwise we
>           * get flooded by nghttp2. */
>          nghttp2_option_set_no_auto_window_update(options, 1);
>
> ====================
> And not a single call to nghttp2_submit_window_update() to find, explains
> the situation.
>
> I haven't tried what happens when I disable this auto_window call... but
> sending window updates is really required by the H2 specs.
>
>
>
> And I totally understand that this wasn't high priority... I worked around
> not sending updates in my implementation until yesterday :-)
>
>
> 	Bert
>