Add example demonstrating graceful shutdown #2
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
brandur
commented
Nov 9, 2023
| // finish on context cancellation. | ||
| fmt.Printf("Soft stop succeeded\n") | ||
|
|
||
| case <-time.After(100 * time.Millisecond): |
There was a problem hiding this comment.
Not super happy with this wait. It's not strictly necessary to include it, but if we don't, then we don't show any opportunity for the soft stop to work at all, so I put it in.
As I was writing the docs for graceful shutdown, I realized that it wasn't a half bad idea to include a full code sample for a realistic program that when exiting, would (1) try a soft stop to start, and (2) do a hard stop if the soft stop didn't work in time. This is somewhat non-trivial code though, and I'd be afraid to just include it it docs without testing it. I started writing the code to be actually runnable, and realized that as long as it was going to be runnable anyway, we may as well also include an example for it and commit to the repository. So that's what we do here: add an example test that shows a realistic shutdown loop demonstrating both a soft and hard stop.
brandur
force-pushed
the
brandur-graceful-shutdown-example
branch
from
de1d2bd
to
3640eff
Compare
bgentry
approved these changes
Nov 9, 2023
|
TY. |
brandur
added a commit
that referenced
this pull request
Nov 10, 2023
Follows up #2 with a few fixes/changes. As I was writing documentation for graceful shutdown I realized there were a few things that weren't quite ideal: * The job should return an error in the event of cancellation so that it can be persisted as errored and be worked again. * The example now respects either `SIGINT` or `SIGTERM`. `SIGTERM` is what's used on Heroku, but `SIGINT` is the standard signal from `Ctrl+C` in a terminal, so by respecting both we can have a program that works well in either development or a common hosted environment. * Add a third phase in which the program initiates an unclean stop by not waiting on stop any longer. This is probably something that most programs should have because it's going to be reasonably easy to write workers that accidentally don't respect context cancellation and get stuck. * Add a 10 second timeout to each phase. This is for Heroku's benefit. It'll send one `SIGTERM` and wait 30 seconds before issuing `SIGKILL`. So the program here waits 10 seconds for a soft stop, another 10 seconds for a hard stop, and then exits uncleanly on its own volition before getting `SIGKILL`ed.
brandur
added a commit
that referenced
this pull request
Nov 10, 2023
Follows up #2 with a few fixes/changes. As I was writing documentation for graceful shutdown I realized there were a few things that weren't quite ideal: * The job should return an error in the event of cancellation so that it can be persisted as errored and be worked again. * The example now respects either `SIGINT` or `SIGTERM`. `SIGTERM` is what's used on Heroku, but `SIGINT` is the standard signal from `Ctrl+C` in a terminal, so by respecting both we can have a program that works well in either development or a common hosted environment. * Add a third phase in which the program initiates an unclean stop by not waiting on stop any longer. This is probably something that most programs should have because it's going to be reasonably easy to write workers that accidentally don't respect context cancellation and get stuck. * Add a 10 second timeout to each phase. This is for Heroku's benefit. It'll send one `SIGTERM` and wait 30 seconds before issuing `SIGKILL`. So the program here waits 10 seconds for a soft stop, another 10 seconds for a hard stop, and then exits uncleanly on its own volition before getting `SIGKILL`ed.
brandur
added a commit
that referenced
this pull request
Nov 10, 2023
Follows up #2 with a few fixes/changes. As I was writing documentation for graceful shutdown I realized there were a few things that weren't quite ideal: * The job should return an error in the event of cancellation so that it can be persisted as errored and be worked again. * The example now respects either `SIGINT` or `SIGTERM`. `SIGTERM` is what's used on Heroku, but `SIGINT` is the standard signal from `Ctrl+C` in a terminal, so by respecting both we can have a program that works well in either development or a common hosted environment. * Add a third phase in which the program initiates an unclean stop by not waiting on stop any longer. This is probably something that most programs should have because it's going to be reasonably easy to write workers that accidentally don't respect context cancellation and get stuck. * Add a 10 second timeout to each phase. This is for Heroku's benefit. It'll send one `SIGTERM` and wait 30 seconds before issuing `SIGKILL`. So the program here waits 10 seconds for a soft stop, another 10 seconds for a hard stop, and then exits uncleanly on its own volition before getting `SIGKILL`ed.
brandur
added a commit
that referenced
this pull request
Nov 10, 2023
Follows up #2 with a few fixes/changes. As I was writing documentation for graceful shutdown I realized there were a few things that weren't quite ideal: * The job should return an error in the event of cancellation so that it can be persisted as errored and be worked again. * The example now respects either `SIGINT` or `SIGTERM`. `SIGTERM` is what's used on Heroku, but `SIGINT` is the standard signal from `Ctrl+C` in a terminal, so by respecting both we can have a program that works well in either development or a common hosted environment. * Add a third phase in which the program initiates an unclean stop by not waiting on stop any longer. This is probably something that most programs should have because it's going to be reasonably easy to write workers that accidentally don't respect context cancellation and get stuck. * Add a 10 second timeout to each phase. This is for Heroku's benefit. It'll send one `SIGTERM` and wait 30 seconds before issuing `SIGKILL`. So the program here waits 10 seconds for a soft stop, another 10 seconds for a hard stop, and then exits uncleanly on its own volition before getting `SIGKILL`ed.
brandur
added a commit
that referenced
this pull request
Nov 10, 2023
Follows up #2 with a few fixes/changes. As I was writing documentation for graceful shutdown I realized there were a few things that weren't quite ideal: * The job should return an error in the event of cancellation so that it can be persisted as errored and be worked again. * The example now respects either `SIGINT` or `SIGTERM`. `SIGTERM` is what's used on Heroku, but `SIGINT` is the standard signal from `Ctrl+C` in a terminal, so by respecting both we can have a program that works well in either development or a common hosted environment. * Add a third phase in which the program initiates an unclean stop by not waiting on stop any longer. This is probably something that most programs should have because it's going to be reasonably easy to write workers that accidentally don't respect context cancellation and get stuck. * Add a 10 second timeout to each phase. This is for Heroku's benefit. It'll send one `SIGTERM` and wait 30 seconds before issuing `SIGKILL`. So the program here waits 10 seconds for a soft stop, another 10 seconds for a hard stop, and then exits uncleanly on its own volition before getting `SIGKILL`ed.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
As I was writing the docs for graceful shutdown, I realized that it
wasn't a half bad idea to include a full code sample for a realistic
program that when exiting, would (1) try a soft stop to start, and (2)
do a hard stop if the soft stop didn't work in time.
This is somewhat non-trivial code though, and I'd be afraid to just
include it it docs without testing it. I started writing the code to be
actually runnable, and realized that as long as it was going to be
runnable anyway, we may as well also include an example for it and
commit to the repository.
So that's what we do here: add an example test that shows a realistic
shutdown loop demonstrating both a soft and hard stop.