Channel Attributes
Universal Messaging channels provide a set of attributes that define the behaviour of the events published and stored by the Universal Messaging Realm Server. Each event published onto a channel has a unique ID within the channel called Event ID. Using this event ID, it is possible for subscribers to re-subscribe to events on a channel from any given point. The availability of the events on a channel is defined by the chosen attributes of the channel upon creation. Channels can be created either using the Universal Messaging Enterprise Manager or programmatically using any of the Universal Messaging Enterprise APIs.
There are a number of important channel attributes which are discussed below.
Channel Type
Each channel has an associated channel type. Universal Messaging channels can be of the types described in the following table. The difference lies in the type of physical storage used for each type and the performance overhead associated with each type.
Channel Type | Description |
Persistent | Persistent channels have their messages stored in the Universal Messaging Realm's persistent channel disk-based store. The persistent channel store is a high performance file-based store that uses one or more files for each channel on that Realm, thus facilitating migrating whole channels 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 channel 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 channel 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 channel 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 channels allow you 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 channel, the TTL and Capacity can be set; if you supply a TTL for an event, this is used instead of the channel TTL. Events stored persistently are either stored on a single or multiple files in the same manner as a persistent channel. |
Reliable | Reliable channels 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 channels 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 channels will be removed from the channel as a matter of policy. However, as Universal Messaging guarantees never to reuse event IDs within a channel, new messages published in those channels will get assigned event IDs incremented from the event ID of the last message prior to the previous instance stopping. |
Simple | Simple channels have their messages stored in the Universal Messaging Realm's own memory space, thus supplying a high-speed channel type. The difference between Simple and Reliable is that the event IDs are reset to 0 in a Simple channel whenever the Universal Messaging Server is restarted, whereas Reliable channels increment and store the Event ID on disk rather than in memory so that in the event of failure, event IDs are not reset to 0. Simple channels are not supported across realms in a cluster. |
Transient | A transient channel is like a simple channel in that no event characteristics are stored persistently. In addition to this, data is only ever written to a transient channel when 1 or more consumers are connected to the channel and are able to consume this data. Unlike the simple channel which stores event data in memory, transient channels do not store anything, not even in memory. Transient channels can be thought of as a relay between 1 or more publishers and 1 or more subscribers. Transient channels are not supported across realms in a cluster. |
Off-heap | Off-heap channels, similar to reliable channels, store the events in memory, but this channel 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 channels allows users access to high speed, off-heap memory mapped files as the basis for the event storage. As for the other channel types, each channel or queue has its own unique file mapping. While similar to the off-heap channel type, where the events are stored in the off heap memory, the paged channel store is also persistent, thereby allowing recovery of events that are written into this store. |
Channel TTL
The TTL ("time to live") for a channel defines how long (in milliseconds) each event published to the channel will remain available for subscribers to consume. Specifying a TTL of 0 will mean that events will remain on the channel indefinitely. If you specify a TTL of 10000, then after each event has been on the channel for 10000 milliseconds, it will be automatically removed by the server.
Channel Capacity
The capacity of a channel defines the maximum number of events that may remain on a channel once published. Specifying a capacity of 0 will mean that there is no limit to the number of events on a channel.
Example: If you specify a capacity of 10000, then if there are 10000 events on a channel, and another event is published to the channel, the oldest event on the channel will be automatically removed by the server to make room for the new event.
Note: You can use the storage property
Honour Capacity to prevent further events being published to the channel if the channel capacity has been reached. See the section
Storage Properties of Channels and Queues for details.
Dead Event Store
When events are removed automatically, either by the capacity policy of the channel or the age (TTL) policy of the individual events, and they have not been consumed, it may be a requirement for those events to be processed separately. If so, channels or queues can be created with a dead event store so any events that are purged automatically before being consumed will be moved into the dead event store. Dead event stores themselves can be a channel or a queue and can be created with any attributes you wish.
Use JMS Engine / Use Merge Engine
By default, Universal Messaging retains all events on any given channel until the events reach their individual time-to-live limit (see the description of Channel TTL above).
This default behavior can be modified by selecting either of the following optional engines:
Engine | Description |
JMS Engine | The JMS Engine deals with JMS topics within Universal Messaging. The JMS engine causes events to remain on the channel as long as there is "interest" in receiving the events. In this sense, "interest" means that at least one of the following conditions is met:  there are one or more active non-durable subscribers on the channel who have not yet consumed the events; there are one or more durable subscribers on the channel who have not yet consumed the events. When there is no more "interest" for an event, the event will be deleted automatically. For further information on the JMS engine, see the section Fanout Engine in the Developer Guide. |
Merge Engine | The merge engine is similar to the default engine, in that events are retained until they reach their TTL limit. The Merge Engine is used for Registered Events, and allows delivery of just the portion of an event's data that has changed, rather than of the entire event. In this scenario, the first time an event is published, it is published with all of its data fields. Thereafter, if another event occurs in which only a small number of the data fields have changed compared to the original published event, Universal Messaging allows you to send an event containing just the modified data fields. This process is known as delta delivery, and the events that contain just the modified fields are called event deltas. This pattern can be continued over a set of published events, so that each published event just contains the delta from the previous published event in the set. By publishing just delta events rather than full events, the amount of data being transferred on the channel can be considerably reduced. For further details on the merge engine and event deltas for Java, see the section The Merge Engine and Event Deltas in the Developer Guide. For other programming languages, see the appropriate language-specific part of the Developer Guide. |
The merge engine and the JMS engine are mutually exclusive: you can choose one but not both of these engines. If you choose neither of these engines, the default engine is used.
Channel Keys
Channels can also be created with a set of channel keys which define how channel events can be managed based on the content of the events. For more information, please see the section
Channel Publish Keys.
Note on differences between Administration API and Enterprise Manager for Channel Creation
If you use the Administration API to create a channel rather than using the Enterprise Manager, some channel attributes must be set explicitly that in the Enterprise Manager are set implicitly according to context.
For example, the API offers a "cluster wide" flag, indicating that the new channel will be created on all cluster realm nodes. In the Enterprise Manager, this flag is not available directly, but will be applied automatically to the channel if you create the channel in the context of the cluster node rather than in the context of a realm node.