Glossary

Glossary

Messaging Service Concepts

The Messaging Service is a multi-tenant, message queue implementation that utilizes a RESTful HTTP interface to provide an asynchronous communications protocol, which is one of the main requirements in today’s scalable applications.

Queue
Queue is a logical entity that groups messages. Ideally a queue is created per work type. For example, if you want to compress files, you would create a queue dedicated for this job. Any application that reads from this queue would only compress files.
Message
Message is sent through a queue and exists until it is deleted by a recipient or automatically by the system based on a TTL (time-to-live) value.
Claim
Claim is a mechanism to mark messages so that other workers will not process the same message.
Worker
Worker is an application that reads one or multiple messages from the queue.
Producer
Producer is an application that creates messages in one or multiple queues.
Publish - Subscribe
Publish - Subscribe is a pattern where all worker applications have access to all messages in the queue. Workers can not delete or update messages.
Producer - Consumer
Producer - Consumer is a pattern where each worker application that reads the queue has to claim the message in order to prevent duplicate processing. Later, when the work is done, the worker is responsible for deleting the message. If message is not deleted in a predefined time (claim TTL), it can be claimed by other workers.
Message TTL
Message TTL is time-to-live value and defines how long a message will be accessible.
Claim TTL
Claim TTL is time-to-live value and defines how long a message will be in claimed state. A message can be claimed by one worker at a time.
Queues Database
Queues database stores the information about the queues and the messages within these queues. Storage layer has to guarantee durability and availability of the data.
Pooling
If pooling enabled, queuing service uses multiple queues databases in order to scale horizontally. A pool (queues database) can be added anytime without stopping the service. Each pool has a weight that is assigned during the creation time but can be changed later. Pooling is done by queue which indicates that all messages for a particular queue can be found in the same pool (queues database).
Catalog Database
If pooling is enabled, catalog database has to be created. Catalog database maintains queues to queues database mapping. Storage layer has to guarantee durability and availability of data.
Creative Commons Attribution 3.0 License

Except where otherwise noted, this document is licensed under Creative Commons Attribution 3.0 License. See all OpenStack Legal Documents.