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.
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.
Property | Description |
---|---|
(included in default configuration) |
Specifies how messages are delivered when multiple consumer flows are bound to the queue. The default value is
|
|
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 |
|
Specifies the name of the dead message queue (DMQ) used by this queue. The default is A DMQ collects undelivered messages that would otherwise be discarded from the queue because the Maximum TTL or Maximum Redelivery Count has been reached. |
|
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 |
|
Specifies the delay, in seconds, to apply to messages arriving on the queue before the messages are eligible for delivery. The default value is |
|
Specifies event bind count thresholds for the queue:
|
|
Specifies message spool usage thresholds for the queue:
|
|
Specifies message spool usage thresholds for the queue:
|
|
Specifies the maximum number of consumer flows that can bind to the queue. The default value is |
|
Specifies the maximum number of messages delivered but not acknowledged per flow for the queue. The default value is |
|
Specifies he maximum message size allowed in the queue, in bytes. The default value is |
(included in default configuration) |
Specifies the maximum message spool usage allowed by the queue, in megabytes. A value of |
|
Specifies the maximum number of times the queue will attempt redelivery of a message prior to it being discarded or moved to the DMQ. |
|
Specifies the maximum time, in seconds, a message can stay in the queue when |
|
Specifies the name of the Message VPN hosting the queue. |
|
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. |
|
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 |
|
Specifies the delay, in seconds, before a partition rebalance is started once needed. The default value is |
|
Specifies the maximum time, in seconds to wait before handing off a partition while rebalancing. The default value is |
|
Specifies the access level given to client applications other than the queue owner. The default value is
|
(included in default configuration) |
Specifies the name of the queue. |
|
Enables or disables a message redelivery delay. When |
|
Specifies the delay to be used between the first two redelivery attempts, in milliseconds. The default value is |
|
Specifies the maximum delay to be used between any two redelivery attempts, in milliseconds. The default value is |
|
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 |
|
Enables or disables message redelivery. When enabled, the number of redelivery attempts is controlled by |
|
Enables or disables the checking of low priority messages against the |
|
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 |
|
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
|
|
Enables or disables the respecting of message priority. When enabled, messages contained in the queue are delivered in priority order. The default value is |
|
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 |
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 exampleMyQueue_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
totrue
.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
totrue
.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 thedeadMsgQueue
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.