Configuring Endpoint Templates

Endpoint templates are configurable objects that administrators can use to specify custom attributes and parameters for any new client-created endpoints. When client-created endpoints are created dynamically using an API, the endpoint name can be matched to the endpoint template. All custom attributes that are configured in the endpoint template are copied to the client-created endpoint. For more information, see Queues and Topic Endpoints.

Client profiles have an optional copy-from-template-on-create command for both queues and topic endpoint templates. You can use the copy-from-template-on-create command to specify a CLI-provisioned endpoint template, and those template values are applied to any new client-created endpoints. For more information, see Configuring Initial Values for Client-Created Endpoints.

For information about creating and configuring endpoint templates in PubSub+ Broker Manager, see Configuring Endpoint Templates for PubSub+ Cloud or Configuring Endpoint Templates for software event brokers and appliances.

Configuring Queue Templates

To configure a queue template in a given Message VPN, enter the following commands:

solace(configure)# message-spool message-vpn <vpn-name>
solace(configure/message-spool)# create queue-template <name>
solace(configure/message-spool/queue-template)#

Where:

<name> is the queue template name of up to 255 characters.

The no version of the command, no queue-template <name>, deletes the specified queue template from the Message VPN.

From here, you can now assign custom attributes and parameters to the queue template that can be copied to any client created queues. You can start by setting up a name-filter that can be used to match a queue name with a queue template.

Setting Name Filters to Match Queue Names

Administrators can use name filters to match a queue name with a queue template. More precisely, name filter is a wildcard pattern that is used to determine which queues use settings from a given template. Following two types of wildcards are supported: * and >.

Rules governing the use of the wildcards:

* matches zero or more characters but never a slash (/). It can be present only at the end, after a / (as in, animals/domestic/*).
Example: animals/domestic/* matches the queues animals/domestic/cats and animals/domestic/dogs, but it doesn't match the queue animals/domestic/dogs/beagles.
> matches anything with identical prefixes to the name-filter, but only when it's placed at the end (as in, animals/domestic/>). It is considered a wildcard only when placed at the end, after a /.
Example: animals/domestic/> matches the queues animals/domestic/cats, animals/domestic/dogs and animals/domestic/dogs/beagles, but it doesn't match the queue animals/domestic.

To configure a name-filter that can be used to match a queue name with a queue template, enter the following command:

solace(configure/message-spool/queue-template)# name-filter <name>

Where:

name is the value to be used for the name-filter.

The no version of the command, no name-filter <name>, returns its value to the default.

When configuring name filters, the best practice is to avoid overlapping name filters. If you do use overlapping name filters, the event broker takes the longest non-wildcarded prefix when resolving multiple matches.

Setting Durability Override

The durability-override command allows to control the durability of client created well-known durable queues. When a client’s API-created queues are created, with durability-override non-durable specified in the queue template, the client created well-known durable queue is converted to a well-known non-durable queue. The created queue will be non-durable, regardless of what the client requested during queue creation.

To configure durability-override to controls the durability of a queue created from a given template, enter the following CONFIG command:

solace(configure/message-spool/queue-template)# durability-override {none | non-durable}

Where:

none is the durability of the queue as requested on create.

non-durable is the durability of the created queue, which will be non-durable, regardless of the specified durability.

The no version of the command, no durability-override {none | non-durable}, returns its value to the default (none).

Durability override is not support for MQTT queues.

For more information, see Well-Known Queues.

Setting Access Types

To configure the client access type for durable message queues, enter the following CONFIG command:

solace(configure/message-spool/queue-template)# access-type {exclusive | non-exclusive}

Where:

exclusive specifies that multiple subscriber flows established by clients can be bound to the queue, but only one flow out of all the bound flows is able to receive messages at a time. (That is, only one flow can be active.) The first flow to bind to the queue can consume messages from it, and when that Flow disconnects, the next oldest Flow to bind becomes active and can begin receiving messages, and so on.

non-exclusive specifies that all bound Flows are able to receive messages, and when multiple Flows are bound to a non‑exclusive Queue, they receive messages in a round-robin (if the partition count is zero) or partitioned (if the partition count is non-zero) fashion, see Configuring Endpoint Templates. This provides load-balancing; however, if a connection fails, then unacknowledged messages are delivered to another Flow with the redelivered indicator set. In this way, messages can be delivered to clients out of order.

The no version of this command, no access-type, reverts the setting back to the default (exclusive).

For more information about client access type configuration for durable queues, see Configuring Access Types.

Setting Consumer ACK Propagation

Following configurations in the queue template will enable or disable the propagation of consumer acks received on the active Replication Message VPN to the Standby Replication Message VPN:

To prevent the queue from propagating consumer acks to the standby Replication Message VPN, enter the following CONFIG command:

solace(configure/message-spool/queue-template)# no consumer-ack-propagation

If the queue was allowed to propagate consumer acks to the standby Replication Message VPN, enter the following CONFIG command to allow it to do so:

solace(configure/message-spool/queue-template)# consumer-ack-propagation

For more information, see Enabling / Disabling Propagating Consumer Acks to Replicated VPNs.

Setting Queue Event Thresholds

To configure the thresholds that control when message spool-related events are generated for a queue, enter the following CONFIG command:

solace(configure/message-spool/queue-template)# event

The CLI is now at a level from which you can configure the set and clear thresholds for various message spool events using a queue template.

For more information about setting and clearing thresholds for generating those events for a queue using a queue template, see Queue Event Thresholds Using Templates.

Setting Max Number of Flows That May Bind

To configure the maximum number of flows that can bind to a queue, enter the following CONFIG command.

solace(configure/message-spool/queue-template)# max-bind-count <value>

Where:

<value> is the integer value specifying the maximum number of flows that can bind to a durable message queue. The valid range is 0 to 10,000. The default value is 1,000.

The no version of this command, no max-bind-count, resets the maximum number of flows that can bind to a queue template back to the default.

For more information, see Configuring Max Number of Flows That May Bind.

Setting Max Permitted Number of Delivered Unacked Messages

To configure a limit for maximum outstanding number of delivered but unacknowledged messages per flow, enter the following CONFIG command:

solace(configure/message-spool/queue-template)# max-delivered-unacked-msgs-per-flow <max>

Where:

<max> is an integer value specifying the maximum number of messages that can be delivered to a client on a subscriber flow but remain unacknowledged by the client. The valid range is 1 to the maximum value supported by the event broker. The maximum value depends on the type of PubSub+ event broker used. The default value is 10000. If the maximum number of delivered but unacknowledged messages amongst all clients is reached, the event broker will stop delivering messages to all clients until some clients return acknowledgments back to the event broker.

The no version of this command, no max-delivered-unacked-msgs-per-flow, resets the maximum number unacknowledged messages back to the default value.

For more information on max-delivered-unacked-msgs-per-flow, or to review any performance impact that you may want to consider, see Configuring Max Permitted Number of Delivered Unacked Messages.

Setting Max Permitted Message Sizes

To configure the maximum message size for the given durable queue, enter the following CONFIG command.

solace(configure/message-spool/queue-template)# max-message-size <size>

Where:

<size> is an integer value specifying the maximum message size (in bytes) permitted for the queue.

The no version of this command, no max-message-size, resets the permitted message size available for use by the queue back to the default.

Setting Max Redelivery Attempts

To configure the maximum number of times a queue can attempt to redeliver a message to a client, enter the following CONFIG command:

solace(configure/message-spool/queue-template)# max-redelivery <count>

Where:

<count> is the maximum message redelivery attempts possible. The valid range is 0 to 255. 0 means try forever. The default is 0.

The no version of this command, no max-redelivery, resets the max-redelivery value back to the default value.

For more information about max-message-size configuration, see Configuring Max Redelivery Attempts.

Setting a Message Redelivery Delay

To configure a message redelivery delay, enter the following command:

solace(configure/message-spool/queue-template)# redelivery-delay

The CLI is now at a level where you can configure the initial interval, maximum interval, and delay interval multiplier the queue uses when it attempts to redeliver a message to a client following an application-initiated local transaction rollback.

To configure the initial interval, enter the following command:
```
solace(.../message-spool/queue-template/redelivery-delay)# initial-interval <value>
```
Where:

<value> is an integer value specifying the delay between the first two delivery attempts, in milliseconds. The valid range of values is 1 to 3600000. The default is 1000.

The no form of this command, no inital-interval, resets the value to the default.
To configure the maximum interval, enter the following command:
```
solace(.../message-spool/queue-template/redelivery-delay)# max-interval <value>
```
Where:

<value> is an integer value specifying the maximum delay to be used between any two redelivery attempts, in milliseconds. The valid range of values is 1 to 10800000. The default is 64000.

The no form of this command, no max-interval, resets the value to the default.
To configure the delay interval multiplier, enter the following command:
```
solace(.../message-spool/queue-template/redelivery-delay)# multiplier <value>
```
Where:

<value> is a floating point value specifying the amount that each delay interval is multiplied by after each failed delivery attempt. The valid range of values is 1.00 to 5.00. The default is 2.00.

The no form of this command, no multiplier, resets the value to the default.

To enable the message redelivery delay configuration, enter the following command:

solace(.../message-spool/queue-template/redelivery-delay)# no shutdown

To disable the message redelivery delay configuration, enter the following command:

solace(.../message-spool/queue-template/redelivery-delay)# shutdown

For more information about configuring a message redelivery delay, see Configuring a Message Redelivery Delay.

Disabling Message Redelivery

By default, the maximum number of times the queue can attempt to redeliver a message to a client is controlled by the max-redelivery command. For more information, see Setting Max Redelivery Attempts.

You can instead disable this functionality. When message redelivery is disabled, a given message will only be attempted to be delivered from the queue once.

Disabling message redelivery is a Controlled Availability (CA) feature. Please contact Solace to find out if this feature is supported for your use case.

To disable message redelivery attempts, enter the following CONFIG command:

solace(configure/message-spool/queue-template)# no redelivery

To enable message redelivery attempts, enter the following CONFIG command.

solace(configure/message-spool/queue-template)# redelivery

Setting a Delivery Delay

By default, messages published to queues are immediately published to connected consumers. There are many use cases in which published messages must not be delivered to consumers immediately, but delivered only after a fixed delay. One example is a retry mechanism within a payment processing system. After receiving a customer order, you may want to implement a delivery delay to retry credit card transactions when the processing of the transaction fails for any reason. For more information, see Queues and Topic Endpoints.

You can use the delivery-delay option to configure a delivery delay for a queue, such that all messages destined to a queue are not eligible to be delivered for a fixed period of time.

If you are currently using DMQs to implement a delivery delay, contact Solace for guidance on migrating your implementation to use the delivery-delay option instead.

To configure a delivery delay on the queue, enter the following CONFIG command:

solace(configure/message-spool/queue-template)# delivery-delay <delay>

Where:

<delay> is the delay, in seconds, to apply to messages arriving on the queue before the messages are eligible for delivery. The valid range is 0 to 4294967295. The default is 0.

The no version of this command, no delivery-delay, resets the delivery-delay value back to the default.

Setting Max Spool Usage Values

To configure the maximum amount of message spool that the given queue may use, enter the following CONFIG command:

solace(configure/message-spool/queue-template)# max-spool-usage <size>

Where:

<size> is an integer value specifying the maximum amount of message spool disk space permitted for the queue in MB.

The no version of this command, no max-spool-usage, resets the permitted message spool usage quota available for use by the queue back to the default.

For information about configuring max-spool-usage size for queues, see Configuring Max Spool Usage Values.

For information about the default values for this setting, see Maximum Spool Usage.

Setting Permissions for Non-Owner Clients

To configure the permission levels for all clients other than the owner of the given durable queue, enter the following CONFIG command:

Client access to the durable message queue must first be disabled before queue permissions can be configured. For more information, see Enabling / Disabling Client Access to Queues.

solace(configure/message-spool/queue-template)# permission all {no-access | read-only | consume | modify-topic | delete}

Where:

no-access disallows all access.

read-only provides clients with read-only access permission to messages spooled to the queue.

consume provides clients with read-only permission and the ability to delete messages from the queue.

modify-topic provides clients with consume permission and the ability to modify the topic or selector assigned to the queue.

delete provides clients with modify-topic permission and the ability to either delete messages from the queue, or delete the queue altogether. Note that clients cannot delete a queue if it was created using the CLI or SEMP by a management user.

The no version of this command, no permission, resets the permission levels for all clients other than the owner of the queue to none; that is, no access. A client access level of none is the default permission level.

For more information, see Configuring Permissions for Non-Owner Clients.

Setting Rejection of Low-Priority Messages

To enable the reject low‑priority message feature for a for a queue, enter the following CONFIG command:

solace(configure/message-spool/queue-template)# reject-low-priority-msg

The no version of this command, no reject-low-priority-msg, configures the client created queues to not perform reject low‑priority message limit checking on published messages (default configuration).

For more information, see Enabling Rejection of Low-Priority Messages.

Setting Reject Low‑Priority Message Limits

To configure a reject low‑priority message limit for a queue, enter the following CONFIG command:

solace(configure/message-spool/queue-template)# reject-low-priority-msg-limit <limit>

Where:

<limit> is the total number of low- and high‑priority messages spooled. When this value is exceeded, the queue discards any further published low-priority messages but spools published high-priority messages. Valid values are from 0 through 4294967295. If value of 0 is set, the queue only spools high-priority messages are spooled.

Setting Message Discard Handling

To enable the reject-msg-to-sender-on-discard option for a durable queue, enter the following CONFIG command:

solace(configure/message-spool/queue-template)# reject-msg-to-sender-on-discard [including-when-shutdown]

Where:

including-when-shutdown specifies to return Nacks to clients publishing messages topics if the endpoint has a matching subscription but is shutdown. Note that this parameter specifically targets messages published to topics because messages published to a queue are always nacked when reject-msg-to-sender is enabled and the queue is shutdown.

The no version of this command, no reject-msg-to-sender-on-discard, disables the reject-msg-to-sender-on-discard option on a durable queue.

For more information about the conditions that cause ingress messages discards and the impact on transacted sessions, see Configuring Message Discard Handling.

Setting Max Message TTLs

To define a maximum TTL for the endpoint to apply to messages to be spooled, enter the following CONFIG command:

solace(configure/message-spool/queue)# max-ttl <ttl>

Where:

<ttl> is maximum number of seconds that messages can stay on a queue that has the Respect TTL option enabled.

The no version of this command, no max-ttl, sets the default Max TTL value to 0 (Disabled), which means that no expiry time is applied to any received messages spooled to that endpoint.

For more information about the conditions when Max TTL value is applied, TTL & Message VPN bridges, and the impact on performance, see Configuring Max Message TTLs

Setting Respect TTLs

To configure a durable queue to respect message TTLs, enter the following CONFIG command:

solace(configure/message-spool/queue-template)# respect-ttl

The no version of this command, no respect-ttl, configures a durable endpoint to ignore message TTL expiry times (the default configuration).

For more information see Enforcing Whether to Respect TTLs.

Setting Respect Message Priority Values

To configure a durable queue to respect message priority values, enter the following CONFIG command:

solace(configure/message-spool/queue-template)# respect-message-priority

The no version of this command, no respect-message-priority, configures a durable queue to ignore message priority values (the default configuration).

For more information, see Enforcing Whether to Respect Message Priority Values.

Configuring Topic Endpoint Templates

To configure a topic endpoint template in a given Message VPN, enter the following commands:

solace(configure)# message-spool message-vpn <vpn-name>
solace(configure/message-spool)# create topic-endpoint-template <name>
solace(configure/message-spool/topic-endpoint-template)#

Where:

<name> is the topic endpoint template name of up to 255 characters.

The no version of the command, no topic-endpoint-template <name>, deletes the specified topic endpoint template from the Message VPN.

From here, you can now assign custom attributes and parameters to the topic endpoint template that will be copied to any client created topic endpoints. Lets start by setting up a name filter that can be used to match a topic endpoint name with a topic endpoint template.

Setting Name Filters to Match Topic Endpoint Names

Administrators can use name filters to match a topic endpoint name with a topic endpoint template. More precisely, name filter is a wildcard pattern that is used to determine which queues use settings from a given template. Following two types of wildcards are supported: * and >.

Rules governing the use of the wildcards:

* matches zero or more characters but never a slash (/). It can be present only at the end, after a / (as in, animals/domestic/*).
Example: animals/domestic/* matches the topic endpoints animals/domestic/cats and animals/domestic/dogs, but it doesn't match the topic endpoint animals/domestic/dogs/beagles.
> matches anything with identical prefixes to the name-filter, but only when it's placed at the end (as in, animals/domestic/>). It is considered a wildcard only when placed at the end, after a /.
Example: animals/domestic/> matches the topic endpoints animals/domestic/cats, animals/domestic/dogs and animals/domestic/dogs/beagles, but it doesn't match the topic endpoint animals/domestic.

To configure a name-filter that can be used to match a topic endpoint name with a topic endpoint template, enter the following command:

solace(configure/message-spool/topic-endpoint-template)# name-filter <name>

Where:

name is the value to be used for the name-filter.

The no version of the command, no name-filter <name>, returns its value to the default.

When configuring name filters, the best practice is to avoid overlapping name filters. If you do use overlapping filters, the event broker takes the longest non-wildcarded prefix when resolving multiple matches.

Setting Access Types

To configure the client access type for durable topic endpoints, enter the following CONFIG command.

solace(configure/message-spool/topic-endpoint-template)# access-type {exclusive | non-exclusive}

Where:

exclusive specifies that only one client can bind to and be serviced by the topic endpoint; if other consumers attempt to bind, they will be rejected.

non-exclusive specifies that all bound flows are able to receive messages, and when multiple flows are bound to a non‑exclusive topic endpoint, they receive messages in a round-robin fashion.

The no version of this command, no access-type, reverts the setting back to the default (exclusive).

For more information about client access type configuration for durable queues, see Configuring Access Types.

Setting Consumer Acknowledgment (ACKs)

By default, endpoints on an active replication Message VPN propagate consumer acks that they received to the standby replication Message VPN.

To prevent a client created topic endpoint from propagating consumer acks to the standby replication Message VPN, enter the following CONFIG command:

solace(configure/message-spool/topic-endpoint-template)# no consumer-ack-propagation

To allow topic endpoint to propagate consumer acks to the standby replication Message VPN, enter the following CONFIG command to allow it to do so:

solace(configure/message-spool/topic-endpoint-template)# consumer-ack-propagation

Setting Topic Endpoint Event Thresholds

To configure the thresholds that control when message spool-related events are generated for a given topic endpoint, enter the following CONFIG command:

solace(configure/message-spool/topic-endpoint-template)# event

The CLI is now at a level at which you can configure the set and clear thresholds for various message spool events for a given topic endpoint template.

For information on the available Message VPN-level message spool events that are generated for a topic endpoint template and how to set and clear thresholds for generating those events, refer to Topic Endpoint Event Thresholds Using Templates.

Setting Max Number of Flows That May Bind

To configure the maximum number of flows that can bind to a non-exclusive durable topic endpoint, enter the following CONFIG command:

solace(configure/message-spool/topic-endpoint-template)# max-bind-count <value>

Where:

<value> is an integer value specifying the maximum number of flows that can bind to a non-exclusive durable topic endpoint. If the topic endpoint's access type has been set to exclusive, the value of max-bind-count is considered to be 1 regardless of the set value. The valid range is 0 to 10,000. The default value is 1.

The no version of this command, no max-bind-count, resets the maximum number of flows that can bind to a durable topic endpoint back to the default.

For more additional information, see Configuring Max Number of Flows That May Bind.

Setting Max Permitted Number of Delivered Unacked Messages

To configure a limit for maximum outstanding number of delivered but unacknowledged messages per flow, enter the following CONFIG command:

solace(configure/message-spool/topic-endpoint-template)# max-delivered-unacked-msgs-per-flow <max>

Where:

<max> is an integer value specifying the maximum number of messages that can be delivered to a client on a subscriber flow but remain unacknowledged by the client. The valid range is 1 to the maximum value supported by the event broker. The maximum value depends on the type of event broker used. The default value is 10000. If the maximum number of delivered but unacknowledged messages amongst all clients is reached, the PubSub+ event broker will stop delivering messages to all clients until some clients return acknowledgments back to the event broker.

The no version of this command, no max-delivered-unacked-msgs-per-flow, resets the maximum number unacknowledged messages back to the default value.

For more information about max-delivered-unacked-msgs-per-flow, or to review any performance impact that you may want to consider, see Configuring Max Number of Delivered Unacked Messages .

Setting Max Permitted Message Sizes

To configure the maximum message size for a given topic endpoint, enter the following CONFIG command.

solace(configure/message-spool/topic-endpoint-template)# max-message-size <size>

Where:

<size> is an integer value specifying the maximum message size (in bytes) permitted for the topic endpoint. The valid range is 0 to 30000000. The default value is 10000000.

The no version of this command, no max-message-size, resets the permitted message size available for use by the topic endpoint back to its default value.

Setting Max Redelivery Attempts

To configure the maximum number of times a topic endpoint can attempt to redeliver a message to a client, enter the following CONFIG command:

solace(configure/message-spool/topic-endpoint-template)# max-redelivery <count>

Where:

<count> is the maximum message redelivery attempts possible. The valid range is 0 to 255. 0 means try forever. The default is 0.

The no version of this command, no max-redelivery, resets the max-redelivery value back to the default value.

For more information on max-message-size configuration, refer to Configuring Max Permitted Redelivery Attempts.

Setting a Message Redelivery Delay

To configure a message redelivery delay, enter the following command:

solace(configure/message-spool/topic-endpoint-template)# redelivery-delay

The CLI is now at a level where you can configure the initial interval, maximum interval, and delay interval multiplier the topic endpoint uses when it attempts to redeliver a message to a client following an application-initiated local transaction rollback.

To configure the initial interval, enter the following command:
```
solace(.../message-spool/topic-endpoint-template/redelivery-delay)# initial-interval <value>
```
Where:

<value> is an integer value specifying the delay between the first two delivery attempts, in milliseconds. The valid range of values is 1 to 3600000. The default is 1000.

The no form of this command, no inital-interval, resets the value to the default.
To configure the maximum interval, enter the following command:
```
solace(.../message-spool/topic-endpoint-template/redelivery-delay)# max-interval <value>
```
Where:

<value> is an integer value specifying the maximum delay to be used between any two redelivery attempts, in milliseconds. The valid range of values is 1 to 10800000. The default is 64000.

The no form of this command, no max-interval, resets the value to the default.
To configure the delay interval multiplier, enter the following command:
```
solace(.../message-spool/topic-endpoint-template/redelivery-delay)# multiplier <value>
```
Where:

<value> is a floating point value specifying the amount that each delay interval is multiplied by after each failed delivery attempt. The valid range of values is 1.00 to 5.00. The default is 2.00.

The no form of this command, no multiplier, resets the value to the default.

To enable the message redelivery delay configuration, enter the following command:

solace(.../message-spool/topic-endpoint-template/redelivery-delay)# no shutdown

To disable the message redelivery delay configuration, enter the following command:

solace(.../message-spool/topic-endpoint-template/redelivery-delay)# shutdown

For more information, see Configuring a Message Redelivery Delay.

Disabling Message Redelivery

By default, the maximum number of times the topic endpoint can attempt to redeliver a message to a client is controlled by the max-redelivery command. For more information, see Setting Max Redelivery Attempts.

You can instead disable this functionality. When message redelivery is disabled, a given message will only be attempted to be delivered from the topic endpoint once.

Disabling message redelivery is a Controlled Availability (CA) feature. Please contact Solace to find out if this feature is supported for your use case.

To disable message redelivery attempts, enter the following CONFIG command:

solace(configure/message-spool/topic-endpoint-template)# no redelivery

To enable message redelivery attempts, enter the following CONFIG command.

solace(configure/message-spool/topic-endpoint-template)# redelivery

Setting a Delivery Delay

By default, messages published to topic endpoints are immediately published to connected consumers. There are many use cases in which published messages must not be delivered to consumers immediately, but delivered only after a fixed delay. One example is a retry mechanism within a payment processing system. After receiving a customer order, you may want to implement a delivery delay to retry credit card transactions when the processing of the transaction fails for any reason. For more information,see Queues and Topic Endpoints.

You can use the delivery-delay option to configure a delivery delay for a topic endpoint, such that all messages destined to a topic endpoint are not eligible to be delivered for a fixed period of time.

If you are currently using DMQs to implement a delivery delay, contact Solace for guidance on migrating your implementation to use the delivery-delay option instead.

To configure a delivery delay on the topic endpoint, enter the following CONFIG command:

solace(configure/message-spool/topic-endpoint-template)# delivery-delay <delay>

Where:

<delay> is the delay, in seconds, to apply to messages arriving on the topic endpoint before the messages are eligible for delivery. The valid range is 0 to 4294967295. The default is 0.

The no version of this command, no delivery-delay, resets the delivery-delay value back to the default.

Setting Max Spool Usage Values

To configure the maximum message spool usage for durable topic endpoints on the PubSub+ event broker on a per-topic endpoint basis, enter the following CONFIG command:

solace(configure/message-spool/topic-endpoint-template)# max-spool-usage <size>

Where:

<size> is an integer value specifying the maximum amount of message spool disk space permitted for the topic endpoint in MB.Setting the value to 0 is not recommended for topic endpoints.

The no version of this command, no max-spool-usage, resets the default.

For information about configuring max-spool-usage size for topic endpoints, see Configuring Max Spool Usage Values.

For information about the default values for this setting, see Maximum Spool Usage.

Setting Permissions for Non-Owner Clients

To configure the permission levels for all clients other than the owner of the given durable topic endpoints, enter the following CONFIG command:

solace(configure/message-spool/topic-endpoint-template)# permission all {no-access | read-only | consume | modify-topic | delete}

Where:

no-access disallows all access.

read-only provides clients with read-only access permission to messages spooled to the topic endpoint

consume provides clients with read-only permission and the ability to delete messages from the topic endpoint

modify-topic provides clients with consume permission and the ability to modify the topic or selector assigned to the topic endpoint

delete provides clients with modify-topic permission and the ability to either delete messages from the topic endpoint, or delete the topic endpoint altogether. Note that clients cannot delete a topic endpoint if it was created using the CLI or SEMP by a management user.

The no version of this command, no permission, resets the permission levels for all clients other than the owner of the topic endpoint to none; that is, no access. A client access level of none is the default permission level.

For more information, see Configuring Permissions for Non-Owner Clients.

Setting Reject Low‑Priority Message Limits

To configure a reject-low-priority-msg-limit for a topic endpoint, enter the following CONFIG command:

solace(configure/message-spool/topic-endpoint-template)# reject-low-priority-msg-limit <limit>

Where:

<limit> is the total number of low- and high‑priority messages spooled. When this value is exceed, the topic endpoint discards any further published low-priority messages, but spools published high-priority messages. Valid values are from 0 through 4294967295. If value of 0 is set, the topic endpoint only spools high-priority messages are spooled. The default value is 0.

Setting Rejection of Low-Priority Messages

To enable the reject low‑priority message feature for a topic endpoint, enter the following CONFIG command:

solace(configure/message-spool/topic-endpoint-template)# reject-low-priority-msg

The no version of this command, no reject-low-priority-msg, configures the durable topic endpoint to not perform reject low‑priority message limit checking on published messages (the default configuration).

For more information, see Enabling Rejection of Low‑Priority Messages.

Setting Max Message TTLs

To define a maximum TTL for the topic endpoint to apply to messages to be spooled, enter the following CONFIG command:

solace(configure/message-spool/topic-endpoint-template)# max-ttl <ttl>

Where:

<ttl> is maximum number of seconds that messages can stay on the topic endpoint when it has respect-ttl enabled.

The no version of this command, no max-ttl, sets the default Max TTL value 0 (disabled), which means that no expiry time is applied to any received messages spooled to that endpoint.

For more information, see Configuring Max Message TTLs

Setting Message Discard Handling

To enable the reject-msg-to-sender-on-discard option for a durable topic endpoint, enter the following CONFIG command:

solace(configure/message-spool/topic-endpoint-template)# reject-msg-to-sender-on-discard

The no version of this command, no reject-msg-to-sender-on-discard, disables the reject-msg-to-sender-on-discard option on a durable topic endpoint.

For more information about the conditions that cause ingress messages discards and the impact on transacted sessions, see Configuring Message Discard Handling.

Setting Respect TTLs

To configure a topic endpoint to respect message TTLs, enter the following CONFIG command:

solace(configure/message-spool/topic-endpoint-template)# respect-ttl

The no version of this command, no respect-ttl, configures a durable topic endpoint to ignore message TTL expiry times (the default configuration).

For more information, see Enforcing Whether to Respect Message TTLs.

Setting Respect Message Priority Values

To configure a topic endpoint to respect message priority values, enter the following CONFIG command:

solace(configure/message-spool/topic-endpoint-template)# respect-message-priority

The no version of this command, no respect-message-priority, configures a durable topic endpoint to ignore message priority values (the default configuration).

For more information, see Enforcing Whether to Respect Message Priority Values.

Provide feedback