Both types of endpoints are visible only on the event broker. Client applications connect to the event broker that has the endpoint that it wants to consume messages from. There is no propagation of the existence of endpoints from one event broker to another via control or routing protocols, so there is no need for endpoints to have unique names throughout a network.
Queues are significantly more flexible than topic endpoints and are the recommended approach for most applications. The use of topic endpoints should be restricted to JMS applications.
Endpoint Durability
Queues and topic endpoints can be either durable or temporary, except for Partitioned Queues, which can only be durable.
Durable Endpoints
Durable queues and topic endpoints are provisioned objects on the event broker that have a life span independent of a particular client session. They also survive an event broker restart and are preserved as part of the event broker configuration for backup and restoration purposes. Administrators can provision durable queues and topic endpoints through the Solace CLI, SEMP, or Broker Manager. Client applications can dynamically provision durable endpoints through the Solace messaging APIs.
A durable endpoint has an associated access type which determines how messages are delivered to bound consumer flows. For more information, see Queue Access Types and Topic Endpoints.
Temporary Endpoints
Temporary queues and topic endpoints are dynamically created and destroyed by client applications. Temporary queues and topic endpoints are typically used as temporary destinations for service requests.
When a client application has a connected session, it can provision a temporary queue or topic endpoint and create a consumer flow to bind to it. These temporary queues and topic endpoints are non-durable because they only last as long as the client’s session is connected. Only a single consumer can bind to a non-durable endpoint, and there is no support for multiple consumers or non-exclusive access.
The naming of the temporary destinations is controlled by the application. On a BIND request from the client, a name is provided. If the destination does not exist, one is created.
When a client dynamically creates a queue, it is configured by those endpoint properties and provision flags that the client may provide with a create API function or method. Any other endpoint parameters are then configured with the values used for endpoints provisioned by an administrator through the Solace CLI. By default, the system defaults are used. However, it is also possible to use CLI-provisioned queues and topic endpoints with custom values, and those values will be applied to any new client-created queues and topic endpoints.
A non-durable queue or topic endpoint can be dynamically created if:
- The client is associated with a profile that permits clients to create endpoints.
- The maximum number of endpoints available for the Message VPN that the client is connected has not been reached.
- The maximum number of endpoints permitted per client username within a client profile has not been exceeded.
- The number of endpoints does not exceed the system-wide limit.
Topic Subscriptions
You can add one or more topic subscriptions to a durable endpoint so that Guaranteed messages published to matching topics are delivered to that endpoint.
Any Guaranteed messages published to topics that match subscriptions associated with endpoints are delivered to those endpoints. Error indications are returned to the publisher if the message can't be delivered to one or more endpoints for any reason. That is, the feedback to the publisher is identical to that provided when the messages are published directly to the endpoint.
As illustrated in the following diagram, topic subscriptions allow a single message published to a topic to be delivered to a combination of topic endpoints, queues, and consuming clients with matching Direct messaging topic subscriptions. For information on how a message’s delivery mode can be changed to deliver a message to a client’s topic subscription, refer to Topic Matching and Message Delivery Modes.
The mechanism for adding subscriptions depends on the type of endpoint:
- For queues, subscriptions can be configured as a property of the queue itself. Subscription mappings are applicable to both durable and non‑durable queues. If you delete a queue for any reason, all topic subscriptions configured for that queue are also deleted. To add a subscription using Broker Manager, see
- For topic endpoints, the client specifies its required subscription as part of a flow bind request. For more information, see
Topic Subscription Exceptions
In addition to topic subscriptions, you can add one or more topic subscription exceptions to a durable queue so that Guaranteed messages published to matching topics are not delivered to the queue. Topic subscription exceptions are not supported for topic endpoints.
Using topic subscription exceptions allows you to easily exclude specific topics from the set of topics delivered to a the queue by adding a leading "!" character to the topic subscription. For example, if you add a topic subscription "animals/f*" and a topic subscription exception "!animals/fox" to a queue, guaranteed messages published to "animals/frog" are delivered to the queue; however, messages published to "animals/fox" are discarded.
Topic subscription exceptions are enabled by default, and always take precedence over subscriptions regardless of the order in which the subscriptions and the exceptions are configured.