Add workers graceful timeout - test refactor #459
Closed
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Follow-up from #435, just to demonstrate a possible refactoring
Granian uses multiprocessiong to keep track of workers. On respawn and stop it uses
SIGTERM
together withjoin
without atimeout
(althoughtimeout
is exposed). If a worker refuses to gracefully stop, the granian main loop can get stuck at thejoin
This change implements a timeout for graceful stopping of workers with a default of
30s
. If the timeout is breached the worker gets force stopped usingSIGKILL
. The timeout can be changed with--workers-graceful-timeout
on the cmdline or as parameter in an app.Related work: gunicorn
Reproduction: The issue can be simulated by starting a thread in a worker without daemonizing it:
threading.Thread(target=slow_thread).start()
. If granian is used together with FastAPI it also works with a background task:background_tasks.add_task(slow_task)
. Note: The thread or task doesn't have to be hanging, but just has to be running at the time granian tries to stop the worker.