36.6. Message Redistribution

Another important part of clustering is message redistribution. Earlier, it was demonstrated how server side message load balancing round robins or directs messages to all nodes across the cluster. If forward-when-no-consumers is false, messages will not be forwarded to nodes which do not have matching consumers. This ensures that messages do not arrive on a queue which has no consumers to consume them, however there is a situation it does not solve: What happens if the consumers on a queue close after the messages have been sent to the node? If there are no consumers on the queue the message will not get consumed and a starvation situation will be created.
Message redistribution addresses this and HornetQ can be configured to automatically redistribute messages from queues which have no consumers to other nodes in the cluster which do have matching consumers.
Message redistribution can be configured to act immediately after the last consumer on a queue is closed, or to wait for a configurable delay after the last consumer on a queue is closed before redistributing. By default, message redistribution is enabled with a delay of 60000 milliseconds (1 minute).
Message redistribution can be configured on a per address basis, by specifying the redistribution delay in the address settings. For more information on configuring address settings, refer to Chapter 23, Queue Attributes.
An address settings snippet from <JBOSS_HOME>/jboss-as/server/<PROFILE>/deploy/hornetq/hornetq-configuration.xml showing how message redistribution is enabled for a set of queues follows:
<address-settings>     
   <address-setting match="jms.#">
      <redistribution-delay>0</redistribution-delay>
   </address-setting>
</address-settings>
The above address-settings block would set a redistribution-delay of 0 for any queue which is bound to an address that starts with "jms.". All JMS queues and topic subscriptions are bound to addresses that start with "jms.", so the above would enable instant (no delay) redistribution for all JMS queues and topic subscriptions.
The attribute match can be an exact match or it can be a string that conforms to the HornetQ wildcard syntax (described in Chapter 11, Understanding the HornetQ Wildcard Syntax).
The element redistribution-delay defines the delay in milliseconds after the last consumer is closed on a queue before redistributing messages from that queue to other nodes of the cluster which do have matching consumers. A delay of zero means the messages will be immediately redistributed. A value of -1 signifies that messages will never be redistributed.
It often makes sense to introduce a delay before redistributing as it is a common case that a consumer closes but another one quickly is created on the same queue, in such a case you probably do not want to redistribute immediately since the new consumer will arrive shortly.