Para reproducir, inicie gunicorn así:
gunicorn -w 1 --max-requests=0 --max-requests-jitter=10 -b 0.0.0.0:8000 api:app
Luego, dirija algo de tráfico hacia él y observe la siguiente salida de registro:
[2019-02-05 20:27:23 +0000] [19] [INFO] Starting gunicorn 19.9.0
[2019-02-05 20:27:23 +0000] [19] [INFO] Listening at: http://0.0.0.0:8000 (19)
[2019-02-05 20:27:23 +0000] [19] [INFO] Using worker: sync
[2019-02-05 20:27:23 +0000] [22] [INFO] Booting worker with pid: 22
[2019-02-05 20:27:37 +0000] [22] [INFO] Autorestarting worker after current request.
[2019-02-05 20:27:37 +0000] [22] [INFO] Worker exiting (pid: 22)
[2019-02-05 20:27:37 +0000] [24] [INFO] Booting worker with pid: 24
Espero que --max-requests-jitter
no tenga ningún efecto cuando --max-requests
se establece en 0.
¿Cuál es el comportamiento que esperas? Normalmente, max-requests=0
debería significar que los trabajadores nunca se reinician automáticamente, pero desde su registro parece que sí.
Este error se ha introducido en d4e1bfe5bd7801c160282310875c70cec15b7c07:
La línea self.max_requests = cfg.max_requests + jitter or MAXSIZE
ahora self.max_requests = cfg.max_requests + jitter or sys.maxsize
desde e974f30517261b2bc95cfb2017a8688f367c8bf3 establecerá self.max_requests
en el valor _jitter_.
Realmente deberíamos establecer self.max_requests
solo si su valor de configuración es mayor que 0.
@joekohlsdorf el parche anterior debería corregir el error, pero háganoslo saber ...
Gracias, me queda bien.
Comentario más útil
Este error se ha introducido en d4e1bfe5bd7801c160282310875c70cec15b7c07:
La línea
self.max_requests = cfg.max_requests + jitter or MAXSIZE
ahoraself.max_requests = cfg.max_requests + jitter or sys.maxsize
desde e974f30517261b2bc95cfb2017a8688f367c8bf3 estableceráself.max_requests
en el valor _jitter_.Realmente deberíamos establecer
self.max_requests
solo si su valor de configuración es mayor que 0.