Page History

...

Broker Changes

Extension Point
v1: To enable the broker to monitor the queues and perform the appropriate action we can extend a existing mechanism. That of the VirtualHost housekeeping thread. This is a thread that checks all the queues for alerting purposes. Currently this is done via a single TimerTask however by updating this to utilise a ScheduledThreadPoolExecutor we can run arbitrary processes in the pool and ensure that any error in their operation does not prevent them from running on their defined schedule.

v2: Extending the broker to provide an event processor for major events that occur such as MessageEnqueue/Dequeue will allow us to delegate the processing of the events. This is benefitial for two reasons one it allows delegation to a non-message delivery thread and two, it will allow multiple listeners to be registed so many components can respond to the event. This will allow other listeners such as alerting, producer-side flow-control or QMF Agents to receive the event in addition to the Slow Consumer Detection.
This approach is preferable to v1 above as it removes the need for another thread to be actively checking the queues, freeing up a CPU.

Queue Detection
v1: The target queues can easily be identified by checking their bindings. Topics are all bound to the TopicExchange. Once we have identified a topic exchange we can use the queue assigned configuration to determine if we are checking depth, messageCount or messageAge as a means of selecting the subscription for processing.

v2: The use of an event based processor means there is no need for direct queue detection checks. Rather what we will need to do is to process the configuration and register an event listeners with the appropriate values.

Processing
When we have our identified queue/subscription we have two policy options. In both situations we will identify the session/channel that the subscription is on and close it with the appropriate error code. The first policy is 'Delete' which will then ensure that the queue is deleted and all messages released after the session/channel has been closed. The second policy is 'Cycle' which will limit the queue to the given size. This means that the oldest messages, i.e. the ones at the front, will be purged as new messages arrive.

...