SwiftMQ provides publish/subscribe flow control. As for point-to-point queues, the flow control is based on flow control delays. During the publish/commit operation, all flow control delays of the selected subscriber queues are determined and the maximum delay is delivered back. So, the flow control delay is that of the slowest subscriber.
In some use case scenarios it is very important to maintain a constant publishing rate. For example, a trading feed in a financial application requires that feed data (stock prices) are published without delays. If there are slow subscribers on that feed topic, either a backlog of messages will increase for that subscribers or, when using pub/sub flow control, the publisher will be throttled down from SwiftMQ to the rate of the slowest subscriber.
To avoid this situations, slow subscriber conditions can be created. Such a condition identifies a slow subscriber during the publish transaction and, if the condition matches, avoids to send further messages to those matching subscribers until the condition doesn't match with future publish transactions. Thus, a constant publishing rate is created.
SwiftMQ 5.2.0 onwards also allows to remove non-durable subscriber connections and to remove durable subscriber connections including deleting the durable subscriptions. See sections below.
A slow subscriber condition is defined per 'root topic', which is the first node of a topic hierarchy. Say, all your feeds are summarized under the hierarchy 'feed', e.g. 'feed.bloomberg', 'feed.reuters', a condition can be defined on root topic 'feed'. The condition is valid for all sub-topics in the hierarchy. Further condition attributes are the persistence-mode (all, persistent, non_persistent), the subscription-type (all, local, remote) and the maximum messages in the subscriber queue during the time of the publish operation.
Example:
<swiftlet name="sys$topicmanager">
<slow-subscriber-conditions>
<topic name="feed" max-messages="100" persistence-mode="non_persistent" subscription-type="local"/>
<topic name="events" max-messages="300" persistence-mode="all" subscription-type="remote"/>
</slow-subscriber-conditions>
<topics>
<topic name="feed"/>
<topic name="feed.bloomberg"/>
<topic name="feed.reuters"/>
<topic name="events"/>
</topics>
</swiftlet>
The example defines 2 conditions. The first is for the topic hierarchy 'feed' and matches for nonpersistent messages and local subscribers if the subscriber queue has reached 100 messages. The second condition is for topic hierarchy 'events', matches for all messages but only for remote subscriptions and permits max. 300 messages in the subscriber queue.
Note that for remote subscriptions the subscriber queue is the routing queue of the resp. router and thus the message count of that queue is taken.
SwiftMQ 5.2.0 onwards adds an attribute "disconnect-non-durable-subscriber" to a slow subscriber condition. The default value is false. If it is set to true, all non-durable subscriber connections for which the condition matches will be removed. This option is useful if there are malfunctioning JMS clients which have topic subscriptions.
SwiftMQ 5.2.0 onwards adds another attribute "disconnect-delete-durable-subscriber" to a slow subscriber condition. The default value is false. If it is set to true, all durable subscriber connections for which the condition matches will be removed and their durable subscriptions will be deleted. That is, all messages in their durable subscriber queue will be lost! So be careful with this option. This option is useful if there are malfunctioning JMS clients which have durable topic subscriptions or if there are "dead" durable subscription on a topic (a JMS client created a durable subscription but doesn't use it anymore so the durable subscriber queue grows and grows).