Queues

2 mins

V6 ProV6 MSPV6 Core

Overview

Most rConfig backend functionality is based on Laravel Jobs and Queues that easily creates queued jobs that may be processed in background processes. While most rConfig administrators do not need to know the ins and outs of the queueing system, some basics are important for entry level troubleshooting. rConfig v6 has brought some enhancements to the rConfig queueing scheduler. Namely the introduction of new queues, and a batch queueing system.

How it works

As of rConfig V6 we have introduced new queues, and a batch queueing system. The new queues 'downloadqueue' and 'lastqueue'. All device download jobs are sent to the 'downloadqueue' and will be processed separately to the default queue which will continue to handle email sending, system backups etc.. The 'lastqueue' is currently not used, but is expected to be a queue of last resort. The separated queues mean device downloads will not be impacted by other queues jobs. All queues are processed in a First In First Out FIFO algorithm.

_Batches _ are a new queueing concept in rConfig v6. Previously, rConfig would process all devices in a scheduled task as a single job. This meant any failures or delays would affect the entire job. No, with batches, all devices to be downloaded in a single scheduled (or manually run) task, will be sent in a 'batch', then delivered to the queue 'downloadqueue' as individual jobs. This will allow for non-blocking of queues and greater troubleshooting. i.e. of a job or jobs in the batch fails, ir will not block the entire job, all other jobs will complete unimpeded and you can review the batch for any failures. See output below.

rConfig deploys with a Laravel Queue monitoring tool called Horizon. This is accessible from the settings menu, and only users with the 'admin' role can access it.

ℹ️ Horizon provides a beautiful dashboard and code-driven configuration for your Laravel powered Redis queues. Horizon allows you to easily monitor key metrics of your queue system such as job throughput, runtime, and job failures.

There are 4 Important sections to the Horizon Application

  • The Dashboard
    • High level view of running, completed and failed jobs
    • Horizon and Queuing status
  • Batches
    • As of v6 all device download jobs are sent as a batch of jobs. You can monitor status of those batches here.
  • Pending Jobs
    • Jobs awaiting executing by the Laravel applications
  • Completed Jobs
    • History of all completed jobs.
    • History will be flush on system restart, or rConfig update
  • Failed Jobs
    • View log and details of any failed jobs.
    • Any failed jobs should be notified to rConfig Support for investigation
    • Normally, this should be empty

As of v6.11.0, under certain conditions some of the default Horizon queue settings need to be changed. This should be done with caution and only after consultation with rConfig support. Each extra process or increased timeout will consume more resources on the server, this needs to be monitored carefully. The default settings are as follows;

HORIZON_PROD_TIMEOUT=60
HORIZON_MIN_PROCESS=1
HORIZON_MAX_PROCESS=10

These settings can be changed (or if not already present, added) in the .env file. Simply the description for each setting is as follows;

  • HORIZON_PROD_TIMEOUT
    • The number of seconds a job may run before it is terminated as a timeout
  • HORIZON_MIN_PROCESS
    • The minimum number of processes Horizon should maintain - default 1
  • HORIZON_MAX_PROCESS
    • The maximum number of processes Horizon should maintain - default 5

If you update the .env file with new settings, you must run the clear-all command. This can be done from the command line with the following command;

php artisan rconfig:clear-all
Edit this page on GitHub
Table of Contents