Topic Matching and Message Delivery Modes
When a Solace PubSub+ event broker using Guaranteed Messaging receives messages published to a topic, it can automatically change the delivery mode of the messages to accommodate the persistence requirements of an endpoint or a client subscription when there is a topic match. Changing message delivery modes is also known as message promotion and demotion.
Message promotion and demotion can introduce several potential drawbacks to your deployment. Carefully consider the following limitations before deciding to implement this feature:
-
Message promotion is not guaranteed to be lossless. A Direct message publisher can send messages faster than the Guaranteed messaging path can process messages and it doesn’t have the same backpressure mechanisms as a Guaranteed publisher. In this case, the event broker aggressively discards messages on the promotion path to protect the Guaranteed messaging path.
-
Message promotion can lead to resource issues. Because a Direct message publisher can send messages faster than a Guaranteed messaging client can consume them, the disk space allocated for queues on the event broker can be quickly consumed.
-
A high rate of message promotion can impact latency for Guaranteed messaging.
-
Message demotion can result in duplicate messages. If the publishing application doesn’t receive acknowledgement from the event broker, messages are retransmitted. The event broker has built in mechanisms to prevent this retransmission for Guaranteed messaging subscribers, however Direct messaging subscribers receive additional copies.
For additional guidance, contact our Professional Services Group.
Client publishes a Direct message to a topic that matches the topic subscription set for an endpoint
To show how a messageʼs delivery mode might be changed, consider when a client publishes a Direct message to a topic that matches the topic subscription set for an endpoint (either a queue that has a topic subscription added to it or a topic endpoint). Because an endpoint can only accept non‑persistent and persistent messages, the event broker will change the messageʼs delivery mode to non-persistent so that the endpoint can receive it. Note that when a client publishes a message as Direct, the message is not acknowledged back to the client. However, when the message’s delivery mode is changed to non‑persistent and is spooled to the endpoint, the message then acts as a Guaranteed message, and an acknowledgment from the receiving client is provided to the event broker.
For an illustration of how the delivery mode of a message published as Direct can be changed if it matches a Topic assigned to an endpoint, refer to Publishing Direct Messages.
Event broker receives a persistent message published to a topic
Also, if an event broker receives a persistent message published to a topic, it delivers the message to any endpoints that have matching topic subscriptions. However, because topic subscriptions registered for individual clients are for Direct messages, the event broker can change the message’s delivery mode to Direct and send it to those clients with matching topic subscriptions. In this scenario, because the client published the message as persistent, the message is acknowledged back to the publishing client.
The only way for a client to receive Persistent messages is to either bind to a durable topic endpoint or queue, or request that a non-durable queue or topic endpoint be created for it.
For an illustration of how the delivery mode of a message published as Non‑Persistent or Persistent can be changed if it matches a client’s Topic subscription, refer to Publishing Guaranteed Messages.
How messages’ delivery modes can be changed for endpoints with matching topics
The table below lists how messages’ delivery modes can be changed for endpoints with matching topics.
| Delivery Mode of Published Message | Received by Endpoint as ... |
|---|---|
| Direct | Non-Persistent |
| Non-Persistent | Non-Persistent |
| Persistent | Persistent |