Once clients are connected to the broker, the routing and delivery of messages can proceed. In this phase, the broker is responsible for creating and managing different types of physical destinations, for ensuring a smooth flow of messages, and for using resources efficiently. The broker properties related to routing and destinations are used by the broker to manage these tasks in a way that suits your application’s needs.
Remember that a physical destination on the broker is a memory location where messages are stored before being delivered to a message consumer. There are four kinds of physical destinations:
Admin-created destinations are created by the administrator using the GUI (imqadmin) or the imqcmd utility. These correspond either to a logical destination created programmatically or to a destination administered object that is created by the administrator and looked up by the client. You use the imqcmd utility to set or update properties for each admin-created destination.
Auto-created destinations are automatically created by the broker whenever a message consumer or producer attempts to access a nonexistent destination. These are typically used during development. You can set a broker property to disallow the creation of such destinations. You set broker properties to configure all auto-create destinations on a particular broker.
An auto-created destination is automatically destroyed by the broker when it is no longer being used: that is, when it has no consumer clients and no longer contains any messages. If a broker restarts, it only recreates this kind of destination if it contains persistent messages.
Temporary destinations are explicitly created and destroyed programmatically by clients who need a destination where to receive replies to messages. As their name implies, these destinations are temporary and maintained by the broker only for the duration of the connection for which they are created.
Temporary destinations are not stored persistently and are never recreated when a broker is restarted, but they are visible to administration tools.
The dead message queue is a specialized destination, created automatically at broker startup and used to store dead messages for diagnostic purposes. You can set properties for the dead message queue using the imqcmd utility.
You use the imqcmd utility to manage destinations. Managing a destination involves one or more of the following tasks:
Creating, pausing, resuming, or destroying a destination
Listing all destinations on a broker
Displaying information about the state and properties of a destination
Displaying metrics information for a destination
Compacting disk space used to persist messages for a destination
Updating a physical destination’s properties
Management tasks vary with the kind of destination being managed: admin-created, auto-created, temporary, or dead message queue. For example, temporary destinations do not need to be explicitly destroyed; auto created properties are configured using broker configuration properties which apply to all auto-created destinations on that broker.
For optimal performance, you can set properties when creating or updating physical destinations. Properties that can be set include the following:
The type and name of the destination.
Individual and aggregate limits for destinations (the maximum number of messages, the maximum number of total bytes, the maximum number of bytes per message, the maximum number of producers).
What the broker should do when individual or aggregate limits are exceeded.
The maximum number of messages to be delivered in a single batch.
Whether dead messages for a destination should be sent to the dead message queue.
Whether (in the case of a clustered broker) a destination should be replicated to other brokers in the cluster.
For a queue destination you can also configure the maximum number of back up consumers and you can specify (for clustered brokers) whether delivery to a local queue is preferred.
You can also configure the limits and behavior of the dead message queue. Note, however, that default properties for this queue differ from those of a standard queue.
Destinations can consume significant resources, depending on the number and size of messages they handle and on the number and durability of the consumers that register; therefore, they need to be managed closely to guarantee good messaging service performance and reliability.
You can set properties to prevent a broker from being overwhelmed by incoming messages and to prevent the broker from running out of memory. The broker uses three levels of memory protection to keep the message service operating as resources become scarce: destination limits, system-wide limits, and system memory thresholds. Ideally, if destination limits and system-wide limits are set appropriately, critical system-memory thresholds should never be breached.
You can set destination attributes to manage memory and message flow for each destination. For example, you can specify the maximum number of producers allowed for a destination, the maximum number (or size) of messages allowed in a destination, and the maximum size of any single message.
You can also specify how to broker should respond when any such limits are reached: to slow producers, to throw out the oldest messages, to throw out the lowest-priority messages, or to reject the newest messages.
You can also use properties to set limits that apply to all destinations on a broker: you can specify the total number of messages and the memory consumed by all messages. If any of the system-wide message limits are reached, the broker rejects new messages.
Finally, you can use properties to set thresholds at which the broker takes increasingly serious action to prevent memory overload. The action taken depends on the state of memory resources: green (plenty of memory is available), yellow (broker memory is running low), orange (broker is low on memory), red (broker is out of memory). As the broker’s memory state progresses from green to red, the broker takes increasingly serious actions:
It throws out in-memory copies of persistent messages in the data store.
It throttles back producers of non-persistent messages, eventually stopping the flow of messages into the broker. Persistent message flow is automatically limited by the requirement that each message be acknowledged by the broker.