hyperium / hyperium/hyper

Graceful client connection shutdown

Open
#2,192 1 comment 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Rust
Stars
16.3k
Forks
1.8k
Avg merge
1d 22h
Merged PRs (30d)
14

Description

We have a use case where we know beforehand if we need to stop sending requests to specific connections within the same client pool. Similarly to how it's possible to gracefully shut down a hyper server connection, it would be useful to be able to gracefully shutdown a specific connection. I was about to create my own pool by using handshake and a VecDeque (or something but this might be best as part of hyper directly.

More precisely, we host virtual machines which can go up, down or restart at any time. We use a custom Service implementation to choose which virtual machine to connect to based on a bunch of criteria (essentially: load balancing). When a controlled shutdown of a virtual machine happens, we're notified ~30 seconds or so before it actually happens. At that time, we'd like to make a best effort attempt at gracefully shutting down the connection in such a way that a client stops using it to send requests.

You hinted that it would be possible to do this with a Service? I think the missing bit might just be a way to mark a connection as "shutting down" so hyper knows to stop sending requests to it.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the client pool and handshake APIs, then compare them with the graceful shutdown behavior for a hyper server connection. Review how the custom Service selects connections and clarify how a connection marked “shutting down” should stop receiving requests; done requires an agreed API and demonstrated best-effort draining behavior.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
backend-api-design, networking
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.