> -----Original Message-----
> From: Stefan Eissing [mailto:[email protected]]
> Sent: vrijdag 20 november 2015 10:26
> To: [email protected]
> Subject: Re: H2 stream dependencies
>
> Bert,
>
> interesting and nice to see the progress. You probably could use priorities
> for
> ordering, especially when using the stream dependencies. I am not certain,
> however, if this will give you totally deterministic behavior. If stream B
> depends on A, usually A will be sent out before B. However, should stream A
> become suspended - e.g. unable to progress, either because there is no data
> available which some other thread needs to produce, or because the flow
> control window has not been updated in time - the server will start sending
> data for B.
>
> The state of the implementation is:
> 2.4.17: fully implemented priority handling on sending stream data, as
> implemented by the nghttp2 library
> 2.4.18: additionally, streams are scheduled for execution by priority. Makes a
> difference when the number of available worker is less than the stream
> queue length, e.g. when der server is under load or only few workers are
> available (in prefork, for certain).
>
> Another way to influence the ordering is for the client to play with the
> stream window sizes. If you give stream A 2^31-1 and stream B 0 until you
> have A, then update B, it may also do what you want. If both streams
> produce response bodies...flow only applies to DATA...
I'm currently thinking about combining both approaches... Sending the
dependencies and (just to be sure) also keep the window low on such a stream.
In that case only a very small cache should be able to handle the delaying in
case (somehow) the dependency doesn't do the right thing.
In the specific case of Subversion there shouldn't be many cases where output
is delayed, so I hope this will just work for us. But once we see h2 proxies,
I'm guessing we will really need the window handling as fallback.
In a few of the remaining test failures I see httpd spinning at 100% CPU
(automatically cooling down after some timout; perhaps if the connection is
closed). I haven't investigated those, but it could be an httpd issue. This
usually triggers other test failures for me as I limit the amount of workers
and threads while testing. I'll follow-up when I know more.
Bert
