Managing Guaranteed Messaging

The Guaranteed Messaging facility can be used to ensure that the delivery of a message between two applications is guaranteed even in cases where the receiving application is off line, or there is a failure of a piece of network equipment. Once a Solace router has acknowledged receiving a Guaranteed message from a publisher, it is committed to delivering that message.

Guaranteed Messaging also ensures that published messages can be reliably delivered to each matching client once and only once, and that messages are delivered in the order they are published.

Note:  To support Guaranteed Messaging, a Solace router must have Guaranteed Messaging and message spooling enabled. By default, these are not enabled for physical router (that is, an appliance), but they are enabled for a virtual messaging routing (VMR). An appliance must also have an Assured Delivery Blade (ADB) and a Host Bus Adapter (HBA) installed.

Feature Interoperability Limitations

Observe the following limitations:

  • Topic endpoint subscriptions follow the “deliver always” paradigm in the Deliver-To-One messaging feature.
  • With the exception of message spool-specific details, the show User EXEC commands do not make a distinction between durable and non-durable destinations. That is, the same show commands and options exists for both durable and non-durable destinations.
  • Guaranteed temporary destinations and their content survive a redundancy switch provided that the bind from the client occurs within the switchover time.
  • Guaranteed messages are not routed between Solace routers. The multi‑node routing feature is for use with Direct messages only.
  • The Solace JavaScript API does not support Guaranteed Messaging.

Functional Parameters to Consider When Provisioning Endpoints

Functional parameters to consider when provisioning queues and topic endpoints on Solace routers include:

  • technology used by connected client. For example:
    • Solace enterprise Messaging API
    • Solace Web messaging API
    • non-Solace technology: OpenMAMA API, REST messaging, MQTT
  • endpoint durability: durable or non-durable
  • message delivery type: Guaranteed or Direct
  • message type: persistent, non-persistent, or Direct

The following table lists the supported queue and topic endpoint functionality. When created, the associated client durability and message delivery attributes for queues and topic endpoints are assigned.

Supported Queue and Topic Endpoint Functionality

 

Durable Client

Non-Durable Guaranteed Client

Non-Durable Direct Client

Destination Types

queue, topic endpoint

temporary queue, topic/temporary topic

temporary queue, topic/temporary topic

Endpoints Survive Client Disconnect?

Yes

Yes, but only within a certain period of time (a short delay for client disconnect/connect case)

No

Endpoints Survive Redundancy Switchover?

Yes

Yes, but only in the case of a client reconnect within a certain period of time

No

Requires physical ADB?

Yes, if endpoint is on a physical appliance

Yes, if endpoint is on a physical appliance

No

Guaranteed Message Ordering?

Yes, but with the exception of non‑exclusive queues, which can shuffle message order for the sake of load balancing

Yes

No

Guaranteed Message Expiry (TTL)?

Yes

Yes

No

Messages Survive Client Disconnects?

Yes

Yes, but only within a certain period of time (a short delay for client disconnect/connect case)

No

Messages Survive Redundancy Switchover?

Yes

Yes, but only within a certain period of time (a short delay for client disconnect/connect case)

No

Client Access Type

Exclusive queue, non-exclusive queue, one-and-only-one durable topic endpoint

At most one client

At most one client