worker: add options to finish work before shutdown; extend or turn off forced shutdown timeout #104272

viktorasm · 2023-12-15T15:45:45+01:00

viktorasm commented

2023-12-15 15:45:45 +01:00

First-time contributor

This changes shutdown behavior of workers slightly:

when using --finish-work-before-shutdown flag, SIGINT and SIGTERM signals will no longer cancel worker context. Instead, they serve as advice for worker to enter shutdown mode - finish all work and exit; this feature will cooperate with forced shutdown timeout.
forced shutdown timeout is now configurable via --forced-shutdown-timeout, and, if set to 0, turns off forcefull shutdown feature. Operating system can still kill the process forcefully.
default behavior is backwards compatible, though it would result in simpler code if some things were made into new defaults, e.g. worker should probably ALWAYS finish in-progress work before agreeing to terminate on SIGTERM.

This changes shutdown behavior of workers slightly: * when using `--finish-work-before-shutdown` flag, SIGINT and SIGTERM signals will no longer cancel worker context. Instead, they serve as advice for worker to enter shutdown mode - finish all work and exit; this feature will cooperate with forced shutdown timeout. * forced shutdown timeout is now configurable via `--forced-shutdown-timeout`, and, if set to 0, turns off forcefull shutdown feature. Operating system can still kill the process forcefully. * default behavior is backwards compatible, though it would result in simpler code if some things were made into new defaults, e.g. worker should probably ALWAYS finish in-progress work before agreeing to terminate on SIGTERM.

viktorasm added 7 commits 2023-12-15 15:45:48 +01:00

Sybren A. Stüvel commented

2023-12-15 16:44:00 +01:00

Please don't send in pull requests, unless they are fixing a bug or adding a feature for which the design has been approved. Writing code before design/approach approval is at your own risk, as the entire approach taken could be rejected.

viktorasm commented

2023-12-15 17:42:47 +01:00

First-time contributor

Please don't send in pull requests, unless they are fixing a bug or adding a feature for which the design has been approved. Writing code before design/approach approval is at your own risk, as the entire approach taken could be rejected.

Point taken. The code is part of a personal experiment, without building a proof-of-concept would be very hard to propose a final design. No expectations this will be accepted to main repo, just wanted to test the waters now versus doing that later.

> Please don't send in pull requests, unless they are fixing a bug or adding a feature for which the design has been approved. Writing code before design/approach approval is at your own risk, as the entire approach taken could be rejected. Point taken. The code is part of a personal experiment, without building a proof-of-concept would be very hard to propose a final design. No expectations this will be accepted to main repo, just wanted to test the waters now versus doing that later.

viktorasm referenced this pull request

2023-12-15 18:07:20 +01:00

Support autoscaleable deployment architectures #104275

viktorasm closed this pull request

2023-12-18 08:55:45 +01:00

Sybren A. Stüvel commented

2023-12-18 17:49:33 +01:00

You're of course completely free to do whatever you want with your time ;-)

Sending in a PR to an official repository does send a more specific signal, though, so that's what I was responding to.

You're of course completely free to do whatever you want with your time ;-) Sending in a PR to an official repository does send a more specific signal, though, so that's what I was responding to.