Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
From: "Bert Huijben" <bert@qqmail.nl>
To: <dev@httpd.apache.org>
References: <02f401d12912$fcba4130$f62ec390$@qqmail.nl>
 <030501d12916$cf7e1120$6e7a3360$@qqmail.nl> <56599792.3060402@greenbytes.de>
In-Reply-To: <56599792.3060402@greenbytes.de>
Subject: RE: No H2 Window updates!
Date: Sat, 28 Nov 2015 13:33:56 +0100
Message-ID: <03a201d129d9$0d829a00$2887ce00$@qqmail.nl>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AQJt5VCTIFs6KteEjCgZz0PozG8d2QIIvd2DAZcYZYmdWucw8A==
Content-Language: nl


> -----Original Message-----
> From: Stefan Eissing [mailto:stefan.eissing@greenbytes.de]
> Sent: zaterdag 28 november 2015 13:01
> To: dev@httpd.apache.org
> Subject: Re: No H2 Window updates!
> 
> 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.

>From h2_session.c around line 1640.
=======================
            switch (status) {
                case APR_SUCCESS:       /* successful read, reset our idle
timers */
                    have_read = 1;
                    wait_micros = 0;
                    break;
                case APR_EAGAIN:              /* non-blocking read, nothing
there */
                    break;
                default:
                    if (APR_STATUS_IS_ETIMEDOUT(status)
                        || APR_STATUS_IS_ECONNABORTED(status)
                        || APR_STATUS_IS_ECONNRESET(status)
                        || APR_STATUS_IS_EOF(status)
                        || APR_STATUS_IS_EBADF(status)) {
                        /* common status for a client that has left */
                        ap_log_cerror( APLOG_MARK, APLOG_DEBUG, status,
session->c,
                                      "h2_session(%ld): terminating",
                                      session->id);
                        /* Stolen from mod_reqtimeout to speed up lingering
when
                         * a read timeout happened.
                         */
                        apr_table_setn(session->c->notes,
"short-lingering-close", "1");
                    }
                    else {
                        /* uncommon status, log on INFO so that we see this
*/
                        ap_log_cerror( APLOG_MARK, APLOG_INFO, status,
session->c,
                                      APLOGNO(02950) 
                                      "h2_session(%ld): error reading,
terminating",
                                      session->id);
                    }
                    h2_session_abort(session, status, 0);
                    goto end_process;
            }
===========================

I'm not familiar enough with differences in bucket handling between serf and
httpd to really make the call, but as the serf buckets were designed by the
same group:
I'm guessing that there might be successful reads with different status
values than just APR_SUCCESS.


In serf I would expect to see an immediate APR_EOF when there is only a
single frame to be read (or perhaps a few intermediate APR_EAGAINS and then
a EOF), which may both imply successful reading 0 or more bytes, followed by
their status code.

	Bert