> -----Original Message-----
> From: Stefan Eissing [mailto:stefan.eiss...@greenbytes.de]
> Sent: vrijdag 4 december 2015 21:36
> To: dev@httpd.apache.org
> Subject: Re: No H2 Window updates!
> 
> The code increases the window by the difference between max and current
> so that the client has exactly the max value. nghttp2 accepts this on the
client
> side. It rejects any larger value as you described.
> 
> So we seem to have a difference in calculation between nghttp2 and serf.
> which values do you see? some data would be helpful here.

The values are completely in the log file at the bottom of this mail.

I open a connection and the server announces a default window of 65535.

> > I: DBG: Allocated 131 bytes for window on stream 0x1 (left: 65404,
65404)
I send a request with a DATA frame with a payload of 131 bytes, which
updates the stream and windows size with -131.

So both the stream and connection windows are no longer default, but 65404.
Logged for easy reading


Then I receive a WINDOW_UPDATE frame
> > I: DBG: Connection window update of 2147483392 to -2147418500
Which tries to add 2147483392 to the existing window.

Which doesn't fit, because the total outgoing window has to fit in 2^31-1...
See the RFC.


That is all that happens.
(The windowing in the other direction is completely uninteresting here... as
it happens completely independent)

        Bert



> 
> > Am 04.12.2015 um 18:42 schrieb Bert Huijben <b...@qqmail.nl>:
> >
> >
> >
> >> -----Original Message-----
> >> From: Stefan Eissing [mailto:stefan.eiss...@greenbytes.de]
> >> Sent: vrijdag 4 december 2015 16:23
> >> To: dev@httpd.apache.org
> >> Subject: Re: No H2 Window updates!
> >>
> >> If you find the time, the lastest v1.0.10 mod_http2 in 2.4.x sets the
> >> connection window to max which addresses for me the window
> starvation
> >> issues I was able to reproduce (and put into my test suite). I hope
this
> > works
> >> for you as well, otherwise I'd need more detailed data on how to
> reproduce
> >> the hanger.
> >
> > The latest version gives me immediately a connection window update of
> the
> > maximum allowed value.
> >
> > But given that the initial connection window was already set via the
> > settings window, adding this value is not allowed.
> >
> > The code has his comment copied from the RFC:
> > /* A sender MUST NOT allow a flow-control window to exceed 2^31-1
> >         octets.  If a sender receives a WINDOW_UPDATE that causes a
flow-
> >         control window to exceed this maximum, it MUST terminate either
the
> >         stream or the connection, as appropriate.  For streams, the
sender
> >         sends a RST_STREAM with an error code of FLOW_CONTROL_ERROR;
> for
> > the
> >         connection, a GOAWAY frame with an error code of
> FLOW_CONTROL_ERROR
> >         is sent.*/
> >
> > Serf does exactly this... it terminates the connection.
> >
> > So it gets nowhere near the original point of failure in the test.
> > It fails around the first stream created the test, while the original
> > failure is after thousands of requests.
> >
> >    Bert
> >
> > --
> > With the same logging enabled as on that older url, this is the whole
test
> > output now:
> >
> >
> > START: svnmover_tests.py
> > I: CMD: svnadmin.exe create svn-test-work\local_tmp\repos
> > --compatible-version=1.10 --fs-type=fsfs
> > I: <TIME = 0.016000>
> > I: CMD: svn.exe import -m "Log message for revision 1."
> > svn-test-work\local_tmp\greekfiles
> > https://localhost:7829/svn-test-work/local_tmp/repos --config-dir
> > R:\subversion\tests\cmdline\svn-test-work\local_tmp\config --password
> > rayjandom --no-auth-cache --username jrandom
> > I: CMD: R:\subversion\svn/svn.exe import -m "Log message for revision
1."
> > svn-test-work\local_tmp\greekfiles
> > https://localhost:7829/svn-test-work/local_tmp/repos --config-dir
> > R:\subversion\tests\cmdline\svn-test-work\local_tmp\config --password
> > rayjandom --no-auth-cache --username jrandom exited with 1
> > I: <TIME = 0.547000>
> > I: DBG: Allocated 131 bytes for window on stream 0x1 (left: 65404,
65404)
> > I: DBG: Connection window update of 2147483392 to -2147418500
> > I: ..\..\..\subversion\svn\import-cmd.c:129,
> > I: ..\..\..\subversion\libsvn_client\import.c:868,
> > I: ..\..\..\subversion\libsvn_client\ra.c:509,
> > I: ..\..\..\subversion\libsvn_client\ra.c:488,
> > I: ..\..\..\subversion\libsvn_ra\ra_loader.c:404:
> > (apr_err=SVN_ERR_RA_CANNOT_CREATE_SESSION)
> > I: svn: E170013: Unable to connect to a repository at URL
> > 'https://localhost:7829/svn-test-work/local_tmp/repos'
> > I: ..\..\..\subversion\libsvn_ra_serf\serf.c:603,
> > I: ..\..\..\subversion\libsvn_ra_serf\options.c:538,
> > I: ..\..\..\subversion\libsvn_ra_serf\util.c:1032,
> > I: ..\..\..\subversion\libsvn_ra_serf\util.c:981,
> > I: ..\..\..\subversion\libsvn_ra_serf\util.c:958: (apr_err=120153)
> > I: svn: E120153: Error running context: HTTP2 flow control limits
exceeded
> > W: ..\..\..\subversion\svn\import-cmd.c:129,
> > W: ..\..\..\subversion\libsvn_client\import.c:868,
> > W: ..\..\..\subversion\libsvn_client\ra.c:509,
> > W: ..\..\..\subversion\libsvn_client\ra.c:488,
> > W: ..\..\..\subversion\libsvn_ra\ra_loader.c:404:
> > (apr_err=SVN_ERR_RA_CANNOT_CREATE_SESSION)
> > W: svn: E170013: Unable to connect to a repository at URL
> > 'https://localhost:7829/svn-test-work/local_tmp/repos'
> > W: ..\..\..\subversion\libsvn_ra_serf\serf.c:603,
> > W: ..\..\..\subversion\libsvn_ra_serf\options.c:538,
> > W: ..\..\..\subversion\libsvn_ra_serf\util.c:1032,
> > W: ..\..\..\subversion\libsvn_ra_serf\util.c:981,
> > W: ..\..\..\subversion\libsvn_ra_serf\util.c:958: (apr_err=120153)
> > W: svn: E120153: Error running context: HTTP2 flow control limits
exceeded
> > END: svnmover_tests.py
> > ELAPSED: svnmover_tests.py 0:00:00.609000
> >
> >

Reply via email to