Expand Collapse
Just a second...

Slave topics (DEPRECATED)

A special type of topic that has no state of its own but is a reference to the state of another topic.

Note: Slave topics are now deprecated and will be removed in a future version. Use Topic views instead of slave topics. Topic views were added in Diffusion™ Cloud 6.3 and can do everything slave topics can do, with more powerful mapping options than are available between master and slave topics.
A slave topic acts as an alias to another topic, the master topic. Updates published to the master are fanned out to subscribers of the slave. The slave cannot be updated directly. The master topic can be any topic type except:
  • slave
  • routing

The link between a slave topic and a master topic is defined when the slave topic is created. This is different to routing topics where the link between topics is defined when a client session subscribes.

If the master topic does not exist when the slave topic is created, the slave topic is created as an unbound slave topic that is not visible to subscribers. When a topic is created at the master topic path, the slave topic becomes bound and can be subscribed to by client sessions.

Properties of a slave topic

When you create a slave topic you must specify the following property in the topic specification:
SLAVE_MASTER_TOPIC (DEPRECATED)
This property is now deprecated and will be removed in a future release.

The path to the topic that acts as the master topic to a slave topic. A topic is not required to exist at this path at the time the slave topic is created.

When you create a slave topic you can specify the following optional properties in the topic specification:
TIDY_ON_UNSUBSCRIBE

If set to true, when a session unsubscribes from the topic, any updates for the topic that are still queued for the session are removed.

There is a performance overhead to using this option as the client queue must be scanned to find topic updates to remove, however it may prove useful for preventing unwanted data being sent to sessions. This property is disabled by default.

Why use a slave topic?

You can use slave topics to provide the same data from multiple topic paths and manage the topics from only one topic.

You can use a slave topic to act as a redirection to a succession of master topics. For example, you can create a slave topic called latest that is linked to a master topic where data is published about a current event. When that event is no longer current, you can remove the slave topic and recreate it now linked to the master topic where data is published about what is now the current event.

The subscribing client sessions can subscribe to the latest slave topic and they continue to be subscribed to the slave topic and receive the latest data, even as the master topic that provides the data changes.

Considerations when using a slave topic

A client only needs permissions on the slave topic. Permission to subscribe to the linked topic is not required.

More than one slave can point to the same master topic.

A slave topic cannot also act as a master topic to another slave topic.

Removing a master topic causes all linked slave topics to become unbound and any clients that are subscribed to the slave topic become unsubscribed. If a new master topic is created at the linked path, the slave topic is bound and the clients are resubscribed.

Slave topics created by the Publisher API cannot link to master topics created by a client.

Slave topics created by a client cannot link to master topics created by the Publisher API.

Slave topics created by the Publisher API behave differently to those created by the client API. When a publisher creates a slave topic, the master topic must already exist. When a master topic is removed any slave topics that were created by the Publisher API are removed.

This page last modified: 2019/11/26