Add a test to demonstrate connection logical deadlock under high concurrency #852
Conversation
…equests than max_concurrent_streams
|
Thanks for providing a test case! What you describe in the issue sounds plausible, but I notice in this that flow control isn't touched, so neither side will give any more connection window space at all, so it will by design definitely not be able to make further progress. |
tests/h2-tests/tests/deadlock.rs
Outdated
| ); | ||
| } | ||
|
|
||
| thread::sleep(CHECK_FOR_PROGRESS_INTERVAL); |
There was a problem hiding this comment.
You'd also want to use something like tokio::time::sleep(CHECK_FOR_PROGRESS_INTERVAL).await to not block any of the other tasks on this thread.
It is not clear what you mean by this. Why would flow control need to be touched? The connection has a non-zero window (before it gets allocated to pending_open requests that could not possibly use it, based on the theory above), so all the requests should be transmitted through that window. Am I misunderstanding something? |
|
In HTTP/2, there's a window on each stream, and on the connection as a whole. And the default is fairly small, just 64kb. Flow control management with h2 is manual. Without the other "side" give more window on the connection, no stream will be allowed to send more data. hyper will manage it for you automatically... And, perhaps you do in your larger app. But it is a reason why this specific test will hang. With 10kb bodies, it should stop around the 7th request (-ish, since prioritization/ordering of DATA frames is not specified). |
|
If this test were failing because the connection window is not being extended, it would be failing also with Yet, with lower values of This suggests to me that the problem is not the lack of connection window extension. |
Test to accompany bug report #853.