Subject Filtering with Wildcards

The wildcard characters, * and >, have the same semantics in import, export and exchange parameters as they do in listening calls:

•

* matches any single element.

•

> in the last (rightmost) position matches one or more trailing elements.

Recall that these rules of import parameter behavior apply also to routing daemons.

Importing Wildcard Subjects

Importing this wildcard name	Matches messages with names like these	But not names like these (reason)
FOO.*	FOO.BAR	FOO.BAR.BAZ (extra element)
FOO.>	FOO.BAR FOO.BAR.BAZ FOO.BAR.BAZ.BOX	FOO (missing element)
FOO.*.>	FOO.BAR.BAZ FOO.BAR.BAZ.BOX	FOO.BAR (missing element) FOO (missing elements)
FOO.*.STOP	FOO.BAR.STOP FOO.FOZ.STOP	FOO.STOP (missing element) FOO.BAR.BAZ (unmatched 3rd element)

Routing Daemons Filter Interest to Permitted Subjects

Routing daemons filter local listening interest according to the subjects that the local networks can import and export. The general rule is that routing daemons disregard listening interest that would include subjects in either of these categories:

•

Subjects that the listener’s local network cannot import.

•

Subjects that the sender’s local network cannot export.

Note	Customers frequently deploy application programs that listen to wildcard subjects that are more inclusive than the wildcard subjects that rvrd imports or exports. As a result, the routing daemon filters this application subject interest, and the listeners do not receive any messages.

For example, consider a situation in which the local network imports FOO.> (that is, it does not permit any other subjects to enter from the WAN). When a process, L1, within the local network listens to the subject > (that is, the wildcard that matches any subject), the routing daemon first compares it to the permitted import subjects; since > is not a subset of FOO.>, the routing daemon does not forward any messages into the local network, so L1 does not receive any messages.

When a second process, L2, in the same local network, listens to the subject FOO.BAR, the routing daemon begins importing messages (because the subject matches a subject for which import is permitted); both L1 and L2 receive the imported messages.

When a third process, L3, listens to the subject FOO.>, the routing daemon widens the set of messages it imports; both L1 and L3 receive the additional message subjects.

Correctly Importing Wildcard Subjects summarizes this example, and presents further examples.

 

Correctly Importing Wildcard Subjects

Importing this wildcard name	While listening to this subject	Imports these subjects	Reason
FOO.>	>	none	> is more inclusive than FOO.> rvrd filters out > because it isn’t imported.
FOO.>	FOO.BAR	FOO.BAR	FOO.BAR is included within FOO.> rvrd filters out everything else because (for example, FOO.BAZ) no listener is requesting it.
FOO.>	FOO.>	FOO.>	FOO.> is identical to FOO.>
A.B.C	A.*.C	none	A.*.C is more inclusive than A.B.C rvrd filters out A.*.C because it isn’t imported.
A.*.C	A.*.C	A.*.C	A.*.C is identical to A.*.C
A.B.>	A.B.*	A.B.*	A.B.* is included within A.B.> rvrd filters out everything else (for example, A.B.C.D) because no listener is requesting it.

See Also

Using Wildcards to Receive Related Subjects in TIBCO Rendezvous Concepts