Specify message limit and limit behavior attributes for the
topic (see Table 18–1). For example,
you can specify the REMOVE_OLDEST and REMOVE_LOW_PRIORITY limit behaviors, which delete messages that accumulate in memory.

Limit the time messages can remain in memory by rewriting
the producing client to set a time-to-live value on each message. You can
override any such settings for all producers sharing a connection by setting
the imqOverrideJMSExpiration and imqJMSExpiration connection
factory attributes (see Message Header Overrides).

Possible cause: Too few consumers
are available to consume messages in a multiple-consumer queue.

If there are too few active consumers to which messages can
be delivered, a queue destination can become backlogged as messages accumulate.
This condition can occur for any of the following reasons:

Too few active consumers exist for the destination.

Consuming clients have failed to establish connections.

No active consumers use a selector that matches messages in
the queue.

To confirm this cause of the problem: To
help determine the reason for unavailable consumers, check the number of active
consumers on a destination:

imqcmd metrics dst -n destName-t
q -m con

To resolve
the problem: Depending on the reason for unavailable consumers,

Create more active consumers for the queue by starting up
additional consuming clients.

Specify message limit and limit behavior attributes for the
queue (see Table 18–1). For example,
you can specify the REMOVE_OLDEST and REMOVE_LOW_PRIOROTY limit behaviors, which delete messages that accumulate in memory.

Limit the time messages can remain in memory by rewriting
the producing client to set a time-to-live value on each message. You can
override any such setting for all producers sharing a connection by setting
the imqOverrideJMSExpiration and imqJMSExpiration connection
factory attributes (see Message Header Overrides).

In this case, topic subscribers or queue receivers are consuming
messages more slowly than the producers are sending messages. One or more
destinations are getting backlogged with messages because of this imbalance.

To confirm this cause of the problem: Check
for the rate of flow of messages into and out of the broker:

Significant broker resources can be consumed in processing
client acknowledgments. As a result, message consumption may be slowed in
those acknowledgment modes in which consuming clients block until the broker
confirms client acknowledgments.

JMS payload messages and Message Queue control
messages (such as client acknowledgments) share the same connection. As a
result, control messages can be held up by JMS payload
messages, slowing message consumption.

To confirm this cause of the problem:

Check the flow of messages relative to the flow of packets.
If the number of packets per second is out of proportion to the number of
messages, client acknowledgments may be a problem.

Check to see whether the client has received the following
exception:

JMSException [C4000]: Packet acknowledge
failed

To resolve the problem:

Modify the acknowledgment mode used by clients: for example,
switch to DUPS_OK_ACKNOWLEDGE or CLIENT_ACKNOWLEDGE.

If using CLIENT_ACKNOWLEDGE or transacted
sessions, group a larger number of messages into a single acknowledgment.

In this case, messages are flowing into the broker faster than
the broker can route and dispatch them to consumers. The sluggishness of the
broker can be due to limitations in any or all of the following:

CPU

Network socket read/write operations

Disk read/write operations

Memory paging

Persistent store

JVM memory limits

To confirm this cause of the problem: Check
that none of the other possible causes of this problem are responsible.

To resolve the problem:

Upgrade the speed of your computer or data store.

Use a broker cluster to distribute the load among multiple
broker instances.

Messages are held in a destination until they have been acknowledged
by all consumers to which they have been sent. If a client is not acknowledging
consumed messages, the messages accumulate in the destination without being
deleted.

For example, client code might have the following defects:

Consumers using the CLIENT_ACKNOWLEDGE acknowledgment
mode or transacted session may not be calling Session.acknowledge or Session.commit regularly.

Consumers using the AUTO_ACKNOWLEDGE acknowledgment
mode may be hanging for some reason.

To confirm this cause of the problem: First
check all other possible causes listed in this section. Next, list the destination
with the following command:

imqcmd list dst

Notice whether the number of messages listed under the UnAcked header
is the same as the number of messages in the destination. Messages under this
header were sent to consumers but not acknowledged. If this number is the
same as the total number of messages, then the broker has sent all the messages
and is waiting for acknowledgment.

To
resolve the problem: Request the help of application developers
in debugging this problem.