add timeout_worker_is_alive as an option for main.run.
Summary
The option lets users set the timeout for judging if a process is dead in multiprocessing mode(i.e., workers > 1). When the module calls uvicorn.run has some heavy load like importing a lot of modules, the is_alive check in supervisors.multiprocessing may be blocked. When this happens, the default 5 seconds timeout may cause the misjudgement of a process and kill it. Issues like https://github.com/encode/uvicorn/discussions/2396 , https://stackoverflow.com/questions/78680384/during-uvicorn-startup-child-process-dies-in-kubernetes-cluster may be caused by the case.
Checklist
- [x] I understand that this PR may be closed in case there was no previous discussion. (This doesn't apply to typos!)
- [ ] I've added a test for each change that was introduced, and I tried as much as possible to make a single atomic change.
- [x] I've updated the documentation accordingly.
This PR does fix some edge cases. Please fix the CI failures so we can merge it.
This PR does fix some edge cases. Please fix the CI failures so we can merge it.
checks passed, please go ahead
Defaulting to a low number doesn't seem right.
Defaulting to a low number doesn't seem right.
It reads to me to be defaulting to the exact number that is already being used to preserve behavior I think?
https://github.com/encode/uvicorn/blob/master/uvicorn/supervisors/multiprocess.py#L65
Hi @abersheeran, I urgently need this feature. During my project development, in case of multiple workers, child processes are dying every 5 seconds. I discovered that this PR resolves the issue. Please merge this PR as soon as possible. 🙏🙏🙏
I've tried almost Uvicorn alternatives including Gunicorn, Hypercorn, Daphne, Sanic, Tornado, Waitress. But I love Uvicorn most. Unfortunately, worker alive timeout is hardcoded. If only this is fixed, Uvicorn is almost PERFECT. Please merge this PR ASAP.
Any status update on this?
Thank you.
We are using Airflow 3 and are noticing issues because of the currently hardcoded 5s, sometimes Airflows fails to start up because of it. This is currently mitigated by setting the workers to 1, but is not a good solution.
See: https://github.com/stackabletech/airflow-operator/issues/641
@Kludex can I ask you to have a look at this PR again, as the impact is quite high for Airflow users
We (@stackabletech) sponsored @Kludex to look at this and get it merged. Thank you for following up on it and getting it merged so fast. @stijndehaes we'll include it in our next version.