Skip to content

http2: allows the capacity to increase with SETTINGS frame#19161

Merged
alyssawilk merged 7 commits intoenvoyproxy:mainfrom
YaoZengzeng:settings
Jan 13, 2022
Merged

http2: allows the capacity to increase with SETTINGS frame#19161
alyssawilk merged 7 commits intoenvoyproxy:mainfrom
YaoZengzeng:settings

Conversation

@YaoZengzeng
Copy link
Member

Signed-off-by: YaoZengzeng [email protected]

Commit Message: allows the capacity of http2 connection to increase with SETTINGS frame
Additional Description: fixes #18880
Risk Level: medium
Testing: unit
Docs Changes: n/a

@YaoZengzeng
Copy link
Member Author

@alyssawilk PTAL:)

Copy link
Contributor

@alyssawilk alyssawilk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Huzzah! Thanks so much for picking up this series of changes. Couple of ideas below
/wait

// currentUnusedCapacity() to be explicit int32_t
ASSERT(std::numeric_limits<int32_t>::max() >= old_unused_capacity);
concurrent_stream_limit_ = settings.maxConcurrentStreams().value();
if (configured_stream_limit_ > settings.maxConcurrentStreams().value()) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

any reason to not set
concurrent_stream_limit_ = std::min(settings.maxConcurrentStreams().value(), configured_stream_limit_) ? I think it's a bit easier to read?

void MultiplexedActiveClientBase::onSettings(ReceivedSettings& settings) {
if (settings.maxConcurrentStreams().has_value() &&
settings.maxConcurrentStreams().value() < concurrent_stream_limit_) {
if (settings.maxConcurrentStreams().has_value()) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should runtime guard this change as described in CONTRIBUTING.md

closeAllClients();
}

TEST_F(Http2ConnPoolImplTest, IncreaseCapacityWithSettingsFrame) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it would be good to integration test this as well.
I think you could move TEST_P(QuicHttpIntegrationTest, NoInitialStreams) { to the protocol integration test, and updateConcurrentStreams / sendSettings based on HTTP/3 vs HTTP/3?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I understand correctly, do you mean move NoInitialStreams to protocol_integration_test.cc and let it test both HTTP2 and HTTP3? It seems a bit complicated, could I open another PR to implement it after dig a little deeper :)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd definitely like to make sure we integration test incrementing settings with this change. Alternately you can land this false by default with a TODO to flip true with integration testing, but I don't think adapting the test is too complicated so I think it makes more sense to land the test now. I'm happy to help if you get stuck!

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Get it, let me do some research to get familiar with the integration test framework :)

@YaoZengzeng
Copy link
Member Author

@alyssawilk updated! But I only write a integration test for http2.

There two issues for NoInitialStreams of http2:

  1. The valid range of max concurrent streams is from 1 to 2147483647 (2^31 - 1) and defaults to 2147483647. Also for http2, client always launch a request first, then get the SETTINGS frame from server.
  2. I don't know how to adjust concurrent streams of nghttp2 like quic does: quic::test::QuicSessionPeer::SetMaxOpenIncomingBidirectionalStreams(...);

@alyssawilk
Copy link
Contributor

Thanks for the integration test!
you can change the streams by writing a sendSettings utility for the test upstream, similar to the updateConcurrentStreams in https://github.com/envoyproxy/envoy/pull/18775/files or alternately you can copy the "send a settings frame" from say UpstreamSettingsMaxStreamsAfterGoAway and use it to update the settings on the connection.

@YaoZengzeng YaoZengzeng force-pushed the settings branch 6 times, most recently from 322734a to 21f83e0 Compare December 25, 2021 10:16
@YaoZengzeng
Copy link
Member Author

@alyssawilk Already use NoInitialStreams to test both HTTP2 & HTTP3.

What weired is the test cases never fail in my local environment with test command bazel test --config=docker-clang --test_output=streamed //test/integration:multiplexed_upstream_integration_test --cache_test_results=no , but it never succeed in CI.

Have any ideas?

@alyssawilk
Copy link
Contributor

hm, not sure. the test/integration/README file has instructions which can help if test failures are due to slow CI machines - you could try that?
/wait

@YaoZengzeng
Copy link
Member Author

hm, not sure. the test/integration/README file has instructions which can help if test failures are due to slow CI machines - you could try that? /wait

Still don't know why :(

Is there any way to pass "-l trace" to CI script, so I could get the verbose log from CI output rather than just error output.

@alyssawilk
Copy link
Contributor

well you can tweak the CI scripts to do that but honestly I usually use the test mock code to only beef up logging in the test case which fails.

like if you know what part of the test fails you can put that code in
EXPECT_LOG_CONTAINS("debug", "foobareep", {
your statements here
})
like I did over in https://github.com/envoyproxy/envoy/pull/19234/files

@YaoZengzeng
Copy link
Member Author

@alyssawilk PTAL! I think the NoInitialStreams for http2 will not fail anymore :)

alyssawilk
alyssawilk previously approved these changes Jan 11, 2022
Copy link
Contributor

@alyssawilk alyssawilk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great! I think the 2 test failures aren't yours :-)

Just because the logic is finicky I'm going to hold this until the release is cut tomorrow (which will require one more merge since the version history file will change)

@alyssawilk
Copy link
Contributor

release is in! one final sync and you should be good to go. Thanks again for your patience here!

Signed-off-by: YaoZengzeng <[email protected]>
Signed-off-by: YaoZengzeng <[email protected]>
Signed-off-by: YaoZengzeng <[email protected]>
Signed-off-by: YaoZengzeng <[email protected]>
Signed-off-by: YaoZengzeng <[email protected]>
Signed-off-by: YaoZengzeng <[email protected]>
@YaoZengzeng
Copy link
Member Author

@alyssawilk synced!

Copy link
Contributor

@alyssawilk alyssawilk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Awesome! Thanks again both for tackling this change and all your patience getting the tests working and code merged!

@alyssawilk alyssawilk merged commit 86cbd31 into envoyproxy:main Jan 13, 2022
joshperry pushed a commit to joshperry/envoy that referenced this pull request Feb 13, 2022
…y#19161)

Commit Message: allows the capacity of http2 connection to increase with SETTINGS frame
Additional Description: fixes envoyproxy#18880
Risk Level: medium
Testing: unit
Docs Changes: n/a

Signed-off-by: YaoZengzeng <[email protected]>
Signed-off-by: Josh Perry <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

handle http/2 with no initial streams

2 participants