Universal Messaging channels provide a set of attributes. Depending on the options chosen, these 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.

The TTL 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.

The capacity of a channel defines the maximum number of events 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. 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 1st event will be automatically removed by the server.

Universal Messaging channels can be of the following types:

The difference lies in the type of physical storage used for each type and the performance overhead associated with each type.

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 a separate file for each channel on that Realm facilitating migrating whole channels to different Realms. 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 TTL or capacity policy. Messages purged from a persistent channel are marked as deleted however 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. This augments the high performance of the Universal Messaging Realm.

Mixed channels allow the 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 channel the TTL and Capacity can be set, if the user supplies a TTL for an event this is used instead of the channel TTL.

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 not to ever 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 channels have their messages stored in the Universal Messaging Realm's own memory space supplying a high-speed channel type. The difference between a Simple and Reliable is the fact that the event ids are reset to 0 in a Simple channel whenever the Universal Messaging Server is restarted.

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 said 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.

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.

In addition to the 3 attributes above which define storage behavior for events, there are a number of other important attributes that can be set for a channel.

When events are removed automatically, either by the capacity policy of the channel or the age (TTL) policy of the events itself 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 from that have not been 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.

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 Channel Publish Keys section

The cluster wide flag indicates that a channel is created on all cluster realm nodes. For more information on clustering please see our clustering section.

There are 2 types of optional engine which a channel can use: