Receiving Guaranteed Messages

To receive published Guaranteed messages (that is, messages that have a delivery mode of persistent or non‑persistent), a client must create a consumer flow to bind to a queue endpoint or a topic endpoint provisioned on the event broker. Once the client is bound to the endpoint, it can receive published Guaranteed messages that are delivered and spooled to that endpoint.

When a consuming client successfully receives a Guaranteed message over a flow, a corresponding application acknowledgment is required to indicate to the event broker that the client application received the message, and then the message can be removed from the endpoint.

Related Event Broker Provisioning and Configuration Information

For clients to consume messages from the message VPN they are connected to, the event broker must have Guaranteed messaging and message spooling enabled. In addition, the clients must be assigned appropriately configured client profiles and/or Access Control List (ACL) profiles:

  • To receive messages with a Guaranteed transport delivery mode, clients must be assigned client profiles that have the allow-guaranteed‑message‑receive parameter enabled. In addition, if clients are going to use non-durable message consumers, the assigned client profiles must also have the allow‑guaranteed‑endpont-create parameter enabled because these clients automatically create temporary queues/topic-endpoints.
  • To allow clients to subscribe to topics (or to only a specific set of topics) clients must be assigned ACLs with the appropriate access controls.

For more information on how to configure event brokers for Guaranteed messaging and authorizing connected clients through client profiles and ACLs, refer to Configuring Client Authentication.

Queues

Messages published to a queue destination are spooled to a matching queue endpoint on the event broker. Therefore, a queue acts as both a destination that messages can be published to and as an endpoint on the event broker that clients can bind to and then browse or consume messages from. In this way, a queue can be used in a typical point-to-point (P2P) model.

However, it is also possible to add topic subscriptions to a queue so messages published to matching topics are delivered to the queue. (For more information, refer to Adding Topic Subscriptions to Queues.) Therefore, it is also possible to use queues in a publish and subscribe (pub/sub) model.

Multiple flows can be bound to a queue, but a single spooled message can only be consumed by a single consuming client bound through one of those flows. If the queue is configured with an access type of exclusive, only the first flow to bind can actively receive messages. If the first flow disconnects, the second flow can start receiving messages, and so on. An exclusive queue always delivers messages in the order they are received.

If the queue is configured with an access type of non‑exclusive, each bound flow receives messages in a round-robin fashion. For more information on access types, refer to Defining Endpoint Properties.

Topic Endpoints

A topic endpoint attracts messages published to a topic that match the topic subscription that is associated with the endpoint. Topic endpoints are equivalent to durable topic subscriptions in Java Message Service (JMS). Topic endpoints can be used in a pub/sub model.

For an exclusive topic endpoint, only one client can bind and receive messages; if other clients attempt to bind, they will be rejected. An exclusive durable topic endpoint always delivers messages in the order they are received. For non-exclusive durable topic endpoints, multiple consumers can bind and each is serviced in round‑robin fashion.

  • When using the JCSMP or .NET APIs, a client must obtain the appropriate topic instance to use topic subscriptions to receive messages (refer to Creating Topics).
  • When using the JavaScript or Node.js APIs, both queues and topic endpoints are modeled as queues and passed in as a solace.QueueDescriptor object to the solace.MesssageConsumerProperties, which is used to create the message consumer.
  • It is possible for messages published with a Direct delivery mode to be spooled to a topic endpoint when there is a match between the message’s topic destination and the topic subscription set for the topic endpoint. In this case, when the message is spooled to the endpoint, it is given a non‑persistent delivery mode so that the receiving client can consume the message over its established consumer flow. For more information, refer to Topic Matching and Message Delivery Modes.

Endpoint Durability

Endpoints can be durable or non-durable.

  • Durable endpoints have life spans independent of any particular session. Messages can accumulate on a durable endpoint even when no session is connected.

    Durable endpoints can only be used with a physical event broker when it has an assured delivery blade (ADB) installed and Guaranteed messaging and message spooling enabled. For information configuring an event broker for Guaranteed messaging, refer to Guaranteed Messaging Configuration.

  • Non-durable or temporary endpoints are created by the client in a session and last for the duration of the session. When a session is closed, temporary endpoints and their messages are deleted. On graceful closure of a client session, temporary endpoints are deleted immediately. Temporary endpoints are maintained for a maximum of 60 seconds if the client that created those endpoints disconnects for a reason other than an event broker HA failover or reboot. If those clients do not reconnect within this time, the temporary endpoints are removed. If the client disconnect is caused by an event broker HA failover or reboot, the temporary endpoints are maintained for a maximum of 180 seconds.

Durable Endpoints vs Non-Durable Endpoints

The lists below outline the key differences between durable and non-durable endpoints in terms of creation, persistence, and consumer support.

Durable endpoints:

  • Can be created by administrators or applications.
  • If an administrator creates an endpoint, an application cannot delete that endpoint.
  • Persist over high-availability (HA) and data replication (DR) failovers.
  • Can support multiple consumers based on the configurations of that endpoint.
  • Names must be defined by the administrator or the application that provisions the endpoint.

Non-durable endpoints:

  • Can only be created by applications.
  • Persist for 60 seconds after unexpected disconnects.
  • Persist over high-availability (HA) failovers, but not data replication (DR) failovers.
  • Only support a single consumer, and their lifespan depends on that consumer.
  • Names can be auto-generated or defined by the application.