How are durable subscriptions handled in a router network?

Nicholas Whitehead

All Topic Manager Swiftlets in a router network are working federated. They exchange subscription messages on a "some/none" base. That means, they send a subscription message to all other Topic Manager Swiftlets if they have at least 1 subscription for a particular topic (SQL-Like predicate) and they send an unsubscription message around if the count wents to zero. For a local Topic Manager Swiftlet are these remote subscriptions just normal subscriptions. The only difference is that the subscriber queue is a remote queue "sys$topic" at the particular remote router. This queue is the inbound queue of the remote Topic Manager Swiftlet. If it receives a message on this queue, it is like a local publish. That means, the topic broker queue is determined and the message is send to all local subscribers.

Due to the nature of this dynamic subscription exchange, a local Topic Manager Swiftlet registers such subscriptions only after the remote router is reachable through routing and the Topic Manager Swiftlets have done some handshaking. Remote subscription are still active when the remote router becomes unreachable (connection down). Messages stay in the routing queues then and will be forwarded when the router becomes reachable again.

The Topic Manager Swiftlet does not store remote subscriptions persistently. When a router is started, it has initially no knowledge about any remote subscriptions.