> -----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 > > > >