Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
GitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
HTTP/2 connection reuse doesn't respect maximum concurrent streams #4779
I did this
Ran HTTP/2 parallel transfers using this example: https://gist.github.com/kunalekawde/1c6494b0aa4bf818ab0c42bb42497f5d. More details in https://curl.haxx.se/mail/lib-2019-12/0073.html.
I expected the following
Connections to be re-used based on some upper limit - max concurrent streams.
Unmodified libcurl 7.67.0 has the issue for connection re-use. A fix for same was committed to master with #4732 . This fix doesn't work as same connection is being re-used continuously for parallel streams without hitting limit of max concurrent connections, indicated same here: https://curl.haxx.se/mail/lib-2019-12/0073.html.
Reported-by: Kunal Ekawde Fixes #4779
Got this crash during one of the run. All call run model is same - parallel HTTP/2 transfers.
I also got below once - but this should be different issue and shall check from application side first.
libcurl version: 7.67.0 with above fix and #4732
Using the example: https://gist.github.com/kunalekawde/6a5d7646fca9d82c50e1e31147a85686
I'm still trying to reproduce the crash reported earlier using this example.
I ran the example with plain version 2 (not prior knowledge, I don't have any such servers around) and it seems to work for me. I can't see any crash or misbehavior.
As for what max concurrency to use in that check, I think maybe we should use the minimum value of
So, mix of HTTP/1.1 and plain HTTP/2.0 transfers to same server worked fine? or was this with only HTTP/2 plain transfers ?
Yes, this sounds reasonable.
A regression made the code use 'multiplexed' as a boolean instead of the counter it is intended to be. Also, respect the CURLMOPT_MAX_CONCURRENT_STREAMS value in the same check. Reported-by: Kunal Ekawde Fixes #4779
On the trap reported earlier:
Do you see anything of concern here ?
chosen->data is set here and again here:
data is updated