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.
For information about permissible channel names, see the topic
Valid Channel and Queue Names in the Enterprise Manager section of the
Administration Guide.
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. |
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.
For stores of type Mixed you can specify the TTL attribute for individual events. Events on queues and channels of type Persistent or Reliable use the TTL set on store level and ignore any event-level TTL.
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.