Competing Queue Consumer Pattern With MuleSoft

In this article, we will learn how to implement the competing queue consumer pattern with MuleSoft. In a message-oriented or event-driven architecture, implementing these patterns provides benefits such as scalability, increased throughput, fault tolerance, high availability, and reliability.

Competing queue consumer patterns enable the processing of messages in parallel by multiple consumers from the same channel. This pattern is very useful when you want to process a series of small tasks asynchronously in parallel by multiple consumers of the same pool instance.

Let’s consider the use case where one publisher is sending the message to the queue and the consumer is retrieving the message from the queue. In this case, the rate of sending the message from the publisher is low and the consumer has consumed and processed a limited number of messages from the queue.

This diagram shows that the message is sent to multiple consumers in a round-robin way because in the JMS listener configuration, the attribute onlyPrimaryNode is false. This means all nodes can actively listen to the queue and process the messages concurrently as shown in the above image.

There might be a scenario where the ingress traffic increases such as publishers start sending more messages to the queue or the number of publishers increases. In this scenario, the rate at which messages are published to the queue is faster than the rate at which the messages can be consumed.

In such cases, we can scale up the consumers listening to the message channel, so multiple consumers can process the message from the queue in parallel. This way, traffic is distributed among multiple consumers ensuring that messages are processed concurrently and one message is delivered to one consumer even if multiple consumers are listening to the same queue.

Implementing Competing Queue Consumer Pattern With Anypoint Clustering.

Anypoint Clustering is a group of servers or nodes that act as a single unit. There can be up to 8 servers in a single cluster. The application instances in a cluster are aware of each other, share common information, and synchronize statuses. You must create the Mule runtime engine instances and add the Mule servers to Anypoint Runtime Manager.

In an active-active model there is no primary node; however, one of the nodes acts as the primary polling node. This means that sources can be configured to only be used by the primary polling node so that no other node reads messages from that source.

This feature works differently depending on the source type:

• Scheduler source: only runs in the primary polling node.
• Any other source: defined by the attribute. Check each connector’s documentation to know which is the default value for primaryNodeOnly in that connector.

In the JMS connector’s configuration, users can configure the attribute primaryNodeOnly to define whether a message will be picked by the primary node or any node in the cluster.

In other words:

• If the primaryNodeOnly attribute is false, the clustering works in active-active mode.
• If the primaryNodeOnly attribute is true, the clustering works in active-passive mode.

To implement the competing queue consumer pattern, the application has to be deployed on a cluster with a queue listener and you need to make sure the attribute primaryNodeOnly is set to false. This will ensure that all the nodes in the cluster have the applications deployed with a queue listener that reads the messages concurrently and processes them asynchronously.

This diagram is showing that the message is sent to multiple consumers in a round-robin way because the attribute onlyPrimaryNode is false in the JMS listener configuration. This means all nodes can actively listen to the queue and process the messages concurrently as shown in the image above

Implementing Competing Queue Consumer Pattern With CloudHub

To enable the competing queue consumer pattern with CloudHub, we need to deploy an application having the queue listener on more than one worker. In this way, workers will receive messages from the queue in a round-robin way.

In CloudHub, applications can be easily scaled up or down by increasing or decreasing the number of workers assigned to the applications.

Benefits of Implementing the Competing Queue Consumer Pattern

Scalability

Consumers can be added or removed depending on traffic from publishers on message channels. By increasing the number of consumers, it will enable the distribution of traffic among multiple consumers and each message can be processed asynchronously and independently.

High Availability

There are multiple consumers listening to the same message channel. In case one of the consumers crashes, shuts down, or goes into offline mode, there are other consumers that can process the messages.

Reliability and Resilience

If the message processing fails for one of the messages, the message will be returned to the queue and will be available to reprocess again by other consumers.

There are various use cases where we can use the competing queue consumer pattern:

• When there is no need to maintain the message sequence in the same order they have been sent to the queue while consuming and when those messages can be consumed and processed independently and asynchronously.
• When the process is divided into a small set of tasks and each task can be processed asynchronously and independently in concurrent execution mode.
• When the traffic is very high and variable, there is a need for distribution of traffic as it cannot be handled by a single consumer. In such cases, we can have multiple consumers processing the messages concurrently.
• When there is a need for message reliability, fault tolerance, and high availability.

Conclusion

The competing queue consumer pattern provides many benefits in terms of scalability, high availability, fault tolerance, resilience, and reliability. It is especially useful while implementing an event-driven architecture. We have also seen above that we can implement this pattern easily with MuleSoft and provide an option to easily scale up your applications.