Skip to content
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

Add API for poisoning connections #121

Merged
merged 3 commits into from
Aug 6, 2024
Merged

Conversation

rcoh
Copy link
Contributor

@rcoh rcoh commented May 8, 2024

This is a port of https://github.com/hyperium/hyper/pull/3145/files + a test.

It introduces a PoisonPill atomic onto connection info. When set to true, this prevents the connection from being returned to the pool.

@seanmonstar
Copy link
Member

It at least looks like the failed test is relevant. Dropping a client should close its idle connections.

@rcoh
Copy link
Contributor Author

rcoh commented May 14, 2024

Yeah I agree. I tried pretty hard to reproduce it on a number of different environments but I haven't been able yet. I'll transition this to Draft in the interim

@rcoh rcoh marked this pull request as draft May 14, 2024 17:30
@Velfi
Copy link

Velfi commented May 23, 2024

I tried running these tests in Docker and in my dev desktop but couldn't reproduce. :(

Running clippy on the tests shows that we're holding a std::sync::Mutex across await points in a few places. Could that be related to the test failure?

I also see that read is used in a few tests but we're not checking to see if it read the whole thing. Switching to read_exact causes a bunch of new test failures. (read 1: Os { code: 35, kind: WouldBlock, message: "Resource temporarily unavailable" })

@seanmonstar
Copy link
Member

I just retried CI, and it's red this time too.

if sock.read(&mut buf).expect("read 1") > 0 {
sock.write_all(b"HTTP/1.1 200 OK\r\nContent-Length: 0\r\n\r\n")
.expect("write 1");
num_requests_tracker.fetch_add(1, Ordering::Relaxed);
Copy link

@hackermondev hackermondev Jul 31, 2024

Choose a reason for hiding this comment

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

Looks like moving num_requests_tracker.fetch_add up before socket.write_all fixes the test.

@hackermondev
Copy link

@rcoh mind pushing the change i mentioned ^ so this can be merged

@rcoh rcoh marked this pull request as ready for review July 31, 2024 13:27
Co-authored-by: Sean McArthur <[email protected]>
@hackermondev
Copy link

tests pass on my machine. not sure why this tests are flaky, can u try rerunning them?

@seanmonstar
Copy link
Member

I did re-run it once more after the latest commit.

@rcoh
Copy link
Contributor Author

rcoh commented Aug 1, 2024

When this first happened I tried really hard to reproduce. I even pulled down the docker image that they are running in, ran them on multiple host platforms etc.

I ran them thousands of times. I was totally unable to reproduce. I'm not sure what's going on here.

@dswij
Copy link
Member

dswij commented Aug 1, 2024

Did you run it with --all-features? @rcoh

@rcoh
Copy link
Contributor Author

rcoh commented Aug 1, 2024

Yes

@seanmonstar
Copy link
Member

I took a closer look at this this morning, and realized that the failing test was unrelated to the rest of the code in this PR. After yet another restart, it worked just fine. Looking at the implementation of the tests, they're, uh, wow. Clearly written before async was a thing, and just barely adjust to work with async hyper. It'd be nice to update them to use task::spawn and async servers... That might help reduce any flakiness in them.

Anywho, since this works, I'm merging and it'll be in the next release (aiming for today).

@seanmonstar seanmonstar merged commit c7752f3 into hyperium:master Aug 6, 2024
16 checks passed
github-merge-queue bot pushed a commit to smithy-lang/smithy-rs that referenced this pull request Aug 21, 2024
## Motivation and Context
<!--- Why is this change required? What problem does it solve? -->
<!--- If it fixes an open issue, please link to the issue here -->
#1925

## Description
Backports connection poisoning that hyper 0.14 HTTP client has to the
hyper 1.x client.

See also:
* upstream support: hyperium/hyper-util#121

## Testing
<!--- Please describe in detail how you tested your changes -->
<!--- Include details of your testing environment, and the tests you ran
to -->
<!--- see how your change affects other areas of the code, etc. -->

## Checklist
<!--- If a checkbox below is not applicable, then please DELETE it
rather than leaving it unchecked -->
- [X] For changes to the smithy-rs codegen or runtime crates, I have
created a changelog entry Markdown file in the `.changelog` directory,
specifying "client," "server," or both in the `applies_to` key.

----

_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
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.

5 participants