In Chapter 4, Monitoring HornetQ, we learnt how to manage the messages in a queue so that we could control their state and behaviour using JMS and Core APIs. This approach is useless in cases where we would like to monitor a HornetQ instance that is under pressure because of too many messages.
This could happen due to various reasons; as we have seen in Chapter 7, Divert and Filter Messages, it is possible to deliver messages to another queue without changing the producer layer. Using the same scenario, when a device has some fault or it raises an alarm, the alarm is diverted to another queue on a different HornetQ instance.
In such cases, if we have multiple alarms it is possible that the queue that stores the alarms starts growing fast so as to cause an out-of-memory exception.
Using the many features that HornetQ provides, it is possible to control the flow of data in the following two ways:
Client to server side: This means that it is possible to control...