Universal Messaging 9.7 | Universal Messaging Developer Guide | Enterprise APIs | Enterprise Developer's Guide for Java | Provider for JMS | Fanout Engine
 
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 has five different channel types each of which have different requirements when storing data:
*The Persistent channel always writes data to disk regardless of the number of subscribers.
*The Simple and Reliable channels both store all events in memory. The difference being that 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.
*The Mixed channel stores the Event ID in the same way as the Reliable channel but the storage of events is specified in the nConsumeEvent by calling setPersistent(). (in JMS the persistence is set by the DeliveryMode).
*With a Transient channel all events are fanned out to subscribers and then dropped so no events are stored in memory or on disk.
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.
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 temporarilly 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 table 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.
disk/ - Events to be stored on disk prior to delivery
memory/ - 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
Reliable
Simple
Transient
Active Durable Subscribers
-
-
-
-
-
One or more Synchronous Consumers or Inactive Durable Subscribers
disk/ memory
disk
memory
memory
-
No Durable Subscribers
-
-
-
-
-
No Subscribers
-
-
-
-
-
Universal Messaging Channel Engine
Channel Type
Mixed
Persistent
Reliable
Simple
Transient
Active Durable Subscribers
disk/ memory
disk
memory
memory
-
One or more Synchronous Consumers or Inactive Durable Subscribers
disk/ memory
disk
memory
memory
-
No Durable Subscribers
disk/ memory
disk
memory
memory
-
No Subscribers
disk/ memory
disk
memory
memory
-
Universal Messaging Queue Engine
Channel Type
Mixed
Persistent
Reliable
Simple
Transient
Active Consumers
disk/ memory
disk
memory
memory
-
No Subscribers
disk/ memory
disk
memory
memory
-

Copyright © 2013-2015 | Software AG, Darmstadt, Germany and/or Software AG USA, Inc., Reston, VA, USA, and/or its subsidiaries and/or its affiliates and/or their licensors.