Copyright © TIBCO Software Inc. All Rights Reserved
Copyright © TIBCO Software Inc. All Rights Reserved


Chapter 20 Working With Routes : Routed Topic Messages

Routed Topic Messages
A server forwards topic messages along routes only when the global property is defined for the topic; see addprop topic on page 123 and create topic on page 127.
Topic messages can traverse multiple hops.
When a route becomes disconnected (for example, because of network problems), the forwarding server stores topic messages. When the route reconnects, the server forwards the stored messages.
Servers connected by routes do exchange messages sent to temporary topics.
Propagating Registered Interest
To ensure forwarding of messages along routes, servers propagate their topic subscriptions to other servers. For example, the top of Figure 37 depicts an enterprise with three servers—A, M and B—connected by routes in a multi-hop zone. The bottom of Figure 37 illustrates the mechanism at work within the servers to route messages from a producer client of server A, through server M, to server B and its subscriber client. Consider this sequence of events.
Figure 37 Routing: Propagating Subscribers
1.
2.
At bottom right of Figure 37, a client of server B creates a subscriber to T1.
3.
4.
Because a route connects servers M and B, server B propagates its interest in T1 to server M. In response, M creates an internal subscriber to T1 on behalf of server B. This subscriber ensures that M forwards (that is, delivers) messages from topic T1 to B. Server B behaves as a client of server M.
5.
Similarly, because a route connects servers A and M, server M propagates its interest in T1 to server A. In response, A creates an internal subscriber to T1 on behalf of server M. This subscriber ensures that A forwards messages from topic T1 to M. Server M behaves as a client of server A.
6.
When a producer client of server A sends a message to topic T1, A forwards it to M. M accepts the message on its topic T1, and forwards it to B. B accepts the message on its topic T1, and passes it to the client.
Subscriber Client Exit
If the client of server B creates a non-durable subscriber to T1, then if the client process exits, the servers delete the entire sequence of internal subscribers. When the client restarts, it generates a new sequence of subscribers; meanwhile, the client might have missed messages.
If the client of server B creates a durable subscriber to T1, then if the client process exits, the entire sequence of internal subscribers remains intact; messages continue to flow through the servers in store-and-forward fashion. When the client restarts, it can consume all the messages that B has stored in the interim.
Server Failure
In an active-active route between servers B and M, if B fails, then M retains its internal subscriber and continues to store messages for clients of B. When B reconnects, M forwards the stored messages.
In an active-passive route configured on B, if B fails, then M removes its internal subscriber and does not store messages for clients of B—potentially resulting in a gap in the message stream. When B reconnects, M creates a new internal subscriber and resumes forwarding messages.
In an active-passive route configured on A, if either server fails, then M retains its internal subscriber in the same way as an active-active route. However, B does not retain its internal state which it uses to suppress duplicate messages from A and can deliver messages to its consumers after they have consumed them. Therefore, if it is desirable to not lose messages and to not have duplicate messages, the route should be active-active.
Network Failure
If an active-passive connection between B and M is disrupted, M displays the same behavior as during a server failure.
maxbytes
Combining durable subscribers with routes creates a potential demand for storage—especially in failure situations. For example, if server B fails, then server M stores messages until B resumes. We recommend that you set the maxbytes or maxmsgs property of the topic (T1) on each server, to prevent unlimited storage growth (which could further disrupt operation).
Selectors for Routing Topic Messages
Motivation
A server forwards a global topic message along routes to all servers with subscribers for that topic. When each of those other servers requires only a small subset of the messages, this policy could potentially result in a high volume of unwanted network traffic. You can specify message selectors on routes, to narrow the subset of topic messages that traverse each route.
Message selectors on routes are different from message selectors on individual subscribers, which narrow the subset of messages that the server delivers to the subscriber client.
Example
Figure 38 illustrates an enterprise with a central server for processing customer orders, and separate regional servers for billing those orders. For optimal use of network capacity, we configure topic selectors so that each regional server gets only those orders related to customers within its region.
Figure 38 Routing: Topic Selectors, example
Specifying Selectors
Specify message selectors for global topics as properties of routes. You can define these properties in two ways:
Define selectors when creating the route (either in routes.conf, or with the administrator command create route).
Manipulate selectors on an existing route (using the addprop, setprop, or removeprop administrator commands).
If you change the message selectors on a route, only incoming messages are evaluated against the new selectors. Messages pending in the server are re-evaluated only if the server is restarted.
Syntax
The message selector properties have the same syntax whether they appear in a command or in a configuration file:
 incoming_topic=topicName selector="msg-selector"
 outgoing_topic=topicName selector="msg-selector"
 
The terms incoming and outgoing refer to the perspective of the active server—where the route is defined.
topicName is the name of a global topic.
msg-selector is a message selector string. For detailed information about message selector syntax, see the documentation for class Message in TIBCO Enterprise Message Service Java API Reference.
Example Syntax
In the example of Figure 38, an administrator might configure these routes on the central order server:
setprop route Canada outgoing_topic="orders" selector="country=’Canada’"
setprop route Mexico outgoing_topic="orders" selector "country=’Mexico’"
setprop route USA    outgoing_topic="orders" selector="country=’USA’"
Those commands would create these entries in routes.conf:
[Canada]
url=ssl://canada:7222
outgoing_topic=orders selector="country=’Canada’"
...
[Mexico]
url=ssl://mexico:7222
outgoing_topic=orders selector="country=’Mexico’"
...
[USA]
url=ssl://usa:7222
outgoing_topic=orders selector="country=’USA’"
...
Symmetry
outgoing_topic and incoming_topic are symmetric. Whether A specifies a route to B with incoming_topic selectors, or B specifies a route to A with outgoing_topic selectors, the effect is the same. That is, B sends only those messages that match the selector over the route.
Active-Active Configuration
In an active-active configuration, you may specify selectors on either or both servers. If you specify outgoing_topic selector S1 for topic T on server A, and incoming_topic selector S2 for T on server B, then the effective selector for T on the route from A to B is (S1 AND S2).
See also Active and Passive Routes.
Wildcards
You can specify wildcards in topic names. For each actual topic, the server uses logical AND to combine all the selectors that match the topic.
 
However, routing of topic messages is only reliably supported when the subscriber's topic is a subset (or equal) of the configured global topic. Similarly, intersections are not supported. For example, if topics.conf contains foo.* and foo.a*, the following subscriptions are correct:

Copyright © TIBCO Software Inc. All Rights Reserved
Copyright © TIBCO Software Inc. All Rights Reserved