Message Delivery Services

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 delivery are used by the broker to manage these tasks in a way that suits your application’s needs.

Physical Destinations

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 an administrator using Message Queue administration tools. Admin-created destinations correspond to destination administered objects created by an administrator and accessed by client applications by using a JNDI lookup. Admin-created destinations can also correspond to destination objects created programmatically by a client application. You use Message Queue administration tools 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 client applications that need a destination at which to receive replies to messages. As their name implies, these destinations are temporary. They are maintained by the broker only for the duration of the connection in which they are created.

  Temporary destinations are only stored persistently only if the consumer of the destination is set to automatically reconnect in the event of failure. Otherwise, they are not recreated when a broker is restarted. Nevertheless, temporary destinations 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.

Managing 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.

Configuring Physical Destinations

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 deleted messages for a destination should be sent to the dead message queue.

• In the case of a broker cluster, whether a destination should be propagated to other brokers in the cluster.

For a queue destination you can also configure the maximum number of active and back up consumers and you can specify (for broker clusters) 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.

Managing Memory

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.

Destination Message Limits

You can set destination properties 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 the 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.

System-Wide Message Limits

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.

System Memory Thresholds

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.