...
| Code Block | ||
|---|---|---|
| ||
<buses>
<bus name="sample-bus" descriptor="${myBusDescriptor::loopback://mybus">
<channels>
...
</channels>
</bus>
</buses> |
| Anchor | ||||
|---|---|---|---|---|
|
The following properties are common to all bus implementations (unless specifically noted otherwise) and can be specified in a bus descriptor either as parameters in a descriptor URL or as properties in the buses' configuration settings when specified in its decomposed form.
...
| Code Block |
|---|
<model>
<!-- Apps will reference the buses they use in their messaging config -->
<apps>
<app name="sample-app" mainClass="com.sample.SampleApp">
<messaging>
...
<messaging>
<!--
<performDuplicateChecking>true</performDuplicateChecking>
</app>
</apps>
</model> |
The following table summarizes AEP Engine configuration properties that have an impact on duplicate detection:
| Config Property | Default | Description |
|---|---|---|
setOutboundSequenceNumbers | true | Enables setting of outbound sequence numbers on send from the application's AEP Engine. When disabled a sequence number of 0 will be set on all outbound sends meaning that downstream receivers will not perform duplicate filtering for sends from this application. See setOutboundSequenceNumbers in the DDL Config Reference |
performDuplicateChecking | true | Whether or not the applications AEP Engine will filter duplicates based on received sequence numbers. An AEP Engine uses the hashcode of the engine name as the sender id. See performDuplicateChecking in the DDL Config Reference |
sequenceUnsolicitedSends | long | Whether to tag sequence numbers on unsolicited sends. This property can be enabled for applications that only perform sends in an unsolicited fashion and will never send a message from a message handler.
In short, enabling this mode of operation is really only applicable for gateway applications that use the application in purely unsolicited sending capacity. In most cases, applications will instead elect to use sequenceUnsolicitedWithSolicitedSends described below. See sequenceUnsolicitedSends in the DDL Config Reference |
sequenceUnsolicitedWithSolicitedSends | int | Indicates that unsolicited sends calls should result in injecting the send operation into the engine's input queue to sequence the send with respect to inbound event processing in the context of an AEP transaction. This avoids the possibility of sequencing errors with respect to outbound messages being concurrently sent by message handlers. See sequenceUnsolicitedWithSolicitedSends in the DDL Config Reference |
HA Considerations
It is worth noting that for a cluster application only the primary instance of the application establishes message bus connections. In the event of a failure, a backup member will be elected and reestablish messaging connections. From a programming standpoint, this has the biggest impact on applications using the EventSourcing HA Policy as it means that even though their handlers are being invoked message channels will not have been established for the applications.
...
| Anchor | ||||
|---|---|---|---|---|
|
As mentioned before, the X runtime ensures that the serialization and sending of messages through the underlying message bus binding (transport) for messages sent through an AEP engine using only solicited sends operates in a single threaded manner. In other words, for an application performing only solicited sends, the underlying bus binding does not have to be configured to be safe for concurrent sends. However, if an application performs unsolicited sends concurrently using more than one thread or performs unsolicited and solicited sends concurrently, then the X runtime needs to be configured to ensure thread safety for such concurrent sends. How one configures the system for such safety depends on the type of concurrent sends being done by the application
Only Concurrent Unsolicited Sends
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
| Code Block | ||
|---|---|---|
| ||
<buses>
<bus name="sample-bus" descriptor="activemq://localhost:61616&enable_concurrent_sends=true">
<channels>
...
</channels>
</bus>
</buses> |
Concurrent Solicited and Unsolicited Sends
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
| Code Block |
|---|
<model>
<!-- Apps will reference the buses they use in their messaging config -->
<apps>
<app name="sample-app" mainClass="com.sample.SampleApp">
<messaging>
...
<messaging>
<!--
<sequenceUnsolicitedWithSolicitedSends>true</sequenceUnsolicitedWithSolicitedSends>
</app>
</apps>
</model> |
Creating Messages For Send
...