Universal Messaging Concepts : Commonly Used Features : Queue Attributes
Queue Attributes
Universal Messaging queues provide 3 main attributes. Depending on the options chosen, these define the behaviour of the events published and stored by the Universal Messaging Realm Server. The availability of the events on a queue is defined by the chosen attributes of the queue upon creation.
Each of these attributes are described in the following sections.
Queue TTL
The TTL for a queue defines how long (in milliseconds) each event published to the queue will remain available to consumers. Specifying a TTL of 0 will mean that events will remain on the queue indefinitely. If you specify a TTL of 10000, then after each event has been on the queue for 10000 milliseconds, it will be automatically removed by the server.
Queue Capacity
The capacity of a queue defines the maximum number of events may remain on a queue once published. Specifying a capacity of 0 will mean that there is no limit to the number of events on a queue. If you specify a capacity of 10000, then if there are 10000 events on a queue, and another event is published to the queue, the 1st event will be automatically removed by the server.
Queue Type
Universal Messaging queues can be of 4 different types, simple, reliable, persistent and mixed. The difference lies in the type of physical storage used for each type and the performance overhead associated with each type.
Simple Queues
Simple queues have their messages stored in the Universal Messaging Realm's own memory space supplying a high-speed queue type. The difference between a Simple and Reliable is the fact that the event ids are reset to 0 in a Simple queue whenever the Universal Messaging Server is restarted.
Reliable Queues
Reliable queues have their messages stored in the Universal Messaging Realm's own memory space. The first fact that is implied is that the maximum number of bytes that all messages across all reliable queues within a Universal Messaging Realm is limited by the maximum heap size available to the Java Virtual Machine hosting that Realm. The second fact implied is that if the Universal Messaging Realm is restarted for any reason, all messages stored on reliable queues will be removed from the queue as a matter of policy. However, as Universal Messaging guarantees not to ever reuse event ids within a queue, new messages published in those queues will get assigned event ids incremented from the event id of the last message prior to the previous instance stopping.
Persistent Queues
Persistent queues have their messages stored in the Universal Messaging Realm's persistent queue disk-based store. The persistent queue store is a high performance file-based store that uses one or more files for each queue on that Realm, thus facilitating migrating whole queues to different Realms. All messages published to a persistent queue will be stored to disk, hence it is guaranteed that they will be kept and delivered to subscribers until it is purged or removed as a result of a "Time to Live" (TTL) or capacity policy.
Messages purged from a persistent queue are marked as deleted, however the store size will not be reduced immediately. If the store is backed by a single file, the store size will not be reduced until maintenance is performed on the queue using the Universal Messaging Enterprise Manager or an Administration API call. Stores backed by multiple files will be cleaned up through the removal of individual files once the events stored on a particular file have all been marked as deleted. This augments the high performance of the Universal Messaging Realm.
Mixed Queues
Mixed queues allow users to specify whether the event is stored persistently or in memory, as well as that the "Time To Live" (TTL) of the individual event. On construction of a Mixed queue, the TTL and Capacity can be set, and if the user supplies a TTL for an event this is used instead of the queue. Events stored persistently are either stored on a single file or on multiple files in the same manner as a persistent queue.
Copyright © 2013-2016 Software AG, Darmstadt, Germany.

Product LogoContact Support   |   Community   |   Feedback