Setting Queue Configurations in Event Portal

You can add queue configuration details for Solace event brokers in Event Portal.

This page includes the following information:

Linking Event Brokers to Applications in Event Portal
Setting Queue Configurations in Event Portal
Adding an Event Queue to an Application in Designer

Linking Event Brokers to Applications in Event Portal

In Event Portal, an application represents an actual client application that publishes or receives event messages. A consumer within an application in Event Portal represents a queue on an operational event broker in the runtime. A topic subscription in the consumer is analogous to a queue subscribing to a topic on the event broker.

Diagram showing the concepts described in the surrounding text.

Adding an Event Queue to an Application in Designer

To add a Solace event queue to an application in Designer, perform these steps:

On the Application Domains page, click the application domain that contains the application you want to update.
Right-click the application in the graph view and select View Details.
Click Open Application.
In the Versions list, click More Actions next to the version that you want to add queue configuration to, then select Edit. If the application doesn’t have a version in Draft state, create a new version.
In the Event Flows section, select Consumers.
Click Add Consumer.
Type a Name for the consumer. The value in the Name field is used as the default value for the "queueName" in the configuration details.
In the Type list, select Solace Event Queue.
Click Set Configuration.
Enter Configuration details for the queue. For more information about the available configuration settings, see Queue Configuration Attributes. To view or copy a sample configuration, see Queue Configuration Example.
The default values represent the default values of the required settings for a queue on an event broker service. Event Portal validates that the configuration is in proper JSON format.
If the queue you are specifying already exists on the event broker service, the "queueName" in the consumer and on the event broker service must match. Otherwise, sending the configuration details to the event broker service creates a new queue.
Click Add Subscription to add a topic subscription to the consumer.
Enter a topic subscription for the consumer to subscribe to. You can use * and > as wildcard characters to subscribe to a group of related topics. For more information, see Topic Subscriptions. When you enter a topic subscription, a Preview of Attracted Events shows all event versions with a matching topic address in Designer that are published by an application version that has been added to at least one modeled event mesh.
Click Save Version.

Queue Configuration Attributes

The JSON queue configuration for the consumer can include the following attributes. Some of these attributes are not supported by earlier event broker versions. For more information, see SEMP API queue parameters.

Property	Description
`accessType` (included in default configuration)	Specifies how messages are delivered when multiple consumer flows are bound to the queue. The default value is `exclusive`. `Exclusive` specifies that only one consumer can receive a message at any one time, while additional consumers may be connected as standby. Only the first consumer to bind can receive messages. If the first consumer disconnects, the second consumer receives data, and so on. Exclusive queues always deliver messages in the order they are received. `Non-Exclusive` specifies that multiple consumers can bind to the queue, which enables load balancing and consumer auto-scaling. A non-exclusive queue can be non-partitioned or partitioned. For a non-partitioned queue (`partitionCount` is `0`), each consumer is serviced in a round-robin fashion. If a connection fails, unacknowledged messages are delivered to another consumer with the re-delivered flag set. In this way, messages can be delivered to consumers out of order. For a partitioned queue (`partitionCount` is greater than `0`), each consumer is delivered messages from one or more partitions. Messages are mapped to partitions based on a hash of the partition key, which is set by the publishing application. Message order is maintained within a partition, but not between partitions.
`consumerAckPropagationEnabled`	Enables or disables the propagation of consumer acknowledgments (ACKs) received on the active replication Message VPN to the standby replication Message VPN. The default value is `true`.
`deadMsgQueue`	Specifies the name of the dead message queue (DMQ) used by this queue. The default is `#DEAD_MSG_QUEUE`. Solace recommends using a separate DMQ for each queue and topic endpoint that requires one and setting the DMQ name to the name of the queue, followed by "_dmq", for example `MyQueue_dmq`. For more information about configuring a DMQ, see Adding a Dead Message Queue to an Application. A DMQ collects undelivered messages that would otherwise be discarded from the queue because the Maximum TTL or Maximum Redelivery Count has been reached.
`deliveryCountEnabled`	Enables or disables the ability for client applications to query the message delivery count of messages received from the queue. This is a controlled availability feature. Please contact support to find out if this feature is supported for your use case. The default value is `false`.
`deliveryDelay`	Specifies the delay, in seconds, to apply to messages arriving on the queue before the messages are eligible for delivery. The default value is `0`.
`eventBindCountThreshold`	Specifies event bind count thresholds for the queue: `clearPercent`—the clear threshold for the value of this counter as a percentage of its maximum value. Falling below this value will trigger a corresponding event `clearValue`—the clear threshold for the absolute value of this counter. Falling below this value will trigger a corresponding event. `setPercent` —the set threshold for the value of this counter as a percentage of its maximum value. Exceeding this value will trigger a corresponding event. `setValue`—the set threshold for the absolute value of this counter. Exceeding this value will trigger a corresponding event.
`eventMsgSpoolUsageThreshold`	Specifies message spool usage thresholds for the queue: `clearPercent`—the clear threshold for the value of this counter as a percentage of its maximum value. Falling below this value will trigger a corresponding event `clearValue`—the clear threshold for the absolute value of this counter. Falling below this value will trigger a corresponding event. `setPercent` —the set threshold for the value of this counter as a percentage of its maximum value. Exceeding this value will trigger a corresponding event. `setValue`—the set threshold for the absolute value of this counter. Exceeding this value will trigger a corresponding event.
`eventRejectLowPriorityMsgLimitThreshold`	Specifies message spool usage thresholds for the queue: `clearPercent`—the clear threshold for the value of this counter as a percentage of its maximum value. Falling below this value will trigger a corresponding event `clearValue`—the clear threshold for the absolute value of this counter. Falling below this value will trigger a corresponding event. `setPercent` —the set threshold for the value of this counter as a percentage of its maximum value. Exceeding this value will trigger a corresponding event. `setValue`—the set threshold for the absolute value of this counter. Exceeding this value will trigger a corresponding event.
`maxBindCount`	Specifies the maximum number of consumer flows that can bind to the queue. The default value is `1000`.
`maxDeliveredUnackedMsgsPerFlow`	Specifies the maximum number of messages delivered but not acknowledged per flow for the queue. The default value is `10000`.
`maxMsgSize`	Specifies he maximum message size allowed in the queue, in bytes. The default value is `10000000`.
`maxMsgSpoolUsage` (included in default configuration)	Specifies the maximum message spool usage allowed by the queue, in megabytes. A value of `0` only allows spooling of the last message received and disables quota checking. The default value is `5000`.
`maxRedeliveryCount`	Specifies the maximum number of times the queue will attempt redelivery of a message prior to it being discarded or moved to the DMQ. `redeliveryEnabled` A value of `0` means to retry forever. The default value is `0`.
`maxTtl`	Specifies the maximum time, in seconds, a message can stay in the queue when `respectTtlEnabled` is `true`. A message expires when the lesser of the sender-assigned time-to-live (TTL) in the message and the `maxTtl` configured for the queue, is exceeded. Expired messages are discarded or moved to a DMQ. A value of `0` disables expiry. The default value is `0`.
`msgVpnName`	Specifies the name of the Message VPN hosting the queue.
`owner`	Specifies the client username that owns the queue. By default, users with access to PubSub+ Broker Manager have ownership privileges. Use this parameter to give ownership to the client application.The queue owner has full unlimited permissions for the queue. The owner can consume, delete, or modify topics in the queue.
`partitionCount`	Specifies the count of partitions of the queue. This setting is only relevant for queues with an access type of non-exclusive. When set to `0`, bound clients receive messages in a round-robin fashion. Otherwise, bound clients receive messages from individually assigned partitions. The default value is `0`.
`partitionRebalanceDelay`	Specifies the delay, in seconds, before a partition rebalance is started once needed. The default value is `5`.
`partitionRebalanceMaxHandoffTime`	Specifies the maximum time, in seconds to wait before handing off a partition while rebalancing. The default value is `3`.
`permission`	Specifies the access level given to client applications other than the queue owner. The default value is `consume`. Possible values are: `no-access`—Disallows all access. `read-only`—Clients have read-only access to messages spooled to the queue. `consume`—Clients can consume and delete messages from the queue. `modify-topic`—Clients can consume and delete messages and modify the topic or selector assigned to the queue. `delete`—Clients can consume and delete messages, modify the topic or selector assigned to the queue, and delete the queue.
`queueName` (included in default configuration)	Specifies the name of the queue.
`redeliveryDelayEnabled`	Enables or disables a message redelivery delay. When `false`, messages are redelivered as soon as possible. When `true`, messages are redelivered according to the initial, max, and multiplier. The default value is `false`.
`redeliveryDelayInitialInterval`	Specifies the delay to be used between the first two redelivery attempts, in milliseconds. The default value is `1000`.
`redeliveryDelayMaxInterval`	Specifies the maximum delay to be used between any two redelivery attempts, in milliseconds. The default value is `64000`.
`redeliveryDelayMultiplier`	Specifies the amount each delay interval is multiplied by after each failed delivery attempt. This number is in a fixed-point decimal format in which you must divide by 100 to get the floating point value. For example, a value of `125` would cause the delay to be multiplied by 1.25. The default value is `200`.
`redeliveryEnabled`	Enables or disables message redelivery. When enabled, the number of redelivery attempts is controlled by `maxRedeliveryCount` and undelivered messages are discarded or moved to the DMQ after the specified number of attempts is reached. When disabled, the queue never attempts message delivery more than once. The default value is `true`.
`rejectLowPriorityMsgEnabled`	Enables or disables the checking of low priority messages against the `rejectLowPriorityMsgLimit`. This can be enabled only if `rejectMsgToSenderOnDiscardBehavior` does not have a value of `never`. The default value is `false`.
`rejectLowPriorityMsgLimit`	Specifies the number of messages of any priority in the queue above which low priority messages are not admitted but higher priority messages are allowed. The default value is `0`.
`rejectMsgToSenderOnDiscardBehavior`	Specifies when to return negative acknowledgments (NACKs) to sending clients on message discards. Note that NACKs cause the message to not be delivered to any destination and Transacted Session commits to fail. The default value is `when-queue-enabled`. Possible values are: `never`—Silently discard messages `when-queue-enabled`—NACK each message discard back to the client, except messages that are discarded because an endpoint is administratively disabled `always`—NACK each message discard back to the client, including messages that are discarded because an endpoint is administratively disabled
`respectMsgPriorityEnabled`	Enables or disables the respecting of message priority. When enabled, messages contained in the queue are delivered in priority order. The default value is `false`.
`respectTtlEnabled`	Enables or disables the respecting of the time-to-live (TTL) for messages in the queue. When enabled, expired messages are discarded or moved to the DMQ. The default value is `false`.

Queue Configuration Example

The following JSON queue configuration example represents a queue on the event broker named samplequeue with default values for all parameters.

{
	"queueName" : "samplequeue",
	"accessType" : "exclusive",
	"consumerAckPropagationEnabled" : true,
	"deadMsgQueue" : "#DEAD_MSG_QUEUE",
	"deliveryCountEnabled" : false,
	"deliveryDelay" : 0,
	"eventBindCountThreshold": {
		"clearPercent": 60,	
		"setPercent": 80
	},
	"eventMsgSpoolUsageThreshold": {
		"clearPercent": 18,
		"setPercent": 25
	},
	"eventRejectLowPriorityMsgLimitThreshold": {
		"clearPercent": 60,
		"setPercent": 80
	},
	"maxBindCount": 1000,
	"maxDeliveredUnackedMsgsPerFlow": 10000,
	"maxMsgSize": 10000000,
	"maxMsgSpoolUsage": 5000,
	"maxRedeliveryCount": 0,
	"maxTtl": 0,
	"partitionCount": 0,
	"partitionRebalanceDelay": 5,
	"partitionRebalanceMaxHandoffTime": 3,
	"redeliveryDelayEnabled": false,
	"redeliveryDelayInitialInterval": 1000,
	"redeliveryDelayMaxInterval": 64000,
	"redeliveryDelayMultiplier": 200,
	"redeliveryEnabled": true,
	"rejectLowPriorityMsgEnabled": false,
	"rejectLowPriorityMsgLimit": 0,
	"rejectMsgToSenderOnDiscardBehavior": "when-queue-enabled",
	"respectMsgPriorityEnabled": false,
	"respectTtlEnabled": false
}

Adding a Dead Message Queue to an Application

You can configure a dead message queue (DMQ) to receive messages that are discarded from a queue when they can't be delivered to the subscribing client. By default, messages are discarded from a queue in the following circumstances:

the maximum time-to-live (TTL) value for the message has been reached and the queue is configured to respect message TTL expiry times.
the number of redelivery attempts to the consumer for a message has reached the max redelivery count value for the original endpoint.

You can configure a Solace event queue in Designer to act as a DMQ for another Solace event queue by setting the appropriate attribute values for both queues.

To configure a DMQ for another Solace event queue, perform these steps:

Configure a Solace event queue according to the instructions for Adding an Event Queue to an Application in Designer.

In the configuration for your queue, set the following values:

Attribute	Description
`deadMsgQueue`	Specify the `queueName` for the DMQ to send expired messages to. Solace recommends using a separate DMQ for each queue that requires one and setting the DMQ name to the name of the queue, followed by "_dmq", for example `MyQueue_dmq`.
`maxRedeliveryCount`	Set this value if you want to specify the maximum number of times the queue attempts to deliver the message before the message expires. If you want to specify the maximum redelivery count, you must also set `redeliveryEnabled` to `true`.
`maxTtl`	Set this value if you want to specify the TTL in seconds that the queue applies to messages when the message arrives in the queue. If you specify the maximum TTL, you must also set `respectTtlEnabled` to `true`.
`respectTtlEnabled`	Set this value if you want messages that have not been delivered to expire at the end of the message TTL. If a message is not consumed and its TTL time is reached, the message is discarded or moved to a DMQ.

Configure a second Solace event queue to act as the DMQ for the first queue and set the queueName to match the deadMsgQueue value you set for the first queue.

The DMQ does not need to subscribe to events. It receives only the expired messages from the first queue.

For instructions to configure DMQs in Mission Control, see Configuring Dead Message Queues.

Provide feedback