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

Connection closed before message completed #405

Closed
r-ml opened this issue Oct 28, 2024 · 2 comments
Closed

Connection closed before message completed #405

r-ml opened this issue Oct 28, 2024 · 2 comments
Assignees
Labels

Comments

@r-ml
Copy link
Contributor

r-ml commented Oct 28, 2024

Describe the bug
Getting a lot of hyper: connection closed before message completed errors which seem to be hyperium/hyper#2136.
rust-s3 does not seem to configure any sort of keepalive value, I assume doing that fixes the issue. AWS NodeJS SDK docs indicate a default value of 1000ms for keepalive.
Another way would be to set pool_idle_timeout to match the S3 server value of 20s, according to comments in the hyper issue.

To Reproduce
Open a connection, sleep for more than 20s then try to use said connection.

Expected behavior
Connections remain open and usable.

Environment

  • Rust version: 1.80.1
  • lib version: 0.35.1
@r-ml r-ml added the bug label Oct 28, 2024
r-ml added a commit to r-ml/rust-s3 that referenced this issue Oct 28, 2024
@r-ml
Copy link
Contributor Author

r-ml commented Oct 28, 2024

Maybe something like r-ml@f8d8310

r-ml added a commit to r-ml/rust-s3 that referenced this issue Oct 28, 2024
r-ml added a commit to r-ml/rust-s3 that referenced this issue Oct 28, 2024
@r-ml
Copy link
Contributor Author

r-ml commented Oct 29, 2024

Another way would be to set pool_idle_timeout to match the S3 server value of 20s, according to comments in the hyper issue.

This does not seem to hold true. I've tried different pool_idle_timeout durations, as low as 5 seconds, but the error persists, although less frequent.
Even tcp_keepalive does not seem to help.

Oh well, retrying seems to be the solution for now. Seems wasteful though.

@r-ml r-ml closed this as completed Oct 29, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants