Skip to content

core: unify uint32_t in connection pool clients and max_request_per_connection #39275

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 10 commits into from
Apr 30, 2025

Conversation

botengyao
Copy link
Member

  1. max_requests_per_connection is uint32Value in the http options and cluster configs, so no need to use uint64_t
  2. clean up for both HTTP and TCP active clients in the connection pool to avoid uint64_t for any limits and the base Envoy::ConnectionPool::ActiveClientare all uint32_t.
  3. correct comments and other changes for the default.

Commit Message:
Additional Description:
Risk Level: low
Testing:
Docs Changes:
Release Notes:
Platform Specific Features:

Signed-off-by: Boteng Yao <boteng@google.com>
Signed-off-by: Boteng Yao <boteng@google.com>
Copy link

As a reminder, PRs marked as draft will not be automatically assigned reviewers,
or be handled by maintainer-oncall triage.

Please mark your PR as ready when you want it to be reviewed!

🐱

Caused by: #39275 was opened by botengyao.

see: more, trace.

Signed-off-by: Boteng Yao <boteng@google.com>
@botengyao botengyao marked this pull request as ready for review April 30, 2025 05:13
@botengyao
Copy link
Member Author

/assign-from @envoyproxy/envoy-maintainers

Copy link

@envoyproxy/envoy-maintainers assignee is @jmarantz

🐱

Caused by: a #39275 (comment) was created by @botengyao.

see: more, trace.

Signed-off-by: Boteng Yao <boteng@google.com>
Signed-off-by: Boteng Yao <boteng@google.com>
@ggreenway ggreenway self-assigned this Apr 30, 2025
Signed-off-by: Boteng Yao <boteng@google.com>
Signed-off-by: Boteng Yao <boteng@google.com>
Copy link
Contributor

@jmarantz jmarantz left a comment

Choose a reason for hiding this comment

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

lgtm mostly; couple questions.

ActiveClient(HttpConnPoolImplBase& parent, uint64_t lifetime_stream_limit,
uint64_t effective_concurrent_stream_limit,
uint64_t configured_concurrent_stream_limit,
ActiveClient(HttpConnPoolImplBase& parent, uint32_t lifetime_stream_limit,
Copy link
Contributor

Choose a reason for hiding this comment

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

What does 'lifetime' mean here? I'm just wondering if we are counting a potentially huge number of events over the lifetime of a server.

Copy link
Member Author

Choose a reason for hiding this comment

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

It is the upstream's connection's life time to the backends, and it could be large, but it is not the lifetime of a server.

Signed-off-by: Boteng Yao <boteng@google.com>
Signed-off-by: Boteng Yao <boteng@google.com>
ggreenway
ggreenway previously approved these changes Apr 30, 2025
Copy link
Member

@ggreenway ggreenway left a comment

Choose a reason for hiding this comment

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

LGTM

Signed-off-by: Boteng Yao <boteng@google.com>
@ggreenway ggreenway merged commit a92ed5f into envoyproxy:main Apr 30, 2025
25 checks passed
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.

3 participants