Fanout Engine
The Universal Messaging Queue and Channel Fanout Engines are used to store and forward events based on the channel type. JMS uses topics and messages which are equivalent to Universal Messaging channels and events respectively.
Universal Messaging offers several channel types, each of which have different requirements when storing data. The available channel types are summarized in the section
Channel Attributes in the Universal Messaging Concepts guide.
The Fanout Engine for Universal Messaging Provider for JMS uses different criteria to determine storage of events.
No replay of messages means that it is not necessary to store events if there is no
interest on the channel or once they have been consumed regardless of the channel type.
Durable Subscribers require the engine to store the events until the subscriber becomes active and consumes the events. For more information, see
Engine Differences.
Interest
The Fanout Engine for Universal Messaging Provider for JMS deals with events published to channels based on 'interest'. If there is no interest present on the channel then any events published can be immediately discarded due to no replay of messages. The channel is said to have no interest if there are no durable or active subscribers.
Durable Subscribers
It is often the case that a subscriber needs to receive all events published to a channel including the events published when the subscriber is inactive. With a durable subscriber, any events published while the subscriber is inactive are stored until the subscriber reconnects and consumes the events missed.
See the section
Durable Subscriptions in the Concepts guide for related information.
No replay of messages
When a JMS subscription is made to a channel, the subscription always begins from the last issued event ID. As no events can be consumed more than once, there is no need to store events once they are consumed. This improves the efficiency of the system because all events can be fanned out to subscribers and then dropped straight away (as long as there are no synchronous consumers or inactive durable subscriptions). This greatly reduces the overhead caused by I/O.
Only in the case of inactive durable subscribers or synchronous consumers are events stored. Once all durable subscribers or synchronous consumers have consumed an event, it is removed from storage as there is no need for it to be kept. Synchronous consumers require the events to be stored because they do not receive events fanned out to all consumers, instead they iterate through the events requesting each event in turn.
Recovery
In the case that a subscriber loses connection to the server, the JMS engine will register a need to temporarily store events for a configurable period of time or until the client reconnects. The time period is defined by the TTL value of the event (if this is non zero) or the EventTimeout value stored in the realm configuration/ClientTimeoutValues under the config tab in the Enterprise Manager which is 60 seconds by default.
Engine Differences
The tables below shows the storage differences between the JMS Engine and the Universal Messaging Queue and Channel Engines. The Universal Messaging engines store events based on the channel type whereas the JMS Engine only stores events when there are synchronous consumers or inactive durable subscribers. The channel type does however determine where the data is stored.
- Events to be stored on disk prior to delivery
- Events to be stored in memory prior to delivery
- Events are not stored prior to delivery
On a Mixed channel, persistent storage to disk or to memory can be individually set on a per-event basis. When appropriate, events on Persistent channels will be stored to disk, and events on Reliable and Simple channels will be stored in memory. Transient channels do not store events prior to delivery.
JMS Engine
Channel Type | Mixed | Persistent | Paged | Reliable | Off-Heap | Simple | Transient |
Active Durable Subscribers | | | | | | | |
Active shared Durable Subscribers (see note 1) | | | | | | | |
Active regular Durable Subscribers, with auto-acknowledgement (see note 2) | | | | | | | |
Active regular Durable Subscribers, with client acknowledgement (see note 3) | | | | | | | |
One or more Synchronous Consumers or Inactive Durable Subscribers | | | | | | | |
No Durable Subscribers | | | | | | | |
No Subscribers | | | | | | | |
Note:
1. For a shared durable consumer, events will always be persisted in an internal queue for that specific subscriber, but not on the channel.
2. For a regular durable consumer, using auto-acknowledgment, events will be passed on to the subscriber and not stored on the channel.
3. For a regular durable consumer, using client acknowledgment, events will be stored on the channel. When the subscriber acknowledgment arrives, the event will be removed from the channel.
For further information on storage methods, see the section
Using Durable Subscriptions with Multiple Clients.
Universal Messaging Channel Engine
Channel Type | Mixed | Persistent | Paged | Reliable | Off-Heap | Simple | Transient |
Active Durable Subscribers | | | | | | | |
One or more Synchronous Consumers or Inactive Durable Subscribers | | | | | | | |
No Durable Subscribers | | | | | | | |
No Subscribers | | | | | | | |
Universal Messaging Queue Engine
Queue Type | Mixed | Persistent | Paged | Reliable | Off-Heap | Simple | Transient |
Active Consumers | | | | | | | |
No Subscribers | | | | | | | |