You can configure queue definitions (in the configuration file queues.conf) with the
import property that specify one or more external transports.
(For general information about queues.conf syntax and semantics, see
queues.conf on page 241. You can also configure queues using the administration tool command
addprop queue.)
For example, the following tibemsadmin command configures the queue
myQueue.in to
import messages on the transports
RV01 and
RV02.
Rendezvous messages with subject myQueue
.in arrive at
tibemsd over the transports RV01 and RV02. EMS clients can receive those messages by subscribing to myQueue
.in.
When a queue specifies import on a connected transport,
tibemsd immediately begins importing messages to the queue, even when no receivers exist for the queue.
For static queues (configured by an administrator) tibemsd continues importing until you explicitly delete the queue.
Wildcards in the import property obey EMS syntax and semantics (not Rendezvous syntax and semantics); see
Destination Name—Syntax and Semantics.
EMS clients cannot subscribe to wildcard queues—however, you can define wildcards queues in the EMS server for the purpose of property inheritance. That is, you can configure a static queue named
foo.* and set properties on it, so that child queues named
foo.bar and
foo.baz will both inherit those properties.
If you define a queue that imports foo.*,
tibemsd begins importing all matching messages from Rendezvous. As messages arrive,
tibemsd creates dynamic child queues (for example,
foo.bar and
foo.baz) and delivers the messages to them. Notices that
tibemsd delivers messages to these dynamic child queues even when no consumers exist to drain them.