9eada23392
Flask-SQLAlchemy sets up a connection pool with 5 connections and will create up to 10 additional connections if all the pool ones are in use. If all connections in the pool and all overflow connections are in use, SQLAlchemy will block new DB sessions until a connection becomes available. If a session can't acquire a connections for a specified time (we set it to 30s) then a TimeoutError is raised. By default db.session is deleted with the related context object (so when the request is finished or app context is discarded). This effectively limits the number of concurrent requests/tasks with multithreaded gunicorn/celery workers to the maximum DB connection pool size. Most of the time these limits are fine since the API requests are relatively quick and are mainly interacting with the database anyway. Service callbacks however have to make an HTTP request to a third party. If these requests start taking a long time and the number of threads is larger than the number of DB connections then remaining threads will start blocking and potentially failing if it takes more than 30s to acquire a connection. For example if a 100 threads start running tasks that take 20s each with a max DB connection pool size of 10 then first 10 threads will acquire a connection right away, next 10 tasks will block for 20 seconds before the initial connections are released and all other tasks will raise a TimeoutError after 30 seconds. To avoid this, we perform all database operations at the beginning of the task and then explicitly close the DB session before sending the HTTP request to the service callback URL. Closing the session ends the transaction and frees up the connection, making it available for other tasks. Making calls to the DB after calling `close` will acquire a new connection. This means that tasks are still limited to running at most 15 queries at the same time, but can have a lot more concurrent HTTP requests in progress.
notifications-api
Notifications api Application for the notification api.
Read and write notifications/status queue. Get and update notification status.
Setting Up
AWS credentials
To run the API you will need appropriate AWS credentials. You should receive these from whoever administrates your AWS account. Make sure you've got both an access key id and a secret access key.
Your aws credentials should be stored in a folder located at ~/.aws. Follow Amazon's instructions for storing them correctly.
### Virtualenv
mkvirtualenv -p /usr/local/bin/python3 notifications-api
### environment.sh
Creating the environment.sh file. Replace [unique-to-environment] with your something unique to the environment. Your AWS credentials should be set up for notify-tools (the development/CI AWS account).
Create a local environment.sh file containing the following:
echo "
export SQLALCHEMY_DATABASE_URI='postgresql://localhost/notification_api'
export SECRET_KEY='dev-notify-secret-key'
export DANGEROUS_SALT='dev-notify-salt'
export NOTIFY_ENVIRONMENT='development'
export ADMIN_CLIENT_SECRET='dev-notify-secret-key'
export ADMIN_BASE_URL='http://localhost:6012'
export FROM_NUMBER='development'
export MMG_URL='https://api.mmg.co.uk/json/api.php'
export MMG_API_KEY='MMG_API_KEY'
export LOADTESTING_API_KEY='FIRETEXT_SIMULATION_KEY'
export FIRETEXT_API_KEY='FIRETEXT_ACTUAL_KEY'
export STATSD_PREFIX='YOU_OWN_PREFIX'
export NOTIFICATION_QUEUE_PREFIX='YOUR_OWN_PREFIX'
export REDIS_URL="redis://localhost:6379/0"
export FLASK_APP=application.py
export FLASK_DEBUG=1
export WERKZEUG_DEBUG_PIN=off
"> environment.sh
NOTES:
- Replace the placeholder key and prefix values as appropriate
- The SECRET_KEY and DANGEROUS_SALT should match those in the notifications-admin app.
- The unique prefix for the queue names prevents clashing with others' queues in shared amazon environment and enables filtering by queue name in the SQS interface.
Postgres
Install Postgres.app. You will need admin on your machine to do this.
Redis
To switch redis on you'll need to install it locally. On a OSX we've used brew for this. To use redis caching you need to switch it on by changing the config for development:
REDIS_ENABLED = True
To run the application
First, run scripts/bootstrap.sh to install dependencies and create the databases.
You need to run the api application and a local celery instance.
There are two run scripts for running all the necessary parts.
scripts/run_app.sh
scripts/run_celery.sh
Optionally you can also run this script to run the scheduled tasks:
scripts/run_celery_beat.sh
To test the application
First, ensure that scripts/bootstrap.sh has been run, as it creates the test database.
Then simply run
make test
That will run flake8 for code analysis and our unit test suite. If you wish to run our functional tests, instructions can be found in the notifications-functional-tests repository.
To run one off tasks
Tasks are run through the flask command - run flask --help for more information. There are two sections we need to
care about: flask db contains alembic migration commands, and flask command contains all of our custom commands. For
example, to purge all dynamically generated functional test data, do the following:
Locally
flask command purge_functional_test_data -u <functional tests user name prefix>
On the server
cf run-task notify-api "flask command purge_functional_test_data -u <functional tests user name prefix>"
All commands and command options have a --help command if you need more information.