All Topic Manager Swiftlets in a router network are working federated. They exchange subscription messages on a "some/none" base. That is, they send a subscription message to all other Topic Manager Swiftlets if they have at least 1 subscription for a particular topic and they send an unsubscription message around if the count reaches zero. The subscription exchange is made on base of root topics. A root topic is the first node in a topic hierarchie, e.g. the root topic of topic 'iit.sales.eu' is 'iit'. For a local Topic Manager Swiftlet these remote subscriptions are just normal subscriptions. The only difference is that the subscriber queue is a remote queue "tpc$<roottopic>" at the particular remote router.
Remote subscriptions are listed in the Topic Manager's "Usage" section below node "Remote Router Subscriptions":
Each router node consists of 1 or more root topics for which the particular router has at least 1 subscription.
Usually this dynamic remote subscriptions are only informational. However, there is one case where an administrator has to delete this remote subscriptions: to put a node of a federated router network out of service.
If a node should be removed from a federated router network, this can be done by shutting down its JMS clients which in turn remove all their subscriptions which forces the router node to send an unsubscription notification to all other routers when the last local JMS client unsubscribes from this particular topic. The last action is to shut down the router.
But if the router node did not had an active routing connection to one or more of its neighbours, they will never receive the unsubscription notification and will continously send pub/sub messages for the router's topic subscriptions. In this case an administrator has to delete the resp. remote router subscription entry:
This must be done on all router nodes of the federated router network.