-
Notifications
You must be signed in to change notification settings - Fork 50
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[AAP-27692] Add middleware that apps can use to handle graceful timeout signal #581
Conversation
dropped introspecting into the X-REQUEST-ID header because I think if apps are following django-ansible-base/docs/logging.md Lines 12 to 29 in cdbea30
|
56a9e2d
to
fec8a71
Compare
7f43463
to
6023e24
Compare
731809d
to
6fb318c
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great. Quality utility.
ae1c43e
to
85d4464
Compare
d653471
to
9ceba08
Compare
re-confirmed with awx PR ansible/awx#15447
|
9ceba08
to
cd45969
Compare
uwsgi 2.0.22+ offers option to send a user-defined signal at for a "graceful" timeout before the real harakiri occurs. gunicorn sends SIGABRT (signal 6) as graceful timeout signal before sending SIGKILL Apps can use this middleware to log a traceback indicating what code was executing when the graceful timeout signal was received. log error message if trying to use middleware in incompatible environment
cd45969
to
a56bdee
Compare
Quality Gate passedIssues Measures |
uwsgi 2.0.22+ offers option to send a user-defined signal at for a "graceful" timeout before the real harakiri occurs (we can configure any signal we want -- so we can go with SIGABRT)
gunicorn sends SIGABRT (signal 6) as graceful timeout signal before sending SIGKILL.
Apps can use this middleware to log a traceback indicating what code was executing when the graceful timeout signal was received.
Will use this instead of middleware defined in awx for ansible/awx#15447