Message queues and topic endpoints can optionally support priority message delivery. When you enable an endpoint to respect message priority, the priority field in messages from publishers are respected for all guaranteed and promoted direct messages. In other words, the queue or topic endpoint delivers queued messages in priority order; meaning that all messages of a higher priority are delivered before any messages of a lower priority.
In order to provide high message delivery throughput to consumers, PubSub+ event brokers and APIs have a message prefetch pipeline for messages to be sent to client consumer flows. In the process of loading this prefetch pipeline, the event broker respects priority (high priority messages are fed into the pipeline ahead of low priority messages). However, once messages are loaded into the pipeline, new high priority messages added to the pipeline will never jump ahead of lower priority messages already in the pipeline. This pipeline consists of two stages:
-
The event broker fetch stage, which attempts to ensure there are messages to send to a consumer when the transport allows it.
-
The transport/delivery stage. This is a shared responsibility of the network layer transport from broker to API, as well as a queuing strategy implemented within client APIs.
The event broker prefetch stage is not tunable. The implication of this is that no matter how much the depth of the transport/delivery stage of the pipeline is reduced, it will always be possible for an application to receive up to 100 low priority messages after a high priority message is received by the event broker and placed into the pipeline. The actual number may be less than 100, depending on the precise state of the broker at the time the high priority message is received.
The implementation details of the transport/delivery stage of the pipeline vary to some degree based on the particular client API that is used. One tool that is available on the event broker side, and therefore consistently available to all clients, is the ability to configure a queue's max-delivered-unacked-msgs-per-flow. This value indicates the maximum number of messages that the event broker can send to a consumer before the client application acknowledges the sent messages. In other words, this value bounds both:
-
the number of messages in the transport/delivery stage of the pipeline.
-
the number of messages received, but not yet acknowledged by the client application.
Reducing this value to its minimum value of 1 minimizes the number of low priority messages that can be delivered ahead of a high priority message. However, this may impact the performance of the application. When reducing this value, you should experiment to determine how far it can be safely lowered with different network environments without negatively impacting message delivery performance.
Priority Levels
PubSub+ event brokers support ten levels of priority from 0 (lowest) to 9 (highest). If the priority field in the received message is greater than 9, then the message is treated as priority 9. Messages that do not have a priority field are treated as priority 4.
Considerations When Enabling Support For Message Priority
You should understand the following considerations when deciding to enable an endpoint to respect message priority:
- When you enable an endpoint to respect message priority, high priority message latency is improved while delivering spooled messages.
- Enforcing message priority increases the chance that duplicate messages will be delivered to a consuming client after it recovers from a connection failure.
- Although message priority is maintained between replication sites and respected after a failover, enforcement of message priority on replication queues and topics is always disabled. In other words, replication bridge links do not respect the priority of replicated messages.
- When the event broker is streaming messages (messages are consumed faster than they are produced), each message is delivered as it's received, which may not be in priority order.
- Dead message queues can be configured to respect message priority.
- Last value queues always store the last message received, regardless of the priority value of the message.
- Message priority is not respected for queue browsers. Messages are delivered to browsers in the order in which they were published.
- Message priority is not respected for bridges. However, the priority information is maintained. Messages are delivered by the bridge in the order in which they were published.
- Message priority is not respected for partitioned queues, even if they are configured to respect it.
- Message priority does not apply to MQTT queues (MQTT queues cannot be configured to respect message priority).
- Messages consumed in a transaction respect message priority.
For information describing how to enable an endpoint to respect message priority using the Solace CLI, see Configuring Queues or Configuring Topic Endpoints.
For more information about enabling respect for message priority for queues in PubSub+ Broker Manager, see Configuring Message Delivery options for PubSub+ Cloud or Configuring Message Delivery options for software event brokers and appliances.