Pub/sub topics

Topic attributes

Each Zato publish/subscribe topic is represented by a set of attributes, described below.

• Name of a topic must be unique within the boundaries of a given Zato cluster. The slash character has a special meaning when permissions to access a topic are resolved.

• If a topic is not active, it will not be possible to publish messages to it.

• The GD enabled flag dictates whether messages published to a topic use Guaranteed Delivery (GD) by default or not. Note that each message can specify this flag independently of whether it is set for the topic. That is, GD is a property of an individual message, not that of a topic.

• API sub. allowed lets you decide whether external subscribers, such as REST or WebSocket-based ones, are allowed to create their own subscriptions. If not, only subscriptions created manually in Dashboard will be available for the topic, which can be desirable in relatively fixed environments.

• If On no sub. is set to Drop, a message published to a topic will be dropped (ignored) if there are no subscribers for the topic at the time of the publication. If it is set to Accept, the message will be stored in the topic - up to a limit (depth) - where it will wait for a subscriber.

• Each topic has a maximum depth which is its maximum capacity. If that limit is reached, any new message will not be saved in the topic - rather, they will be saved in a log file to ensure that they are not lost but they will not be re-read from the file once there is again room in the topic. The maximum depth can be set independently for GD and in-RAM messages.

  Note that there are two ways to reach the limit. One is not having any subscriber at all while having at least one publisher sending messages - ultimately, the depth will be reached. Another is to have publishers sending messages faster than the consumers can process them, in such a case, once more, at one point messages will start to accumulate in the topic until the topic's maximum depth is reached.

  Note also that when the depth is reached, the delivery processes will not stop - they will continue to move the message to subscribers' queues and, from there, to their final recipients. Thus, unless publishers continually outpace the subscribers, the current number of messages in a topic will decrease even if the limit is reached.

  Observe, too, that the maximum depth is a property of a topic only, not that of any queue. That is, it is the maximum depth of messages that have not been moved to queues yet. The queues themselves have no such maximum capacity attribute.

• How often to check whether the maximum depth is reached, once in how many publications, is what the check frequency setting is for. This should never be set to less than 100. Note that, because the setting is at least 100, it means the actual maximum depth for a topic may be slightly exceeded by that many messages.

• Delivery intervals let you control how often internal processes should run, at least once in how many milliseconds. The Sync interval defines how often messages should be moved to each of the delivery queues from a topic, that is, after how many milliseconds they will appear in a queue from the moment they were published or, in other words, how often to synchronize the contents of the queue with the topic. The Delivery interval indicates how often to deliver messages from a given queue to a subscriber. It is almost never needed to change the intervals.

• Time limits can be imposed on messages and subscriptions - all of the limits are in seconds.

  • The Retention limit controls what happens to messages that are published to a topic if "On no sub." is set to Accept but there is still no subscriber to consume them. Each such unconsumed message will be deleted from the topic after at most retention-limit-many seconds. This value cannot be overridden on a per-message basis.

  • The Expiry limit is akin to retention but it can be provided by publishers too. Note that Retention always has precedence over Expiry. For instance, if a publisher sets Expiry to one week but Retention is set to two days (both expressed in seconds), it is Retention that wins.

  • If a WebSocket-based subscriber is not active at least once within Sub. inactivity seconds, its subscription, along with any messages already enqueued for it, will be deleted. Being active means interacting with the broker either through WebSocket ping messages or though the process of receiving messages enqueued for that subscriber. Note that this limit is used only by WebSocket subscribers, it is not applicable to REST, Python or other types of subscribers.

Dashboard

You can publish messages to any topic. Note that the publisher sending the message still needs to have permissions to make publications to topic that you select.

Message that are still in a topic - meaning that no subscriber has moved it to its queue yet - can be updated in place.

Current runtime details of a topic can be checked from the Dashboard, e.g. about subscriptions or messages for a topic, what the last published messages were and similar.

Getting started

Using publish/subscribe