A special type of topic that has no state of its own but is a reference to the state
of another topic.
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
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:
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
- 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
When you create a slave topic you can specify the following optional properties in
the topic specification:
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
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
When using topic replication to replicate slave topics between
Diffusion servers, be aware that a replicated slave
topic is linked to a master topic located on the same Diffusion server as the replicated slave topic. This
is true whether that master topic is created by replication or directly.
Slave topics created by the Publisher API cannot link to master topics created by a
Slave topics created by a client cannot link to master topics created by the
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.