Queue Manager Directives

The queue manager allows RealityServer to connect to an external queuing service to fetch jobs to process and to submit jobs to the queue. The Queue manager is configured inside the <user queue_manager> directive. Within that block there is then further user directives to configure settings for tasks that are performed when a job completes. For example the <user http_post> directive configures the HTTP postback task type. The queue manager may also use configuration defined elsewhere such as the <user aws> configuration which defines configuration to allow Amazon Web Services to be used with RealityServer. Here is an example configuration for the queue manager:

<user queue_manager>
    allow_command get_version
    allow_command example_command
    listen_queue example_sqs_queue_1
    <user http_post>
        follow_redirects on
        verify_ssl off
    </user>
</user>

The queue manager directives do not configure the queue itself. These are handled by additional queue modules. Those queue modules create named queues which are then referenced by the listen_queue directive. This configures the queue that RealityServer will listen to for work. Only a single queue may be configured for listening however any named queue defined by a queue module may be submitted to. Currently the only module available is for using Amazon SQS as an external queue. Additional modules are under development.

The following queue manager directives are supported within the <user queue_manager> section. Pay particular attention to the context of each option since many of these configuration directives are nested in different user sections. For example, the follow_redirects directive in the example above is in the queue_manager/http_post context.

allow_command

The name of a command that is allowed to be queued. This controls which RealityServer commands are permitted to be used by the queuing system. You may specify this directive multiple times, effectively building a whitelist of allowed commands. By default no commands are allowed with queuing. This is to ensure that only workloads that you explicitly allow are able to be placed on the queue. Any call to queue_manager_submit_job which does not contain an explicitly allowed command will be rejected with an error. If you have created a job in the queue outside RealityServer (by manually inserting a payload into the queue) and this job contains a command that has not been explicitly allowed then the job will be returned to the queue with an error state. The exact processing of errors will depend on the chosen queue module.

listen_queue

The name of queue which has been defined elsewhere in the configuration by setting the configuration directives for a known queue module (e.g., sqs). This is the queue on which RealityServer will listen for jobs. If defined, when RealityServer starts it will being listening to the queue and automatically executing the jobs it finds. All queue modules have the ability to name their queues in their configuration. This name is used both by this directive when determining where to listen as well as for submitting jobs with the queue_manager_submit_job command. If no listen_queue is defined then RealityServer will not listen for queued jobs (however jobs can still be submitted).

default_queue

Specifies the default queue that will be used by the queue_manager_submit_job command if no queue_name parameter is given.

follow_redirects

Defined inside the <user http_post> section inside the <user queue_manager> section. Controls whether or not redirects are followed during HTTP postback tasks. It may be desirable to prevent this in some cases. By default redirects will not be followed.

verify_ssl

Defined inside the <user http_post> section inside the <user queue_manager> section. Controls whether or not the postback request made when a job is completed checks whether the SSL certificate of the receiving server is valid. By default SSL certificates are verified. Disabling this can be useful for working with self-signed certificates.