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.