When you are deploying an application to production that includes a background queue, it is important to also setup a process monitor to make sure the worker stays up.
One of the most popular process monitor is supervisord, which also happens to be the one included in the Laravel guide on queues which makes it pretty much the default process monitor on a Laravel deployment.
Many background queue libraries, including the one that came with Laravel will automatically retry jobs that fails due to an exception. They usually also include a way to control how many times the jobs should be retried before giving up and moving it to the failed jobs store.
php artisan queue:listen connection-name --tries=3
One thing to keep in mind is that supervisord also includes a way to control the
maximum number of attempts to start a process after serial crashes.
When this limit is reached, it will stop trying to restart the process and the process will be put into
FATAL state. This number is controlled via the configuration entry called
startretries, and it defaults to
In most cases, one wouldn’t need to change this setting. But, if you set the number of retries
on job queue to be larger than
3, you need to make sure that the
startretries is also
increased accordingly. If the
startretries is set to a number that is less than the
it could cause an issue where the supervisord retry limit is reached before the job retries
limit is reached. When this happens, the process is put into a
FATAL state, and the worker process
doesn’t get started anymore, halting the entire job queue.
[program:laravel-worker] process_name=%(program_name)s_%(process_num)02d command=php /home/forge/app.com/artisan queue:work sqs --sleep=3 --tries=5 autostart=true autorestart=true startretries=5 user=forge numprocs=8 redirect_stderr=true stdout_logfile=/home/forge/app.com/worker.log
So, remember, make sure to keep the queue worker tries equal to or smaller than the supervisord’s
to make sure the failing jobs get moved to the failed jobs queue before they halt the entire job queue.
Of course this won’t help if the queue is full of jobs that keeps failing, but in that scenario, you
should really take a look at your queue worker code anyway.