If both applications are processing messages at the same rate, the broker will deliver an equal number of messages to both apps. This is often referred to as a competing consumer pattern.įor example, in the below diagram, both Application A and Application B will get messages. Based on the acknowledgment rate from the consumer, the broker will deliver the messages at the appropriate rate. There is also a consideration for the speed of each consuming application, meaning that messages will be sent to the consumer based on how fast or slow the consumer is. It may be required to have multiple instances of an application share an endpoint and consume data in a load-balancing manner.Ī Solace non-exclusive endpoint allows multiple connections to bind to it and messages are round robin distributed to those connected applications. Non-Exclusive Queue (Competing Consumer Pattern)įor some use cases, the ingress rate (publish message rate) may be too fast for a single endpoint consumer to keep up. This can be useful for grouped applications to function properly in a fault tolerant consumer pattern. Note: Topic endpoints do not support multiple consumers when set as exclusive, therefore this fault tolerant consumer pattern only applies to queues.įor the developers out there, it may be useful to know there is an Active Consumer Indication which indicates to a previously standby consumer they are now the active consumer. This provides a fault tolerant method to consuming data from a queue without any downtime. The first instance to connect, or bind, to the queue will receive all messages should that instance of the application disconnect, the next instance that connected to the queue is prepared to take over activity and start consuming.
Using an exclusive queue, a developer could connect multiple instances of an application to the same queue to ensure messages are always processed. There is also the case where a consuming application cannot have downtime when processing time-sensitive data. If the application does not connect for a long period of time and the incoming message rate does not slow, the queue could run the risk of filling up. When an application disconnects from the event broker, the endpoint it was connected to will buffer and save the messages destined for that application. Based on the use case, a queue can have two access types for consumers: exclusive and non-exclusive.Įxclusive Queue (Fault Tolerance Pattern)
In Solace PubSub+ Event Broker, a message from a queue can be consumed by only one application, even though multiple applications can be bound to the queue. I detailed the differences here if you want to learn more, and in this post I’ll explain the two consumer patterns you have to choose from, how they differ, and when you should use each. There are two types of endpoints: a queue endpoint (usually just called a queue) and a topic endpoint.
Solace endpoints are objects created on the event broker to persist messages. Note that in addition to writing this blog post, I’ve also presented this concept in a video you can watch here. A queue provides the guarantee that the message will never be lost even if the consuming application is unavailable or if the message broker crashes. Generally speaking, a queue is defined as a storage area where a message is stored until it is consumed by an application, or it expires. The concept of message queues is fundamental in message-oriented middleware (MOM) and a constant topic of discussion for Solace users.