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, thus 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 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 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 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.
A Mixed channel stores the Event ID in the same way as a Reliable channel, but the storage of events is specified in the nConsumeEvent by calling setPersistent(). In JMS the persistence is set by the DeliveryMode.
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 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.
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.
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 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.
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 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.
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.