According to gunicorn `timeout` docs, async workers shouldn't be terminated after the request time exceeds the specified timeout as long as the worker process is still communicating. This makes sense for async workers since they generally don't block other requests from processing. This is the behaviour we've seen on notifications-api - requests can sometimes take much longer than the default 30 second timeout and still succeed. For the admin app however gunicorn has been shutting down workers after 30s with `[CRITICAL] WORKER TIMEOUT`. This results in a 502 response from the admin app. Most of these requests fail because the underlying requests to the api is taking longer than 30 seconds, however we haven't seen this in the logs originally since unlike the admin app, api requests succeed (even though their response is no longer needed). This seems like a bug in newer versions of gunicorn, downgrading it to the version that the api is currently using solves the problem by allowing admin requests to take longer than 30 seconds. (Tested by trying requests with a `time.sleep(30)` locally). It's not clear what exactly the bug in gunicorn is, but this also potentially unblocks eventlet workers and allows them to process more than one request at a time.
notifications-admin
GOV.UK Notify admin application.
Features of this application
- Register and manage users
- Create and manage services
- Send batch emails and SMS by uploading a CSV
- Show history of notifications
First-time setup
Brew is a package manager for OSX. The following command installs brew:
/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
Languages needed
brew install node
NPM is Node's package management tool. n is a tool for managing
different versions of Node. The following installs n and uses the latest
version of Node.
npm install -g n
n latest
npm rebuild node-sass
The app runs within a virtual environment. We use mkvirtualenv for easier working with venvs
pip install virtualenvwrapper
mkvirtualenv -p /usr/local/bin/python3 notifications-admin
Install dependencies and build the frontend assets:
workon notifications-admin
./scripts/bootstrap.sh
Rebuilding the frontend assets
If you want the front end assets to re-compile on changes, leave this running in a separate terminal from the app
npm run watch
Create a local environment.sh file containing the following:
echo "
export NOTIFY_ENVIRONMENT='development'
export FLASK_APP=application.py
export FLASK_DEBUG=1
export WERKZEUG_DEBUG_PIN=off
"> environment.sh
AWS credentials
Your aws credentials should be stored in a folder located at ~/.aws. Follow Amazon's instructions for storing them correctly
Running the application
workon notifications-admin
./scripts/run_app.sh
Then visit localhost:6012
Updating application dependencies
requirements.txt file is generated from the requirements-app.txt in order to pin
versions of all nested dependencies. If requirements-app.txt has been changed (or
we want to update the unpinned nested dependencies) requirements.txt should be
regenerated with
make freeze-requirements
requirements.txt should be committed alongside requirements-app.txt changes.