Universal Messaging 9.12 | 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
Each queue has an associated queue type. A Universal Messaging queue can be one of the types shown in the following table. The difference between the types lies in the type of physical storage used for each type and the performance overhead associated with each type.
Queue Type
Description
Simple
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.
Simple queues are not supported across realms in a cluster.
Reliable
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
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.
For information about setting up a multi-file disk store for persistent channels or persistent queues, see the description of the storage parameter Events per Spindle in the section Storage Properties of Channels and Queues.
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
Mixed queues allow users to specify whether the event is stored persistently or in memory, as well as 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.
Transient
A transient queue is like a simple queue in that no event characteristics are stored persistently. In addition to this, data is only ever written to a transient queue when 1 or more consumers are connected to the queue and are able to consume this data. Unlike the simple queue which stores event data in memory, transient queues do not store anything, not even in memory. Transient queues can be thought of as a relay between 1 or more publishers and 1 or more subscribers.
Transient queues are not supported across realms in a cluster.
Off-heap
Off-heap queues, similar to reliable queues, store the events in memory, but this queue type uses off-heap memory. This allows the normal JVM heap memory to be left free for short lived events, while longer living events can be stored off the JVM heap. This reduces the work the garbage collector needs to do to manage these events since they are out of range of the garbage collector.
Paged
Paged queues allows users access to high speed, off-heap memory mapped files as the basis for the event storage. As for the other queue types, each queue has its own unique file mapping. While similar to the off-heap queue type, where the events are stored in the off heap memory, the paged queue store is also persistent, thereby allowing recovery of events that are written into this store.
Copyright © 2013-2019 | Software AG, Darmstadt, Germany and/or Software AG USA, Inc., Reston, VA, USA, and/or its subsidiaries and/or its affiliates and/or their licensors.