You can use wildcards when specifying statically created destinations in queues.conf and
topics.conf. The use of wildcards in destination names can be used to define
"parent" and
"child" destination relationships, where the child destinations inherit the properties and permissions from its parents. You must first understand wildcards to understand the inheritance rules described in
Inheritance.
The topic topic.multicast.quotes.tibx would be assigned both channels,
multicast_1 and
multicast_2. Therefore, the wildcard topics
topic.multicast.> and
topic.multicast.quotes.* cannot coexist. Their creation would fail.
You can subscribe to a wildcard topic (for example foo.*), whether or not there is a matching topic in the configuration file (for example,
foo.*,
foo.>, or
foo.bar). However, if there is no matching topic name in the configuration file, no messages will be published on that topic.
A message consumer subscribed to topic > will receive messages published to
topic.info and
topic.quotes over TCP, will receive messages published to
topic.multicast.info over the multicast channel
channel-1 and messages published to
topic.multicast.quotes over the multicast channel
channel-2. Note that this means a wildcard consumer may receive messages over both multicast and TCP.
As described in Dynamically Creating Topics and Queues, the EMS server may dynamically create destinations on behalf of its clients. The use of wildcards in the
.conf files can be used to control the allowable names of dynamically created destinations.