Types of Durable Subscription

With the Exclusive durable type, only one client session is subscribed and connected to the durable subscription at a time. Other clients cannot subscribe while the current client session is subscribed.

Each read operation issued by a client returns a single event from the durable to the client. The client processes the event according to the client's application logic, then returns an acknowledgement to the durable that the event has been processed. Each subsequent read operation by the client returns the next event from the durable in chronological order.

If the client connection is terminated, a subsequent client connection on the durable will restart at the next unacknowledged event on the durable.

The following diagram shows the behavior of the Exclusive durable. Client session C1 is subscribed and connected to the durable. No other client sessions can subscribe to the same durable while the current client session is active and subscribed.

Note:
This durable type is deprecated in Universal Messaging version 10.3 and will be removed in a later version. For future applications we suggest you use the durable type Serial instead of Priority.

With this durable type, multiple client sessions can be subscribed and connected, but only one client session has priority. The priority client is the only client that can receive events from the durable.

The read/process/acknowledge cycle for this durable type is the same as for the Exclusive durable type.

If the priority client session goes offline, the next subscribed client will become the priority client, and processing will restart at the next unacknowledged event on the durable.

The following diagram shows the behavior of the Priority durable. Clients sessions C1 and C2 are subscribed. C1 currently has priority and will process all of the events. If C1 goes offline, C2 will take over.

The following diagram illustrates the behavior of the Shared and Serial durable types, which can have multiple active client sessions. The client sessions are served in a round-robin manner. Each client receives a window of events. The Shared type differs from the Serial type in how the clients process their assigned event windows.

With the Shared durable type, multiple clients can subscribe and receive events from the durable in round-robin fashion. You can configure the durable so that each client receives a window that consists of multiple events instead of a single event. As soon as one client has received its allotted event or window of events, the next client receives its events, and so on. All subscribed clients on the durable can process the events concurrently.

The chronological order in which events are processed is not guaranteed. For example: the C1 client receives a window of events, then the C2 client receives a window of events, but C2 can complete its processing and can acknowledge its events before C1 completes its processing.

With the Serial durable type, the events from the event windows are delivered to consumers in chronological order.

Multiple client sessions can subscribe and receive events from the durable, but the delivery method ensured that only one client will receive events at a time. The Serial type differs from the Shared type in that a client will only receive an event or a window of events when the previous client has acknowledged or rolled back its events. While any of the subscribed clients is processing its events, the other clients are inactive.

The window size of the Event delivery type and the number of client sessions will determine how Universal Messaging deals with the serial delivery of events.

With a single client, Software AG recommends setting the window size to one to guarantee the serial delivery and processing of events. The server will not send more events to the client until the event that is already sent has been acknowledged or rolled back. Note that when "Window Size=1", the event delivery and processing is not done in parallel and the delivery throughput is lower.

The window size is set to 1. The client acknowledges events 1 to 4, but rolls back event 5. The server will wait for each event (1,2,3, and 4) to be processed before the server re-sends event 5. This ensures that events 1 to 5 are processed in the exact order, in which they were sent and received.

When the size of the event window is larger than 1, the server performance improves, because the delivery and processing of the batches of events is done in parallel. However, the serial delivery of events is not guaranteed in the following cases:

When an event is rolled back, the client receives the next event from the window (which was sent during the rollback), instead of the event that was rolled back. In this case the order in which the events get delivered to the client does not match the sending order.

The window size is set to 6. The client acknowledges events 1 to 4, but rolls back event 5. If the server has already sent event 6, that event will be delivered next instead of the rolled-back event. Event 5 will get re-delivered after event 6.

The client receives a batch of events, but does not process the events in the order, in which they were received.

The window size is set to 6. The client receives events 1, 2, 3, and 4, but acknowledges the events in a different order, for example 4, 1, 3, 2.

The events are delivered to a client after they have been processed by the previous client. Only one client can have unprocessed events at a time. If none of the clients have outstanding events, the delivery can be scheduled for any of the available clients. The events are delivered among clients in a round-robin fashion.

When the server attempts a round-robin delivery with an event window larger than 1, the round-robin delivery is not guaranteed. For example, if a client processes the events in parallel with the event delivery from the server, the client might receive more than one consequent batches of events.

We have two clients, C1 and C2, and the window size is set to 6. The durable subscription has 6 events.

C1 receives all six events and acknowledges event 1. When a new event is published to the server, the server delivers the event to C1, because C1 has an empty seat for 1 event in its window and 5 unprocessed events. To ensure the serial processing of the events, the server will send events to C2 only after C1 processes all of its in-flight events.

Note:
This durable type is deprecated in Universal Messaging version 10.3 and will be removed in a later version. For future applications we suggest you use the durable type Shared instead of Shared-Queued.

This durable type provides the same functionality as the Shared durable type, but is based on an implementation that uses an internal queue to maintain copies of events that are assigned to the durable. Under certain circumstances, for example if you are running Universal Messaging in a clustered environment where synchronization of queues across all nodes in the cluster is required, the handling of such queues may affect performance.

Shared-Queued is the original implementation of the functionality available in Shared. You may wish to consider using Shared instead of Shared-Queued for any new applications you develop, as Shared uses an indexing mechanism directly on the events in the channel rather than a queue-based mechanism.

The following diagram illustrates the behavior of the Shared-Queued durable. The principle is the same as for Shared, but the internal implementation involves a queue mechanism. Multiple active client sessions are allowed and are served in a round-robin manner. Each client receives a window of events, but clients do not process their windows concurrently.

Processing messages from a single Universal Messaging session through multiple threads can cause redelivery if one of the threads is rolling back a message. For example, if you use an Integration Server JMS trigger on a Shared-Queued durable with multiple concurrent consumers, and the execution time of the event processing service is longer than the timeout of the concurrent consumers, this will cause the event processing to loop between the Pending and Rollback states.

In such cases, consider using a Shared durable rather than a Shared-Queued durable or set the trigger's sleep time to a value lower than the timeout of the concurrent consumers. You can specify the trigger's sleep time by using the watt.server.jms.trigger.pooledConsumer.timeout Integration Server configuration property.