Support for graceful shutdown
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 32/100
- Tipo de issue
- Nueva funcionalidad
- Claridad
- Bastante claro
- Estado de actividad
- Estancado
- Área
- networking
Línea de trabajo
Start with the httpuv server object and its connections callback, then review how server behavior is exposed at the R level. Trace the existing listener, HTTP, and WebSocket lifecycle before deciding where a shutdown state belongs. Done means existing connections can finish while new connections are rejected, with a usable R-level shutdown entry point.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
My motivation here is that to have some sort of graceful transition during Shiny deployments so that existing users don't immediately greyscreen. By this I mean that existing websocket/HTTP connections should continue to work but new connections cannot be made to the running server.
As an external example, the HTTP server from the Go standard library can be put into "shutdown" mode:
Shutdown works by first closing all open listeners, then closing all idle connections, and then waiting indefinitely for connections to return to idle and then shut down.
Which sounds like the right approach to me. Waiting indefinitely is fine for our usecase, since SIGKILL can be used to terminate the process eventually if it exceeds some timeout. (This is how Kubernetes works by default.)
There is an upstream issue on libuv for a direct "stop listening" API that links to various supporting discussions, but it has not been implemented.
The libuv thread above suggests emulating "stop listening" support by having the connections callback just call uv_close() right after calling uv_accept() (as simply not calling uv_accept will accumulate connections in the kernel). I believe httpuv could do when a "shutdown" flag has been set on the server object, although I'm not sure how this ought to be exposed at the R level.
This is mildly related to #226.
- Lenguaje dominante
- C
- Estrellas
- 252
- Forks
- 87
- Métricas de merge de PR
- Sin PR fusionados en 30 d
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Sin plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de rstudio/httpuv
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 64/100
-
Dificultad 4/5 3-5 días Aptitud para principiantes 46/100
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 30/100
-
Dificultad 4/5 3-5 días Aptitud para principiantes 45/100
-
Dificultad 4/5 3-5 días Aptitud para principiantes 35/100
Todos los issues de rstudio/httpuv
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
Los mantenedores suelen responder en 1 día
-
severity: low
Dificultad 2/5 1-3 horas Aptitud para principiantes 64/100
luainkernel/lunatik#2530 ·
Los mantenedores suelen responder en 1 día
-
polygonToCells CLI silently drops vertices when whitespace precedes a coordinate's closing bracketAbierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
Los mantenedores suelen responder en 1 día
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 85/100
Los mantenedores suelen responder en 1 día
-
issue: bug report
Dificultad 2/5 1-3 horas Aptitud para principiantes 62/100
Los mantenedores suelen responder en 2 días