Allow accepting new connections during a graceful shutdown
Les mainteneurs répondent en général sous 1 jour
Personne n'a encore pris cette issue.
Évaluation
- Difficulté
- 4/5
- Temps estimé
- 3-5 jours
- Accessibilité débutants
- 45/100
- Type d'issue
- Fonctionnalité
- Clarté
- Plutôt claire
- Activité
- À l'abandon
- Stack technique
- rust
- Domaine
- networking
Piste de recherche
Commencez par lire les emplacements Rust référencés dans hyper's proto/h1/dispatch.rs et proto/h1/conn.rs, puis hyper-util's server/conn/auto/mod.rs. Suivez l'impact de l'annulation et de l'arrêt gracieux sur les nouvelles connexions et les connexions pouvant être mises à niveau ; le travail est considéré comme terminé lorsque le flag proposé permet d'accepter des connexions pendant la fenêtre initiale d'arrêt tout en appliquant GOAWAY ou connection: close, puis cesse d'accepter des connexions après le délai minimal.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Description
Is your feature request related to a problem? Please describe.
We want a very specific behavior for graceful shutdowns in our hyper-based proxy. We set two deadlines, min (typically 5-10s), and max (could be much longer). We want the following sequence during shutdown:
- t=0s: send GOAWAY on all HTTP2 connections and start responding with
connection: closeon all http1 requests. Continue to accept new connections, and handle them the same (GOAWAY/connection: close) them. - After
mindeadline: stop accepting new connections. Continue existing connections, with the sameGOAWAY/connection: close. - After
maxdeadline: shutdown everything.
The reason for the time when we accept new connections, but tell clients to go away, is that there is some time for the load balancers in front of the proxy (this could be something like AWS NLB, Kubernetes kube-proxy, etc) to de-register the proxy instance and stop sending traffic to it. So immediately dropping new connections results in downtime. However, during this time its nice to start to encourage clients to goaway, since its likely they will select another proxy instance (either because the fronting LB already de-registered the old instance (the min deadline is intended to be the worst case, so usually its much faster), or because of random chance it selects a different one).
Today, the best we can do is wait until after min deadline and stop accepting new connections and start GOAWAY/connection: close at the same time.
Describe the solution you'd like
A new flag on hyper_util::server::conn::auto, and on hyper::server::conn::http1 to enable the "different graceful shutdown mode" (naming TBD!). This would change:
- https://github.com/hyperium/hyper/blob/f9f8f44058745d23fa52abf51b96b61ee7665642/src/proto/h1/dispatch.rs#L97 - skip the close() call
- https://github.com/hyperium/hyper/blob/f9f8f44058745d23fa52abf51b96b61ee7665642/src/proto/h1/conn.rs#L878 - skip the close() call
- https://github.com/hyperium/hyper-util/blob/66afc93debef02548c86e8454e6bc01cf4fca280/src/server/conn/auto/mod.rs#L341 - do no error here
- https://github.com/hyperium/hyper-util/blob/66afc93debef02548c86e8454e6bc01cf4fca280/src/server/conn/auto/mod.rs#L525-L531 -- if
cancelled, then callgraceful_shutdown()on the newly served connections (and do the same for UpgradeableConnection)
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Additional context
If these changes are acceptable I would be happy to contribute both parts of the change
- Langage dominant
- Rust
- Étoiles
- 16.4k
- Forks
- 1.8k
- Merge moyen
- 2 j 9 h
- PR mergées (30 j)
- 14
Préparer son environnement
- Aucun Dockerfile ni fichier Docker Compose
- Aucun modèle de pull request
- Lire le guide de contribution
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Autres issues de hyperium/hyper
-
Publicly reexport the http crateOuverteC-feature
Difficulté 1/5 Moins d'une heure Accessibilité débutants 65/100
hyperium/hyper#2652 · 4 réactions ·
Les mainteneurs répondent en général sous 1 jour
-
bug(ci): some warnings are not enforced by `features` stepPeut-être pris @cratelyn l’a pris il y a 3 jours. OuverteA-tests C-bug
hyperium/hyper#4232 · 1 personne assignée ·
Les mainteneurs répondent en général sous 1 jour
-
Write a HIP for `Body::poll_progress()`Peut-être pris @cratelyn l’a pris il y a 8 jours. OuverteA-body B-rfc C-feature
hyperium/hyper#4228 · 1 personne assignée ·
Les mainteneurs répondent en général sous 1 jour
-
Upgraded HTTP/2 CONNECT streams cannot be reset, so a failed tunnel looks like a clean closePeut-être pris @jeremyjpj0916 l’a pris il y a 18 jours. Ouverte
Difficulté 4/5 3-5 jours Accessibilité débutants 55/100
Les mainteneurs répondent en général sous 1 jour
-
Allow connection pools to stop reusing an HTTP/2 connection before its keep-alive timeoutPeut-être pris @jiahaoliang l’a pris il y a 36 jours. OuverteC-feature
Difficulté 5/5 Plus d'une semaine Accessibilité débutants 35/100
hyperium/hyper#4186 · 3 commentaires ·
Les mainteneurs répondent en général sous 1 jour
Toutes les issues de hyperium/hyper
Issues similaires
-
Difficulté 2/5 1-3 heures Accessibilité débutants 65/100
-
Difficulté 2/5 1-3 heures Accessibilité débutants 70/100
-
area: compat area: parsing bug
Difficulté 2/5 1-3 heures Accessibilité débutants 72/100
reubeno/brush#1526 · 1 commentaire ·
Les mainteneurs répondent en général sous 1 jour
-
Volume eject does not refuse system, root or /home mountsPeut-être pris @bernardopg l’a pris aujourd’hui. Ouverte
Difficulté 2/5 1-3 heures Accessibilité débutants 72/100
spacedriveapp/spacedrive#3159 ·
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 1/5 Moins d'une heure Accessibilité débutants 82/100