Basic Principle
Why would you want to have a queuing system in RealityServer? In some use cases executing work as soon as it has been requested is not desirable. Consider for example a rendering server that an application is using. What if 500 users all request a rendering at the same time? RealityServer will try, valiantly to render all of these jobs at the same time. The likely result is that the resources of the server will be exhausted. Queuing is a way to control the flow of work so that RealityServer can process an acceptable amount of work at a time.
As an example consider the following use case. You have a website where users can interactively lay out furniture in their living room. The visuals for the interactive part are handled by WebGL in your application but you want to have the ability to generate fully photorealistic renderings on demand. When the user asks for a photoreal render a job is queued by the queue manager. A listening RealityServer picks up the job and renders the image and when complete automatically uploads it back to your web server. There it can trigger logic to display the result to the user, put it in their account or other actions.
This is just one example of a common use case that previously would have required implementing a queuing system from scratch, integrating it with RealityServer and then managing and maintaining that queue. The Queue Manager removes the need for all of this and allows you to natively queue and execute jobs using just RealityServer and an external queuing service. The idea is simple:
- Configure RealityServer for queuing
- Submit jobs using the queue_manager_submit_job command
- Listen for jobs on the queue with one or more RealityServers
- Jobs are pulled off the queue and executed
- When complete, jobs run their defined tasks to process the results
Message queues are a topic of intense debate and discussion. The concept is straightforward, a queue accepts messages, those messages can then be retrieved from the queue. A key detail is that at most one receiver can retrieve the message at any time. This detail may vary for different types of queues, as will other details such as whether the queue guarantees order (FIFO) or not. Implementing a robust scalable and fast message queue is a highly non-trivial task. For this reason many queuing libraries and services exist. Some example are Amazon SQS, Azure Queue Storage and RabbitMQ. There is also a protocol designed specifically for queuing called AMQP.
To leverage the large volume of existing message queue work done by the industry RealityServer uses a modular queuing architecture which is not tied to a specific queuing implementation. Currently it offers direct support for AWS SQS however additional integrations are being developed. Using this approach you can take advantage of an already existing, robust, scalable, monitored and easy to use queue service that is fully managed.
AWS SQS was chosen as the first queuing module to be implemented since it allows for integration with many other useful AWS services. However SQS can be used with servers residing outside AWS, so you are not tied to using their EC2 offering for hosting. Queues can be easily setup in the AWS console and then configured in RealityServer.
The queue manager is configured using dedicated directives in the realityserver.conf configuration file. Refer to the Queue Manager Directives section of the RealityServer Configuration Guide for more details.