...
| Property Name | Default Value | Description | ||||||
|---|---|---|---|---|---|---|---|---|
| set_bus_and_channel_on_receipt | false | Controls whether the bus and channel name are set on received messages. Setting the channel and bus name on inbound messages incurs performance overhead. Performance sensitive applications should avoid enabling this property. | ||||||
| set_key_on_receipt | false | Controls whether the message key is set on received messages. Not all binding implementations transport the key on the wire, this property has no effect for bindings that don't transport the key. Setting the key on inbound messages incurs a performance overhead. Performance sensitive applications should avoid enabling this property. | ||||||
| set_sno_on_receipt | true | Controls whether the message sequence number is set on received messages. If set to false, then inbound messages surfaced to the AEP engine and application will not have the sequence number set regardless of whether the sender was configured to set sequence numbers in outbound messages or not (see Message Sequencing) Setting the sequence number on inbound messages incurs a slight performance overhead. Performance sensitive applications should avoid enabling this property. | ||||||
| enable_inbound_transport_headers | false | Controls whether transport headers are set in inbound messages Setting this parameter to true will cause the bindings, that support this functionality, to set transport specific headers in the metadata section of the inbound messages Not all binding implementations support transport header functionality. This property has no effect for such bindings. Setting the sequence number on inbound messages incurs a performance overhead. Performance sensitive applications should avoid enabling this property. Additionally, enabling such a functionality fosters a tighter coupling between the application and specific message bindings which is generally not a recommended practice | ||||||
| topic_starts_with_channel | true | Controls whether topic names start with the channel name for the bus. For bus bindings that support topic routing this property controls whether or not the resolved key is prefixed with the channel name. | ||||||
enable_concurrent_sends | false | Controls whether sends through the message bus binding can be performed concurrently using multiple threads | ||||||
additional_properties_file | false | Specifies the path to an external file that is used to load additional bus configuration properties. The external file format is a plain java Properties file. Properties specified in the external file will be merged into configuration property set for the bus. This file is loaded at runtime, so the file is retrieved from the local file system on the host where the configured XVM will run. |
...
| Note | ||
|---|---|---|
| ||
In an application that only performs solicited sends, the X runtime ensures that the serialization and sends through the underlying transport are done in a single threaded manner. However, when an application performs unsolicited sends using two or more concurrent threads or performs unsolicited sends concurrently with solicited sends, then the sends through the underlying transport are performed using multiple concurrent threads. By default, the X runtime is not configured for thread safety for such concurrent sends. See Concurrent Sends for more information on how to configure the X runtime for concurrent sends. |
...
The use of unsolicited sends introduces send concurrency related concerns. One of the concerns is the integrity of the sequence numbers in outbound messages - with concurrent sends, the system needs to ensure that the messages are transmitted on the wire in the same sequence as the setting of the sequence numbers on them. See Concurrent Sends for more information on how to configure the system for concurrent sends to ensure the integrity of the sequence numbers on the transmitted messages.
...
If the application is NOT performing solicited sends and is performing unsolicited sends concurrently using more than one thread, then the X runtime needs to be configured for concurrent send safety by enabling concurrent sends on the underlying message bus binding. This is done using the enable_concurrent_sends bus connection descriptor property. This configuration parameter can be set as follows and is applicable to all message bus bindings supported for use with the X Platform
...
If an application is performing concurrent solicited and unsolicited sends, then although configuring the underlying message bus binding for concurrent sends will also ensure correct send operation unless sequence numbers need to be set on messages sent using unsolicited sends (. Note that by default, sequence numbers are set for solicited sends and not set for unsolicited sends and, so, with those default sequencing related settings, just configuring the underlying message bus binding for concurrent sends will enable safety of concurrent unsolicited and solicited sends. However, if sequence numbers are desired in messages sent via unsolicited sends, then the sequenceUnsolicitedWithSolicitedSends configuration parameter should be used instead of the enable_concurrent_sends. Setting both these parameters is safe but not necessary. The following example shows how to enable concurrency for this scenario i.e. concurrent solicited and unsolicited sends with sequence numbers in both solicited and unsolicited sent messages
...
| Solicited Sends | Concurrent Unsolicited Sends | Sequence Number in Solicited Sends | Sequence Number in Unsolicited Sends | Configuration |
|---|---|---|---|---|
| No | Yes | N/A | Yes or No | enable_concurrent_sends |
| Yes | Yes | Yes | No | enable_concurrent_sends |
| Yes | Yes | No | Yes | enable_concurrent_sends |
| Yes | Yes | No | No | enable_concurrent_sends |
| Yes | Yes | Yes | Yes | sequenceUnsolicitedWithSolicitedSends |
...
Solicited Sends
As mentioned earlier, the AEP engine manages in-doubt messages across the entire cluster to ensure zero loss in its outbound message stream across fail overs and restarts. In the event of a fail over within a cluster or a fresh restart of the primary member of the cluster from its transaction log, the AEP engine recovers and retransmits "in-doubt" messages to ensure zero loss. This mechanism only applies to messages sent using solicited sends. For unsolicited sends, the application needs to participate in ensuring zero loss.
...