Typically, one of the basic tasks of managing a broker network is to partition the network so that certain queues and topics are restricted to a sub-domain, while messages on other queues and topics are allowed to cross domains. This kind of domain management can be achieved by applying filters at certain points in the network. Fuse Message Broker lets you define filters on network connectors and message selectors on consumers in order to control the flow of messages throughout the network.
The following characters can be used to define wildcard matches for topic names and queue names:
. | Separates segments in a path name. |
* | Matches any single segment in a path name. |
> | Matches any number of segments in a path name. |
Wildcards are meant to be used with destination names that have a segmented
structure, like a path name—for example, PRICE.STOCK.NASDAQ.IBM
or PRICE.STOCK.NYSE.SUNW
—where the segments are delimited by the
.
character. The following table shows some examples of destination
wildcards and describes what names they would match.
Destination wildcard | What it matches |
---|---|
PRICE.> | Any price for any product on any exchange. |
PRICE.STOCK.> | Any price for a stock on any exchange. |
PRICE.STOCK.NASDAQ.* | Any stock price on NASDAQ. |
PRICE.STOCK.*.IBM | Any IBM stock price on any exchange. |
It is possible to filter the messages that pass through a network connector by
specifying destinations to include and destinations to exclude. The following child
elements of networkConnector
are used to filter dynamic
destinations:
dynamicallyIncludedDestinations
Explicitly specifies a list of included destinations, where the included destinations are specified using
queue
child elements andtopic
child elements (wildcards are allowed). Destinations matching this list and only these destinations are propagated dynamically by the network connector (provided they are not blocked by the list specified inexcludedDestinations
). An empty list allows all destinations to be propagated dynamically.excludedDestinations
Specifies a list of excluded destinations, where the excluded destinations are specified using
queue
child elements andtopic
child elements (wildcards are allowed). Destinations matching this list are always blocked by the network connector.
Example 2.4 shows a network connector that is configured to filter dynamic destinations. In this example, the connector transmits stock prices from any exchange except the NYSE and transmits orders to trade stocks for any exchange except the NYSE.
Example 2.4. Connector with Filtered Destinations
<networkConnectors> <networkConnector name="linkToBrokerB" uri="static:(tcp://localhost:61002)" networkTTL="3"> <dynamicallyIncludedDestinations> <queue physicalName="TRADE.STOCK.>"/> <topic physicalName="PRICE.STOCK.>"/> </dynamicallyIncludedDestinations> <excludedDestinations> <queue physicalName="TRADE.STOCK.NYSE.*"/> <topic physicalName="PRICE.STOCK.NYSE.*"/> </excludedDestinations> </networkConnector> </networkConnectors>
There is no need to filter statically propagated destinations, because
destinations are only transmitted statically when they are listed explicitly in a
staticallyIncludedDestinations
element.
Fuse Message Broker supports standard JMS selectors, which enable consumers to filter messages from a particular destination by testing the contents of a message's JMS headers. When a consumer subscribes to a particular destination, the standard JMS API can be used to specify a selector (see javax.jms.Message for more details).
If your consumers use JMS selectors, you should be aware that some interaction can occur between JMS selectors and conduit subscriptions. In general, JMS selectors are always applied by the consumer's local broker (that is, the broker to which the consumer is directly connected). But if the conduit subscriptions option is enabled (which it is by default), JMS selector information is omitted from any conduit subscriptions transmitted to a remote broker. This implies that the remote broker (or brokers ) do not perform any filtering based on JMS selectors. There are certain scenarios where this behavior can cause problems.
For example, consider the broker network shown in Figure 2.17, where conduit subscription is
enabled throughout the network. Both of the consumers, C1 and C2, subscribe to the
same queue and they also define JMS selectors as follows: C1 selects messages for
which the region
header is equal to us
; and C1 selects
messages for which the region
header is equal to
emea
.
Now consider what happens when a producer, P, connects to broker A and starts
sending messages to the queue. The consumer subscriptions, s1
and
s2
, automatically propagate to broker A. But because these
subscriptions are both on the same queue and the conduit subscriptions option is
enabled, broker A combines the subscriptions into a single conduit subscription,
cs
, which does not include any selector
details. When P starts sending messages to the queue, broker A forwards the messages
alternately to broker B and broker C, without checking whether
the messages satisfy the relevant selectors. If you are particularly unlucky, you
might find that all of the messages for region emea
end up on broker B
and all of the messages for region us
end up on broker C. In this case,
none of the messages could be consumed.