Universal Messaging 10.3 | Concepts | Commonly Used Features | Channel Attributes
 
Channel Attributes
Universal Messaging channels provide a set of attributes that define the behavior of the events published and stored by the Universal Messaging realm server. Each event published onto a channel has a unique event ID within the channel. 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 Name
This is the name that you assign to the channel.
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 section Multi-File Disk Stores.
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 the messages are 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, according to the conditions described in the section Multi-File Disk Stores. 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 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.
Note:
The following channel types are deprecated in Universal Messaging v10.2 and will be removed in a future version of the product: Simple, Paged, Offheap.
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 realm server. If you have configured a dead event store for the channel, the removed event will be placed in the dead event store.
Note:
The exact time at which an event is automatically removed by the realm server can be slightly later than the time resulting from the TTL. This is because the removal is done at regular intervals as scheduled by the realm server, rather than on an immediate basis.
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.
If you have configured a dead event store for the channel, the removed event will be placed in the dead event store.
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. In this case, newly arriving events are discarded until there is free capacity on the channel. See the section Storage Properties of Channels and Queues for details. If you have configured a dead event store for the channel, the discarded events will NOT be placed in the dead event store; instead, they are simply ignored.
Dead Event Store
When events are removed automatically by the realm server, either by the capacity policy of the channel, or the age (TTL) policy of the channel, or the age (TTL) policy of 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 configured to use a dead event store, and any events that are removed automatically will be moved into the dead event store. The dead event store can itself be a channel or a queue and can be created with any attributes you wish.
Note:
If you are using the JMS engine, events will be removed automatically from the channel if there is no interest in the events. This happens regardless of any capacity or TTL policy on the channel or on the events. Such removed events will NOT be placed in the dead event store. See the section Use JMS Engine / Use Merge Engine for related information.
Dead Event Store restrictions for durable subscriptions
If you have defined one or more durable subscriptions on the channel, the automatic mechanism for moving events from the channel to the dead event store can produce unpredictable results in the dead event store, in which case you should not rely on this mechanism in your production environment. These unpredictable results when using durable subscriptions can be summarized as follows:
*Durable subscriptions of type Serial or Shared: If you use event filtering for these types, the dead event store mechanism can produce unpredictable results. However, if you do not use event filtering, the dead event store mechanism will work as expected.
*Durable subscriptions of other types: In general, the behavior of the dead event store is unpredictable.
Storage Properties
Each channel has a number of storage properties associated with it, that allow you to configure operational aspects of the channel. You can set values for these properties when you create or edit the channel attributes. See the section Storage Properties of Channels and Queues for details of the storage properties.
Protobuf Descriptor
If you intend to use Google protocol buffers, you can define which protobuf descriptor file will be associated with the channel.
For information about Google protocol buffers, see the section Google Protocol Buffers in the Concepts guide.
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.