Message Production Is Delayed or Slowed

Symptoms:

• When sending persistent messages, the send method does not return and the client blocks.

• When sending a persistent message, the client receives an exception.

• A producing client slows down.

Possible causes:

• The broker is backlogged and has responded by slowing message producers.

• The broker cannot save a persistent message to the data store.

• Broker acknowledgment timeout is too short.

• A producing client is encountering JVM limitations.

Possible cause: The broker is backlogged and has responded by slowing message producers.

A backlogged broker accumulates messages in broker memory. When the number of messages or message bytes in physical destination memory reaches configured limits, the broker attempts to conserve memory resources in accordance with the specified limit behavior. The following limit behaviors slow down message producers:

• FLOW_CONTROL: The broker does not immediately acknowledge receipt of persistent messages (thereby blocking a producing client).

• REJECT_NEWEST: The broker rejects new persistent messages.

Similarly, when the number of messages or message bytes in brokerwide memory (for all physical destinations) reaches configured limits, the broker will attempt to conserve memory resources by rejecting the newest messages. Also, when system memory limits are reached because physical destination or brokerwide limits have not been set properly, the broker takes increasingly serious action to prevent memory overload. These actions include throttling back message producers.

To confirm this cause of the problem: When a message is rejected by the broker because of configured message limits, the broker returns the exception

JMSException [C4036]: A server error occurred

and makes the following entry in the broker log:

[B2011]: Storing of JMS message from IMQconn failed

This message is followed by another indicating the limit that has been reached:

[B4120]: Cannot store message on destination destName because capacity of maxNumMsgs would be exceeded.

if the exceeded message limit is on a physical destination, or

[B4024]: The maximum number of messages currrently in the system has been exceeded, rejecting message.

if the limit is brokerwide.

More generally, you can check for message limit conditions before the rejections occur as follows:

• Query physical destinations and the broker and inspect their configured message limit settings.

• Monitor the number of messages or message bytes currently in a physical destination or in the broker as a whole, using the appropriate imqcmd commands. See Chapter 20, Metrics Information Reference for information about metrics you can monitor and the commands you use to obtain them.

To resolve the problem:

• Modify the message limits on a physical destination (or brokerwide), being careful not to exceed memory resources.

  In general, you should manage memory at the individual destination level, so that brokerwide message limits are never reached. For more information, see Broker Memory Management Adjustments.

• Change the limit behaviors on a destination so as not to slow message production when message limits are reached, but rather to discard messages in memory.

  For example, you can specify the REMOVE_OLDEST and REMOVE_LOW_PRIORITY limit behaviors, which delete messages that accumulate in memory (see Table 17–1).

Possible cause: The broker cannot save a persistent message to the data store.

If the broker cannot access a data store or write a persistent message to it, the producing client is blocked. This condition can also occur if destination or brokerwide message limits are reached, as described above.

To confirm this cause of the problem: If the broker is unable to write to the data store, it makes one of the following entries in the broker log:

[B2011]: Storing of JMS message from connectionID failed[B4004]: Failed to persist message messageID

To resolve the problem:

• In the case of file-based persistence, try increasing the disk space of the file-based data store.

• In the case of a JDBC-compliant data store, check that JDBC-based persistence is properly configured (seeConfiguring a JDBC-Based Data Store). If so, consult your database administrator to troubleshoot other database problems.

Possible cause: Broker acknowledgment timeout is too short.

Because of slow connections or a lethargic broker (caused by high CPU utilization or scarce memory resources), a broker may require more time to acknowledge receipt of a persistent message than allowed by the value of the connection factory’s imqAckTimeout attribute.

To confirm this cause of the problem: If the imqAckTimeout value is exceeded, the broker returns the exception

JMSException [C4000]: Packet acknowledge failed

To resolve the problem: Change the value of the imqAckTimeout connection factory attribute (see Reliability And Flow Control).

Possible cause: A producing client is encountering JVM limitations.

To confirm this cause of the problem:

• Find out whether the client application receives an out-of-memory error.

• Check the free memory available in the JVM heap, using runtime methods such as freeMemory, maxMemory, and totalMemory.

To resolve the problem: Adjust the JVM (see Java Virtual Machine Adjustments).