job queue

database-based job queue processing

The basic Laravel job queue system has been configured to work with a database backend.

The production env file has ‘QUEUE_CONNECTION’ set to ‘database’

Initially, the production system will need to be configured to run

php artisan queue:work –tries=1

on startup.

The production system should also be configured to use supervisor to run the ‘queue:work’ processing, which will manage automatic restarts in the case of any job queue processing hard failures.

We’re currently not defining multiple queues or priorities - just using one ‘default’ to get started.

More docs are available at https://laravel.com/docs/5.8/queues

An example job is included to test the jobs are running.

From tinker, run

\App\Jobs\ExampleJob::dispatch();

This should provide a relatively immediate output of the current timestamp in the standard log.

\App\Jobs\ExampleJob::dispatch()->delay(now()->addSeconds(5));

This will create a job that will be delayed in execution by at least 5 seconds.

The Laravel ‘failed_jobs’ migration is included. The documentation link above shows more information on how to programatically deal with specifc failed jobs.

other notes

This relates to earlier notes in trello cards 62 and 142 and 114, and packages such as https://github.com/imTigger/laravel-job-status, https://github.com/spatie/laravel-failed-job-monitor and https://github.com/spatie/laravel-queueable-action were packages noted for further investigation. Initial review shows there may be some value in one or more of these, but more investigation can be done later - holding up enabling the base job queue functionality should not be done at this stage.

startup script

./script/queue

will connect to the docker system, restart queue workers (which doesn’t actually ‘restart’ them, just kills them), and will start up 3 more jobs processors.

Longer term, ‘supervisor’ should be set up on production system to manage the job runners.