...
When a message is sent through the solace binding SMA metadata is sent with the message to assist receivers in determining how to deserialize and dispatch the message. By default, the solace binding sends messages using the V1 version of metadata to ensure that older receivers (pre-Talon 1.8.396) can deserialize messages. The difference between the V1 and V2 metadata is that the V2 encodes the message type (prior to the introduction of V2 metadata receivers needed to introspect the serialized message content and use the xRogType field encoded in the message).
| Tip |
|---|
If you know that there will be no downstream receivers using a version prior to 1.8.396, you can set |
Other settings
| Property name | Default | Description |
|---|---|---|
set_key_on_receipt | false | sets the Topic on a per-message basis. This is accessed via `message.getMessageKeyAsRaw` |
| provision_queue | true | allows solace to create queues on your behalf. If you disable this, you will have to create the queue's manually |
| queue_name | N/A | limits the queue that your application will read. |
Orphan Subscription Checks
When a Solace message bus binding has a queue name specified it is capable of issue guaranteed subscriptions against that queue. When a binding is started it is possible that there may already be existing subscriptions on the queue that don't match those that the application is issuing. Such subscriptions are considered to be 'orphan' subscriptions - presumably, those left over leftover from an early session that were was not removed.
The following policy can be configured to check for orphan subscriptions
| Policy | Desecription Description |
|---|---|
| None | With this policy, the appliance is not queried for subscriptions This is the default policy |
| Ignore | With this policy enabled the appliance is queried for subscriptions, but no action is taken other than tracing the orphans orphan's subscriptions at the info level. One other difference between |
| LogExceptionAndContinue | With this policy enabled the appliance is queried for subscriptions and if orphands orphans are found an exception is logged. |
| NoOrphan | With this policy enabled the appliance is queried for subscriptions and an exception is thrown from the message binding start method. |
Configuration
To check for existing subscription subscriptions SEMP must be enabled for the binding to retrieve the list of subscriptions over the messaging connection. The following provider properties must be specified on the bus descriptor to perform subscription checks:
| Property | Usage | Default | Description |
|---|---|---|---|
| enable_semp | optional | false | Property controlling whether or not Solace semp over messaging requests are enabled. Controls whether or not semp over messaging requests are enabled. This property must be enabled in order to query the solace appliance for existing subscriptions. This requires that the appliance has semp over messaging-enabled and that the user is authorized to make semp requests. |
| orphan_subscription_check | optional | None | Property controlling the orphan subscription check policy. This policy controls checks for orphaned Guaranteed subscriptions done when the solace binding is started. The check for orphaned is performed after the bindings subscription are created, but just before messaging is started. The solace appliance is queried for the list of Guaranteed subscriptions on the Queue and compared to the subscriptions that were issued. Any subscriptions on the queue that were not issued by the binding are deemed to be orphans. When using a policy other than |
| semp_version | recommended | soltr/7_1_1 | The version of semp requests must match that supported by the messaging appliance. If this property is not set semp requests will be retried using the version reported in the error response if a version mismatch is detected. Setting this property correctly avoids the need to make the initial request to determine the semp version. |
| semp_request_timeout | recommended | 10000 | Property controlling what timeout to use for semp requests in milliseconds. It is recommended that you test against your appliance and application under load to ensure that the default timeout of 10 seconds is sufficient. |
| subscription_validator | unsupported | - | This is a legacy property that allows the an application registered callback to perform additional subscription validation. This should only be used on guidance for Neeve support. |
NOTE: SEMP operations are currently an experimental feature. Enabling semp is not recommended in production without rigorous end user testing, and it should be noted that solace could drop support for SEMP over messaging in the future. Reliance on SEMP operations may also limit the ability to connect to solace appliance versions that don't have a compatibles SEMP model....
...
| Property | Usage | Default | Description |
|---|---|---|---|
| enable_semp | optional | false | Property controlling whether or not Solace semp over messaging requests are enabled. Controls whether or not semp over messaging requests are enabled. This property must be enabled in order to query the solace appliance for existing subscriptions. This requires that the appliance has semp over messaging-enabled and that the user is authorized to make semp requests. |
| enforce_max_bind_count | optional | 0 | Can be set to a positive value to enforce match against a provisioned queue's max bind count. When set the binding will issue a SEMP request when the binding is started to check that the max bind count for the provisioned queue matches the value of this property. This can be used to ensure that exclusive connectivity to the queue when it is provisioned with a max bind count of 1, to disallow 2 application instances for concurrently connecting to a queue. This property is ignored if the binding is not configured with a queue or if the value of the property is less than or equal to 0. |
...
This section describes how to send to Talon applications from non-Talon applications and from Talon application applications to non-Talon applications over solace. This is an uncommon usecase use-case ... see Sending and Receiving Messages for information on sending from within a Talon application. The sections below utilize the ADM generated messages for convenience, but this is not required. For example, if you your messages are encoded in protobuf (or Xbuf) you could encode/decode the message yourself without using ADM. One such example of this might be if you were using C and generated a protobuf message from the IDL generated by ADM.
...