Queues and schedule

Queue workers and the scheduler run in your own Scaleway project, next to the web container. After your first deploy they show up on the page of the environment.

Queues#

The Queues tab lists the queues of the environment and their workers. Workers move to a new release right after the web container has switched to it.

Where the jobs wait is chosen when the environment is set up: in its database, in a queue at Scaleway Queues, or nowhere, in which case a job runs where it is dispatched. See A queue. The worker is the same in each case.

By default the worker works the default queue of your application. Name the queues in your brewless.yml and the next deploy has the worker work those, the first first:

environments:
  production:
    worker:
      queues: [default, mail]

This needs brewless/laravel 0.3 or later. Taking queues out of the file again keeps what the worker works; write [default] to go back.

If a worker gives no sign of life for more than three minutes, the console says so. Check the trigger and the worker container in your Scaleway console.

Failed jobs#

Failed jobs can be put back on the queue from the console. The next run of the worker picks them up.

Note

Why a job failed is in your application's own failed_jobs table. Brewless does not read it: an error can quote the data it failed on.

How the worker is called#

Nothing stays running on a serverless container: something has to call the worker. How depends on where the jobs wait.

Jobs in a queue at Scaleway Queues. The queue calls the worker as soon as a job is put on it, so a job runs right away: a sign-in code by mail, a file to process. Crons call the scheduler only at the moments your schedule has work. A task that runs every fifteen minutes gets a cron every fifteen minutes; one that runs at 02:10 gets one at 02:10. Nothing calls the worker in between, so it, and a serverless database, can sleep.

This needs brewless/laravel 0.4 or later: every job your application queues is then signed with the secret of its machine entrance, and the worker only runs a job whose signature holds. The worker runs a job the way queue:work does, with its tries, its backoff, its failed() and the failed jobs table. A job is given a few minutes before its queue would deliver it again: three, or the worker's timeout from brewless.yml plus half a minute when that is longer. Give a worker that runs long jobs a timeout above the longest job.

The moments come from your schedule itself, read from the worker on every deploy. Scaleway's crons run in UTC; a task in another time zone, or written in a way a cron cannot copy, has the scheduler called every minute instead, which never misses one.

Jobs in the database. A trigger calls the worker every minute for one tick of the schedule, and then the queue, because the jobs in the database have to be looked for. That keeps the database awake all day; for a serverless database a queue at Scaleway Queues is the cheaper choice.

Schedule#

scheduler: false in your brewless.yml leaves the schedule out from the next deploy on; the queue is still worked. scheduler: true puts it back; leaving the key out keeps what stands.

The Schedule tab lists when the worker is called for the schedule: the crons at Scaleway. A task you add to your schedule gets its moment with the next deploy.