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.
In a federated router network, subscriptions are exchanged dynamically between routers. If a router starts up, it has initially no knowledge about remote subscriptions. Once another router connects to this router, subscriptions are exchanged and messages are forwarded between the routers on base of these subscriptions. To enable message forwarding for times when a router has not yet remote subscriptions (it has just being started and no other router has connected yet), static remote subscriptions can be defined.
Note that, per default, static remote subscriptions are only valid before the remote router connects the first time. Thereafter the subscriptions are turning dynamically. So in the case the remote router unsubscribes from a topic, no further messages are forwarded, even if there is a static remote subscription for it. Starting with release 6.1.0 this behavior can be changed by enabling attribute "keep-on-unsubscribe" of the static remote subscription. In that case, dynamic unsubscription requests for that topic of that router are not respected and messages are still forwarded. This is very important in the case the remote router performs an orderly shutdown (e.g. for maintenance) and has durable subscribers, because a router unsubscribes from all topics at remote routers during shutdown. If "keep-on-unsubscribe" is "true", messages are still forwarded into the routing queue and will be delivered once the remote router restarts. So no messages are lost in the meantime. If "keep-on-unsubscribe" is set to "false" (default), no messages are delivered while the remote router is down and messages are lost.
Static remote subscriptions are defined on a per-router-base. It requires that a static route is defined to the particular remote router.
Example:
<swiftlet name="sys$routing">
<connectors/>
<filters/>
<listeners>
<listener name="plainsocket" port="4100">
<host-access-list/>
</listener>
</listeners>
<static-routes>
<static-route name="router2"/>
<static-route name="router3"/>
<static-route name="router4"/>
</static-routes>
</swiftlet>
Thereafter, static remote subscriptions can be defined under the Topic Manager Swiftlet configuration:
Example:
<swiftlet name="sys$topicmanager" flowcontrol-enabled="false">
<static-remote-router-subscriptions>
<static-remote-router-subscription name="router2">
<static-topic-subscriptions>
<static-topic-subscription name="testtopic"/>
</static-topic-subscriptions>
</static-remote-router-subscription>
<static-remote-router-subscription name="router3">
<static-topic-subscriptions>
<static-topic-subscription name="testtopic"/>
</static-topic-subscriptions>
</static-remote-router-subscription>
<static-remote-router-subscription name="router4">
<static-topic-subscriptions>
<static-topic-subscription name="iit" keep-on-unsubscribe="true"/>
<static-topic-subscription name="testtopic"/>
</static-topic-subscriptions>
</static-remote-router-subscription>
</static-remote-router-subscriptions>
<topics>
<topic name="testtopic"/>
<topic name="iit"/>
<topic name="iit.sales"/>
<topic name="iit.sales.eu"/>
<topic name="iit.sales.us"/>
<topic name="iit.sales.asia"/>
</topics>
</swiftlet>
Note that the 'name' attribute of an element 'static-remote-router-subscription' must contain the remote router name and the 'name' attribute of an element 'static-topic-subscription' must contain the root topic (the first node of a topic hierarchy; if you don't have a topic hierarchy then it's just the topic name).
The above configuration ensures that messages are forwarded to the topic hierarchy beginning with 'testtopic' to routers 'router2', 'router3', and 'router4'. Messages to the topic hierarchy beginning with 'iit' are also forwarded to 'router4'. Forwarding of messages for this topic continues even if the remote router has no subscriptions for it.