Managing Client Profiles with the PubSub+ Cloud REST API

Many of the procedures on this page can be performed using our feature-rich and consistent v2 REST API instead of the v0 APIs. For more information, see the PubSub+ v2 REST API Reference.

In PubSub+ Cloud, the REST APIs and API tokens allow you to create, update, and delete client profiles programmatically. For more information about client profiles, see Using Client Profiles and Client Usernames.

This tutorial shows you how to:

Before you Begin

Before you can start this tutorial, you'll require:

  • An account with PubSub+ Cloud and an event broker service.
  • Your account must be assigned the Administrator or Cluster Manager Editor role. The account is required more to validate your results in the PubSub+ Cloud Console and to create an API token; if you have an API token created, you can perform all the steps in this tutorial.
  • An API token must be available in the account with at least the following permissions:
    • Either Get My Services with Management Credentials (From Mission Control) or Get Services with Management Credentials from (Organization Services). Both are recommended for this tutorial.
    • From Organization Services:
      • Get Service Requests
      • Create / Update / Delete / Client Profiles

    For more information, see Creating an API Token.

  • A way to send REST messages from your development environment. We use Postman in this tutorial. You can use the Solace Blogs – Solace Cloud Client Profile Management Postman collection and click the Run in Postman button to import the collection to Postman, which permits you to easily work through the steps in this tutorial. Alternatively, you can simply make each call by specifying it REST API in Postman after you've set up the environment in Postman to use your API token. For more information about setting up Postman, see Managing API Tokens.

    At this time, the documentation on the Solace Blogs about the REST API for PubSub+ Cloud may be out of date. Refer to the documentation on this website for instructions about using the PubSub+ Cloud REST API.

    After you've set up the environment in Postman to use your API token, you can simply make each call by specifying the REST API. To check that API token is set up correctly to use Bearer authorization in Postman, select the Headers tab to validate that it is using Bearer Authorization and set it to use the apiToken environment variable that you had set up earlier. For example, you can see that Authorization is set up to use Bearer and the apiToken in the following illustration:

Creating a Client Profile

You can perform this procedure using our feature rich and consistent v2 REST API. See the Create a Client Profile v2 REST API in Solace's REST API Reference for more information.

After you have your API Token configured for use with Postman, you can use the PubSub+ Cloud REST API to create a client profile. To create a client profile, follow these steps:

  1. In the Postman Collection Solace Blogs - Solace Cloud Client Profile Management, select the request Create a Client Profile. The POST request would be to the URL, https://api.solace.cloud/api/v0/services/{serviceId}/requests/clientProfileRequests.

  2. In the POST request URL, replace the {serviceId} variable with the identifier of the service for which you want to create a client profile. In the body of the request, use the clientProfileName property to specify the name of your client profile and set the operationproperty to create. The other properties can be changed to fit your needs to configure the client profile. For more information about each setting, see Client Profile Settings for the PubSub+ Cloud REST API. Depending on the version of the Postman Collection Solace Blogs - Solace Cloud Client Profile Management, some properties are not listed in the default body request such as:

    • allowSharedSubscriptionsEnabled
    • elidingEnabled
    • rejectMsgToSenderOnNoSubscriptionMatchEnabled
    • serviceMinKeepaliveTimeout
    • serviceSmfMinKeepaliveEnabled

    Here's what your body for the POST request may look like if you specify all the client profile properties:

    {
  "operation": "create",
  "clientProfile": {
  "clientProfileName": "myClientProfile",
  "allowGuaranteedMsgSendEnabled": "true",
  "allowGuaranteedMsgReceiveEnabled": "true",
  "allowUseCompression": "true",
  "replicationAllowClientConnectWhenStandbyEnabled": "true",
  "allowTransactedSessionsEnabled": "true",
  "allowBridgeConnectionsEnabled": "true",
  "allowGuaranteedEndpointCreateEnabled": "true",
  "allowSharedSubscriptionsEnabled": "true",
  "apiQueueManagementCopyFromOnCreateName": "",
  "apiQueueManagementCopyFromOnCreateTemplateName": "",					
  "apiTopicEndpointManagementCopyFromOnCreateName": "",
  "apiTopicEndpointManagementCopyFromOnCreateTemplateName": "",
  "serviceMinKeepaliveTimeout": "30",
  "serviceSmfMinKeepaliveEnabled": "false",
  "serviceWebInactiveTimeout": "30",
  "serviceWebMaxPayload": "1000000",
  "maxConnectionCountPerClientUsername": "100",
  "serviceSmfMaxConnectionCountPerClientUsername": "1000",
  "serviceWebMaxConnectionCountPerClientUsername": "1000",
  "maxEndpointCountPerClientUsername": "100",
  "maxEgressFlowCount": "100",
  "maxIngressFlowCount": "100",
  "maxSubscriptionCount": "1000",
  "maxTransactedSessionCount": "100",
  "maxTransactionCount": "500",
  "queueGuaranteed1MaxDepth": "20000",
  "queueGuaranteed1MinMsgBurst": 66000,
  "queueDirect1MaxDepth": "20000",
  "queueDirect1MinMsgBurst": "4",
  "queueDirect2MaxDepth": "20000",
  "queueDirect2MinMsgBurst": "4",
  "queueDirect3MaxDepth": "20000",
  "queueDirect3MinMsgBurst": "4",
  "queueControl1MaxDepth": "20000",
  "queueControl1MinMsgBurst": "6",
  "tcpCongestionWindowSize": "2",
  "tcpKeepaliveCount": "5",
  "tcpKeepaliveIdleTime": "3",
  "tcpKeepaliveInterval": "1",
  "tcpMaxSegmentSize": "1460",
  "tcpMaxWindowSize": "256",
  "elidingDelay": "0",
  "elidingEnabled": "false",
  "elidingMaxTopicCount": "256",
  "rejectMsgToSenderOnNoSubscriptionMatchEnabled": "false",
  "tlsAllowDowngradeToPlainTextEnabled": "true",
  "eventClientProvisionedEndpointSpoolUsageThreshold": {
     "setPercent": "80",
     "clearPercent": "60"
    }
  }
}

    Note that if you don't specify a client profile property in the body, a default value is used for that property. For the list of properties that you can configure and their defaults, see Client Profile Settings for the PubSub+ Cloud REST API.

  3. Click Send.

    You should see a 202 response confirming that the request was accepted.

  4. You can check the status of the request, use the GET Service Request method in the Postman collection using the id from the response. For more information, see Getting the Status of a POST command.

Now that we have confirmed that our request is marked completed, we can retrieve the client profile we just created using the API.

Getting the Status of a POST command

Because the Create Client Profile command is a POST command, you can use the PubSub+ Cloud REST API to get the status. To check the status of the POST request , you need the id from the response. For example, after of calling the Update a Client Profile method, you may see the following response:

  1. In the Postman Collection Solace Blogs - Solace Cloud Client Profile Management, select the request Get Service Request. The GET URL is https://api.solace.cloud/api/v0/services/{serviceId}/requests/{requestId}.
  2. In the GET URL, replace the {serviceId} variable with the identifier of the service you want to get the client profile information from and replace the {requestId}with the value of id from the running the POST  request.
  3. Click Send.

     

    You should see a JSON response confirming that the request was accepted with the response that indicates the status of the request marked completed.

Getting the Details of a Client Profile

You can perform this procedure using our feature rich and consistent v2 REST API. See the Get a specific client profile for event broker service by name v2 REST API in Solace's REST API Reference for more information.

After you have created a profile, you can PubSub+ Cloud REST API to retrieve the client profile details. To get client profile details, follow these steps:

  1. In the Solace Blogs - Solace Cloud Client Profile Management Postman Collection, select the Get Client Profile request. The GET request would be to the URL, https://api.solace.cloud/api/v0/services/{serviceId}/clientProfiles/{clientProfileName}.
  2. In the GET URL, replace the {serviceId} variable with the identifier of the service you want to get the client profile information from and replace the {clientProfileName}with the value of name of the profile you want to get information about.
  3. Click Send.

    You should see the details of the client profile you specified in the bottom panel.

Updating a Client Profile

You can perform this procedure using our feature rich and consistent v2 REST API. See the Update a client profile v2 REST API in Solace's REST API Reference for more information.

You can use the PubSub+ Cloud REST API to update an existing client profile and change some of its properties.

  1. In the Solace Blogs - Solace Cloud Client Profile Management Postman Collection, select the Update a Client Profile request. The POST request would be to the URL, https://api.solace.cloud/api/v0/services/{serviceId}/requests/clientProfileRequests.
  2. In the POST URL, replace the {serviceId} variable with the identifier of the service that the client profile exists in.

    You can include any properties you want to change in the body of the request. Properties that are not included will be left unchanged. You can see a list of client profile properties in Client Profile Settings for the PubSub+ Cloud REST API. You can retrieve a list of client profile properties for your event broker service by performing a GET, see Getting the Details of a Client Profile.

    If you are using the Postman Collection Solace Blogs - Solace Cloud Client Profile Management example, you must change the following client profile properties as listed:

    • clientProfileName: Set to the name of the client profile you want to update.
    • allowGuaranteedMsgSendEnabled: Set to false.
    • allowGuarenteedMsgReceiveEnabled: Set to false.

    Depending on the version of the Postman Collection Solace Blogs - Solace Cloud Client Profile Management, some properties are not listed in the example body request such as:

    • allowSharedSubscriptionsEnabled
    • elidingEnabled
    • rejectMsgToSenderOnNoSubscriptionMatchEnabled
    • serviceMinKeepaliveTimeout
    • serviceSmfMinKeepaliveEnabled

    {
  "operation": "update",
  "clientProfile": {
  "clientProfileName": "myClientProfile",
  "allowGuaranteedMsgSendEnabled": "true",
  "allowGuaranteedMsgReceiveEnabled": "true",
  "allowUseCompression": "true",
  "replicationAllowClientConnectWhenStandbyEnabled": "true",
  "allowTransactedSessionsEnabled": "true",
  "allowBridgeConnectionsEnabled": "true",
  "allowGuaranteedEndpointCreateEnabled": "true",
  "allowSharedSubscriptionsEnabled": "true",
  "apiQueueManagementCopyFromOnCreateName": "",
  "apiQueueManagementCopyFromOnCreateTemplateName": "",					
  "apiTopicEndpointManagementCopyFromOnCreateName": "",
  "apiTopicEndpointManagementCopyFromOnCreateTemplateName": "",
  "serviceMinKeepaliveTimeout": "30",
  "serviceSmfMinKeepaliveEnabled": "false",
  "serviceWebInactiveTimeout": "30",
  "serviceWebMaxPayload": "1000000",
  "maxConnectionCountPerClientUsername": "100",
  "serviceSmfMaxConnectionCountPerClientUsername": "1000",
  "serviceWebMaxConnectionCountPerClientUsername": "1000",
  "maxEndpointCountPerClientUsername": "100",
  "maxEgressFlowCount": "100",
  "maxIngressFlowCount": "100",
  "maxSubscriptionCount": "1000",
  "maxTransactedSessionCount": "100",
  "maxTransactionCount": "500",
  "queueGuaranteed1MaxDepth": "20000",
  "queueGuaranteed1MinMsgBurst": 66000,
  "queueDirect1MaxDepth": "20000",
  "queueDirect1MinMsgBurst": "4",
  "queueDirect2MaxDepth": "20000",
  "queueDirect2MinMsgBurst": "4",
  "queueDirect3MaxDepth": "20000",
  "queueDirect3MinMsgBurst": "4",
  "queueControl1MaxDepth": "20000",
  "queueControl1MinMsgBurst": "6",
  "tcpCongestionWindowSize": "2",
  "tcpKeepaliveCount": "5",
  "tcpKeepaliveIdleTime": "3",
  "tcpKeepaliveInterval": "1",
  "tcpMaxSegmentSize": "1460",
  "tcpMaxWindowSize": "256",
  "elidingDelay": "0",
  "elidingEnabled": "false",
  "elidingMaxTopicCount": "256",
  "rejectMsgToSenderOnNoSubscriptionMatchEnabled": "false",
  "tlsAllowDowngradeToPlainTextEnabled": "true",
  "eventClientProvisionedEndpointSpoolUsageThreshold": {
     "setPercent": "80",
     "clearPercent": "60"
    }
  }
}
  3. Click Send.
  4. You can check the status of the request, use the GET Service Request method in the Postman collection using the id from the response. For more information, see Getting the Status of a POST command.

Deleting a Client Profile

You can perform this using our feature rich and consistent v2 REST API. See the Delete a client profile v2 REST API in Solace's REST API Reference for more information.

You can delete a client profile. Typically, you only want to delete a client as part of clean-up. To delete a client profile, follow these steps.

  1. The POST request would be to the URL, https://api.solace.cloud/api/v0/services/{serviceId}/requests/clientProfileRequests .

  2. In the POST URL, replace the {serviceId} variable with the identifier of the service where the client profile exists. In the body, specify the operationas delete and the name of the client profile that you want to delete in the clientProfileName properties. For example, we are deleting a profile called myClientProfile: 

    {
      operation": "delete",
      "clientProfile": {
        "clientProfileName": "myClientProfile"
      }
    }

  3. Click Send.

You should receive a 202 Accepted response confirming that the delete request was received. To confirm that the client profile was deleted, call the GET Client Profile request once more. The response should indicate that the client profile is not found.

You can check the status of the request, use the GET Service Request method in the Postman collection using the id from the response. For more information, see Getting the Status of a POST command.

Client Profile Settings for the PubSub+ Cloud REST API

You can perform this procedure using our feature rich and consistent v2 REST API. See the Update a client profile v2 REST API in Solace's REST API Reference for more information.

You can specify settings for the client profile. To do so, you use the same endpoint, but specify additional properties as parameters. If a JSON property is not specified, the default value for the setting is used.

To send a request with all the settings, you send a request to https://api.solace.cloud/api/v0/services/{serviceId}/requests/clientProfileRequests.

For example, to send a request to configure all settings, it would look like the following: 

{
"clientProfile": {
	"id": "default",
	"clientProfileName": "default",
	"allowGuaranteedMsgSendEnabled": "true",
	"allowGuaranteedMsgReceiveEnabled": "true",
	"allowUseCompression": "true",
	"replicationAllowClientConnectWhenStandbyEnabled": "true",
	"allowTransactedSessionsEnabled": "true",
	"allowBridgeConnectionsEnabled": "true",
	"allowGuaranteedEndpointCreateEnabled": "true",
	"allowSharedSubscriptionsEnabled": "true",
	"apiQueueManagementCopyFromOnCreateName": "",
	"apiQueueManagementCopyFromOnCreateTemplateName": "",					
	"apiTopicEndpointManagementCopyFromOnCreateName": "",
	"apiTopicEndpointManagementCopyFromOnCreateTemplateName": "",
	"serviceSmfMinKeepaliveEnabled": "false",
	"serviceWebInactiveTimeout": "30",
	"serviceWebMaxPayload": "1000000",
	"maxConnectionCountPerClientUsername": "100",
	"serviceSmfMaxConnectionCountPerClientUsername": "1000",
	"serviceWebMaxConnectionCountPerClientUsername": "1000",
	"maxEndpointCountPerClientUsername": "100",
	"maxEgressFlowCount": "100",
	"maxIngressFlowCount": "100",
	"maxSubscriptionCount": "1000",
	"maxTransactedSessionCount": "100",
	"maxTransactionCount": "500",
	"queueGuaranteed1MaxDepth": "20000",
	"queueGuaranteed1MinMsgBurst": 66000,
	"queueDirect1MaxDepth": "20000",
	"queueDirect1MinMsgBurst": "4",
	"queueDirect2MaxDepth": "20000",
	"queueDirect2MinMsgBurst": "4",
	"queueDirect3MaxDepth": "20000",
	"queueDirect3MinMsgBurst": "4",
	"queueControl1MaxDepth": "20000",
	"queueControl1MinMsgBurst": "6",
	"tcpCongestionWindowSize": "2",
	"tcpKeepaliveCount": "5",
	"tcpKeepaliveIdleTime": "3",
	"tcpKeepaliveInterval": "1",
	"tcpMaxSegmentSize": "1460",
	"tcpMaxWindowSize": "256",
	"elidingDelay": "0",
	"elidingEnabled": "false",
	"elidingMaxTopicCount": "256",
	"rejectMsgToSenderOnNoSubscriptionMatchEnabled": "false",
	"tlsAllowDowngradeToPlainTextEnabled": "true",
	"eventClientProvisionedEndpointSpoolUsageThreshold": {
		"setPercent": "80",
		"clearPercent": "60"
	},
	"type": "clientProfile"
	},
	"operation": "update"
}

Basic settings

These settings are commonly modified when creating a client profile are as follows:

clientProfileName (Profile Name)
The name of the client profile. The name can be up to 32 alphanumeric characters (case-sensitive) and can also include underscores and dashes.
allowGuaranteedMsgSendEnabled (Send guaranteed messages)
Allow clients assigned to the client profile to publish Guaranteed Messages (that is non-persistent or persistent messages). This option is enabled (true) by default .
allowGuaranteedMsgReceiveEnabled (Receive guaranteed messages)
Allow clients assigned to the client profile to bind to topic endpoints or queues. This option is enabled (true) by default.
allowTransactedSessionsEnabled (Use transacted sessions)
Transacted sessions (that is, local transacted sessions and/or XA Sessions) are supported by the Solace messaging APIs (e.g., JMS, Java, Java RTO, JCSMP, C, and .NET APIs messaging APIs). XA Sessions are only supported by the Solace JMS messaging API. This option is enabled (true) by default.
allowBridgeConnectionsEnabled (Connect as a bridge)
Allow for inter-connection between the Message VPN in the HA group to another HA group using DMR links. This option is enabled (true) by default.
allowUseCompression (Use Compression)
Allow client applications to transfer data using compression. This option is disabled (false) by default.
replicationAllowClientConnectWhenStandbyEnabled (Connect When Replication Standby)
Allow client applications to remain connected to the Message VPN with a Standby Replication state when the Message VPN Replication state changes from Active to Standby. This option is disabled (false) by default.
allowGuaranteedEndpointCreateEnabled (Allow client to create endpoints )
Allow client applications assigned to the client profile to create queues or topic endpoints. This option is enabled by default.
Optionally, you can specify to copy settings from an existing queue or topic endpoint:
  • apiQueueManagementCopyFromOnCreateName (Copy settings from queue name): The name of the queue to copy the settings from
  • apiQueueManagementCopyFromOnCreateTemplateName (Copy settings from queue template): The name of the queue template to copy the settings from
  • apiTopicEndpointManagementCopyFromOnCreateName (Copy settings from topic endpoint name): The name of the topic endpoint to copy the settings from.
  • apiTopicEndpointManagementCopyFromOnCreateTemplateName (Copy settings from topic endpoint template): The name of the topic endpoint template to copy the settings from.

When a client using a Solace messaging API dynamically creates an endpoint, its configuration is determined first by those endpoint properties and provision flags that the client can provide with the API  to create a queue or topic endpoint. Any remaining endpoint parameters to be configured are then filled by the values specified in the copy settings from the specified queue or topic endpoint. 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.

Advanced Profile Settings

These are advanced settings to further configure messaging settings for client applications.

allowSharedSubscriptionsEnabled (Add Shared Subscriptions)
Because allowing indiscriminate access to MQTT and SMF shared subscriptions is a potential security issue (where a client could join a shared subscription and siphon off a portion of the traffic), you can configure whether specific clients can use shared subscriptions. This option is enabled (true) by default.
Allowing shared subscriptions is an all or nothing setting. This means that clients permitted to use shared subscriptions are allowed to subscribe to all shared subscriptions in the Message VPN. If you want to control access to specific shared subscriptions, you can use an ACL to configure a list of share names that are permitted (or denied) and then associate it with a client profile.
elidingEnabled (Enable Message Eliding)
Eliding allows you to define a custom per-topic rate for client applications so they can effectively consume relevant messages, rather than queuing up outdated messages. For example, when eliding is configured, clients could receive direct messages for their topic subscriptions at a rate of at most five per second, per topic – even though the source is publishing updates at a much higher rate. This option is disabled (false) by default.
elidingDelay [Eliding Delay (ms)]
The amount of time to delay the delivery of messages to a client after the initial message has been delivered. You can specify a value from 0-6000 milliseconds. The default is 0.
elidingMaxTopicCount (Maximum Eliding Topics Per Client Connection)
The maximum number of topics the event broker service that can track for performing the eliding function on each client connection. You can specify a value from 1-320000. The default is 256.
maxConnectionCountPerClientUsername (Maximum client connections per client username)
For a given client profile, you can configure the maximum, permitted number of simultaneous client connections to the event broker service that can be made using the same client username. This limit applies to client connections using any supported service type. That is, this limit applies to all client connections regardless of whether they use Solace Message Format (SMF), Web transport, REST, MQTT, or AMQP protocols. The default is 100.
serviceSmfMinKeepaliveEnabled (Enable Minimum Keepalive Timeout for SMF)
You can choose whether to prevent the event broker service from enforcing the minimum keepalive timeout (serviceMinKeepaliveTimeout) on SMF connections using a boolean value. This option is disabled by default (false). To have the event broker service enforce the minimum keepalive timeout for XMF connections, set the value to true.
serviceMinKeepaliveTimeout (Minimum Keepalive)
The minimum period of time (in seconds) that the event broker service will tolerate inactivity on the client connection. The default is 30 and valid ranges are 3–3600.
This keepalive value is enforced for MQTT and SMF (Solace Message Format) connections. The keepalive timeout value is calculated based on the client provided timeout interval (3 x the keepalive interval for SMF, 1.5 x the keepalive interval for MQTT). For SMF clients, this minimum value is ignored when serviceSmfMinKeepaliveEnabled is set to false.
serviceSmfMaxConnectionCountPerClientUsername (SMF client connections per client username)
PubSub+ Cloud uses the Solace Message Format (SMF) as its underlying messaging transport protocol.
For the client profile, you can configure the maximum permitted number of simultaneous SMF client connections to the event broker that can be made using the same client username account. The default is 1000.
serviceWebMaxConnectionCountPerClientUsername (Web transport client connections per client username)
The maximum permitted number of simultaneous Web transport client connections to the event broker service that can be made using the same client username account. The default is 1000.
serviceWebInactiveTimeout [Web Transport - Inactive Timeout (sec)]
The number of seconds a Web client has to send a request before its session times out and be terminated for being inactive. The default is 30 seconds. For more information, see Configuring Inactivity Timeouts.
serviceWebMaxPayload [Web Transport - Maximum Web Transport Payload Size (B)]
Allows you to set the maximum transport payload size.
Solace Message Format (SMF) messages that are sent to a consuming Web client are contained within a Web transport message that the event broker sends in its HTTP response to that client. Each Web transport message that is sent can contain multiple SMF messages or partial SMF messages.
The maximum Web payload value sets the maximum number of bytes allowed in a single Web transport message (not including the header). This value determines the number of SMF messages that can be sent in a single HTTP response and the size of the Web transport message sent in the HTTP response. The value range is 300 to 10000000, in bytes. The default is 1000000 bytes.

SMF messages that are sent to a consuming Web client are contained within a Web transport message that the event broker sends in its HTTP response to that client. Each Web transport message that is sent can contain multiple SMF messages or partial SMF messages.

The maximum Web payload value sets the maximum number of bytes allowed in a single Web transport message (not including the header). This value determines the number of SMF messages that can be sent in a single HTTP response and the size of the Web transport message sent in the HTTP response.

Large SMF messages can be fragmented across Web transport messages to respect the value set for the maximum possible Web payload.

maxEndpointCountPerClientUsername (Maximum queues and topic endpoints created per client username)
The maximum number of durable and non-durable queues and topic endpoints that can be owned by the clients using the same client username within a client profile. The default is 100.
maxEgressFlowCount (Maximum outgoing flows per client)
The maximum number of egress flows (that is, Guaranteed Message client receive flows or consumer flows) that can be created by a single client associated with this client profile. The default is 100.
maxIngressFlowCount (Maximum incoming flows per client)
The maximum number of ingress flows (that is, Guaranteed Message client publish flows) that can be created by a single client associated with this client profile. The default is 100.
maxSubscriptionCount (Maximum subscriptions per client)
The maximum number of subscriptions for a single client in the client profile. When you set this option, consider the total maximum number of permitted topic subscriptions and the total maximum number of client connections for the type of event broker that is used. That is, to ensure reliable system performance, you must find the right balance for your network, while staying within the system limits mentioned. The balance is generally between allowing the creation of many client applications and allowing each client to add a large number of topic subscriptions. The default is 1000.
maxTransactedSessionCount (Maximum transacted sessions per client)
The maximum number of simultaneous transacted sessions and/or XA Sessions allowed for a single client associated with the client profile. The default is 100.
maxTransactionCount (Maximum transactions per client)
The total maximum number of simultaneous transactions (both local transactions and transactions within the XA transaction branches) allowed for a single client associated with the client profile. The default is 500.
tcpCongestionWindowSize (Initial TCP congestion window size)
The TCP initial congestion window size is used when starting up a TCP connection or on recovery from idle (that is, no traffic). This setting is the number of segments that TCP sends before waiting for an acknowledgment from the peer. Larger values of the initial window allows a connection to come up to speed more quickly. For further details, refer to RFC 2581.
Changing the TCP initial congestion window size from its default of 2 results in non-compliance with RFC 2581. Further, if this setting is set to a value too high, it may cause congestion in the network. Contact Solace before you attempt to change this TCP parameter.
tcpKeepaliveCount (TCP keep alive retry count)
The maximum number of keepalive probes (from 2 to 5 ) that TCP should send before dropping the connection. The default is 5.
tcpKeepaliveIdleTime (TCP keep alive idle time)
The time (from 3 to 120 seconds) a connection must remain idle before TCP begins sending keepalive probes. The default is 3.
tcpKeepaliveInterval (TCP keep alive interval)
The time (from 1 to 30 seconds) to set as the interval between individual keepalive probes. The default is 1.
tcpMaxSegmentSize (Maximum TCP segment size)
The TCP maximum segment size (MSS) used for client to the event broker service. The default is 1460.
tcpMaxWindowSize (Maximum TCP window size)
The TCP window size between the event broker service and the client.
If the maximum window size is set to less than the bandwidth-delay product, then the TCP connection operates below its maximum potential throughput. If the maximum window is set to less than about twice the bandwidth-delay product, then occasional packet loss causes the TCP connection to operate below its maximum potential throughput as it handles the missing acknowledgments and retransmissions. The default is 256.
Alternatively, if the TCP maximum window size is set too large, in the presence of a high offered load, TCP gradually increases its congestion window size until either:
  • the congestion window size reaches the maximum window size
  • packet loss occurs in the network
Initially, when the TCP congestion window size is small, the physical bandwidth-delay of the network acts as a memory buffer for packets in flight. But as the congestion window crosses the bandwidth-delay product, the buffering of in-flight packets moves to queues in event broker services and other equipment throughout the network. As the TCP congestion window continues to increase in size, these various equipment queues overflow, causing packet loss and TCP backoff.
rejectMsgToSenderOnNoSubscriptionMatchEnabled (Reject Messages to Sender On No Subscription Match Discard)
Set that NACKs should be returned for published Guaranteed messages that do not have Guaranteed message subscription matches. This option is disabled by default (false).
tlsAllowDowngradeToPlainTextEnabled (TLS Port: allow downgrading connection to plain-text)
Allow TLS/SSL encryption to protect the clients' credentials but don't encrypt the data that is transmitted after the clients are authenticated and authorized. This setting allows connecting client applications to request to downgrade of their TLS/SSL connections to the Message VPN to a plain-text connection, and if that Message VPN allows TLS/SSL connection downgrades, after the clientsʼ login handshake are finished, their connections are downgraded. This means that the clientsʼ authentication data is still encrypted, but the subsequent application data that is transmitted is sent as non-encrypted plain-text. This option is enabled by default (true).
eventClientProvisionedEndpointSpoolUsageThreshold [Provisioned Endpoint Spool Usage Alert Thresholds (%)]
Set the clear and raise threshold values that determine when to generate events for the percentage amount of the message spool used by all endpoints provisioned by clients for the given client profile. The following are set as subparmeters nested within eventClientProvisionedEndpointSpoolUsageThreshold:
clearPercent (Clear Percent)
The clear threshold value for the message spool usage (as a percentage). The default is 60.
setPercent (Raise Percent)
The raise threshold value for the message spool usage (as a percentage). The default is 80.
queueGuaranteed1MaxDepth (Priority Queues - G-1 Maximum Depth)
Set the egress queue maximum depth for Guaranteed Messages that represents the number of work units for the client priority queues. The valid range is 2 to 262144. The default is 20000. For more information about egress queues, see Client Egress Structure Overview. For more information, see Configuring Max Egress Queue Depths.
queueGuaranteed1MinMsgBurst (Priority Queues - G-1 Minimum Burst)
Set the minimum number of messages that must be on the Guaranteed Message queue before the queue’s depth is checked against the maximum depth setting (thereby allowing the queue to absorb a burst of large messages that exceeds the number of allowed work units). A valid range is 0 to 262144 with the default of 255. The value of 255 is recommended for memory usage optimized configurations, such as message applications; a value of 66000 is for WAN optimized configurations.
queueDirect1MaxDepth (Priority Queues - D-1 Maximum Depth)
Set the egress queue maximum depth for Direct Messages 1 [Class of Service (COS) 1] that represents the number of work units for the client priority queues. The valid range is 2 to 262144. The default is 20000. For more information about egress queues, see Client Egress Structure Overview. For more information, see Configuring Max Egress Queue Depths.
queueDirect1MinMsgBurst (Priority Queues - D-1 Minimum Burst Depth)
Set the minimum number of messages that must be on the Direct 1 (COS 1) queue before the queue’s depth is checked against the maximum depth setting (thereby allowing the queue to absorb a burst of large messages that exceeds the number of allowed work units). A valid range is 0 to 262144 with the default of 4. For more information about egress queues, see Client Egress Structure Overview.For more information, see Configuring Egress Queue Minimum Message Bursts.
queueDirect2MaxDepth (Priority Queues - D-2 Maximum Depth)
Set the egress queue maximum depth for Direct Messages 2 (COS 2) that represents the number of work units for the client priority queues. The valid range is 2 to 262144. The default is 20000. For more information about egress queues, see Client Egress Structure Overview. For more information, see Configuring Max Egress Queue Depths.
queueDirect2MinMsgBurst (Priority Queues - D-2 Minimum Burst Depth
Set the minimum number of messages that must be on the Direct 2 (COS 2) queue before the queue’s depth is checked against the maximum depth setting (thereby allowing the queue to absorb a burst of large messages that exceeds the number of allowed work units). A valid range is 0 to 262144 with the default of 4. For more information about egress queues, see Client Egress Structure Overview. For more information, see Configuring Egress Queue Minimum Message Bursts.
queueDirect3MaxDepth (Priority Queues - D-3 Maximum Depth)
Set the egress queue maximum depth for Direct Messages 3 [Class of Service (COS) 3] that represents the number of work units for the client priority queues. The valid range is 2 to 262144. The default is 20000. For more information about egress queues, see Client Egress Structure Overview. For more information, see Configuring Max Egress Queue Depths.
queueDirect3MinMsgBurst (Priority Queues - D-3 Minimum Burst Depth)
Set the minimum number of messages that must be on the Direct 3 (COS 3) queue before the queue’s depth is checked against the maximum depth setting (thereby allowing the queue to absorb a burst of large messages that exceeds the number of allowed work units). A valid range is 0 to 262144 with the default of 4. For more information about egress queues, see Client Egress Structure Overview. For more information, see Configuring Egress Queue Minimum Message Bursts.
queueControl1MaxDepth (Priority Queues - C-1 Maximum Depth)
Set the egress queue maximum depth for Control 1 that represents the number of work units for the client priority queues. The valid range is 2 to 262144. The default is 20000. For more information about egress queues, see Client Egress Structure Overview.
queueControl1MinMsgBurst (Priority Queues - C-1 Minimum Burst Depth)
Set the minimum number of messages that must be on the Direct 1 (COS 1) queue before the queue’s depth is checked against the maximum depth setting (thereby allowing the queue to absorb a burst of large messages that exceeds the number of allowed work units). A valid range is 0 to 262144 with the default of 4. For more information about egress queues, see Client Egress Structure Overview. For more information, see Configuring Egress Queue Minimum Message Bursts.