Chapter 26. Handling Slow Consumers

A slow consumer with a server-side queue can pose a significant problem for server performance. As messages build up in the consumer’s server-side queue, memory usage increases. Consequently, the server can enter paging mode, which can negatively impact performance. Another significant problem is that messages sent to a client’s message buffer can remain waiting to be consumed if the consumer-windows-size attribute is greater than 0. Criteria can be set so that consumers that do not consume messages quickly enough can be disconnected from the server.

In the case where the slow consumer is an MDB, the JBoss EAP server manages the connection. Once the MDB is disconnected, the messages are returned to the queue from which the MDB was consuming, the MDB automatically reconnects, and at this moment, messages are load balanced again to all of the MDBs on the queue. This same process holds for an MDB listening on a durable topic. In the case of a JMS consumer, if it is slow, then it is disconnected, and it reconnects only if the reconnects-attempts is set to -1 or is greater than 0.

In the case of a non-durable JMS subscriber or an MDB with non-durable subscription, the connection is disconnected, which results in the subscription being removed. If the non-durable subscriber reconnects, then a new non-durable subscription is created, and it starts to consume only new messages sent to the topic.

The calculation to determine whether or not a consumer is slow inspects only the number of messages that a particular consumer has acknowledged. It does not take into account whether flow control has been enabled on the consumer, or whether the consumer is streaming a large message, for example. Keep this in mind when configuring slow consumer detection.

Slow consumer checks are performed using the scheduled thread pool. Each queue on the server with slow consumer detection enabled will cause a new entry in the internal java.util.concurrent.ScheduledThreadPoolExecutor instance. If there are a high number of queues and the slow-consumer-check-period is relatively low, then there may be delays in executing some of the checks. However, this will not impact the accuracy of the calculations used by the detection algorithm. See Thread Management for more details about this thread pool.

Slow consumer handling is on a per address-setting basis. See Address Settings for more information on configuring an address-setting, and refer to the appendix for the list of address-setting attributes. There are three attributes used to configure the handling of slow consumers. They are:

slow-consumer-check-period
How often to check, in seconds, for slow consumers. The default is 5.
slow-consumer-policy

Determines what happens when a slow consumer is identified. The valid options are KILL or NOTIFY:

  • KILL will kill the consumer’s connection, which will impact any client threads using that same connection.
  • NOTIFY will send a CONSUMER_SLOW management notification to the client.

The default is NOTIFY.

slow-consumer-threshold
The minimum rate of message consumption allowed before a consumer is considered slow. The default is -1, which is unbounded.

Use the management CLI to read the current values for any of the attributes. For example, use the following command to read the current slow-consumer-policy for the address-setting with the name myAddress. 

/subsystem=messaging-activemq/server=default/address-setting=myAddress:read-attribute(name=slow-consumer-policy)

Likewise, use the following example to set the same slow-consumer-policy. 

/subsystem=messaging-activemq/server=default/address-setting=myAddress:write-attribute(name=slow-consumer-policy,value=<NEW_VALUE>)