You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Document TranslateReplyToAddressForFailedMessages for the bridge (#6814)
* Document TranslateReplyToAddressForFailedMessages for the bridge
* Bridge does not support same logical endpoint on both sides
* Apply suggestions from code review
Co-authored-by: Jo Palac <[email protected]>
* Documented `TranslateReplyToAddressForFailedMessages` for only the messaging bridge versions where it is available
* fix integration tests
* update review date
---------
Co-authored-by: Jo Palac <[email protected]>
Co-authored-by: Jo Palac <[email protected]>
Copy file name to clipboardExpand all lines: nservicebus/bridge/configuration.md
+9-2Lines changed: 9 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -2,7 +2,7 @@
2
2
title: Bridge configuration options
3
3
summary: Configuration options for the messaging bridge.
4
4
component: Bridge
5
-
reviewed: 2023-07-04
5
+
reviewed: 2024-09-05
6
6
---
7
7
8
8
## Hosting
@@ -21,6 +21,11 @@ If a logical endpoint communicates with other endpoints that use a different tra
21
21
22
22
snippet: endpoint-registration
23
23
24
+
> [!NOTE]
25
+
> Having the same logical endpoint running on both transports is not supported. The bridge will throw an exception if an endpoint is registered on more than one transport.
26
+
>
27
+
> If a duplicate endpoint it is not registered with the bridge, any messages it sends that need to be forwarded across the bridge will fail and get sent to the [bridge error queue](#recoverability-error-queue).
28
+
24
29
## Registering publishers
25
30
26
31
When NServiceBus discovers a message handler in an endpoint for an event, it automatically subscribes to this event on the transport. The publisher itself is not aware of this, since it does not receive a notification when a subscriber subscribes to an event. This represents a challenge for the bridge.
@@ -115,7 +120,7 @@ If a message fails while it is being forwarded to the target transport, the foll
115
120
116
121
The error queue used by the bridge is named `bridge.error` by default. Note that the default `error` queue used by other platform components can not be used to enable bridging of the system-wide error queue since a bridged queue may not be used as the error queue. See the documentation around [bridging platform queues](#bridging-platform-queues) for more details.
117
122
118
-
A different error queue may configured as follows:
123
+
A different error queue may be configured as follows:
119
124
120
125
snippet: custom-error-queue
121
126
@@ -142,6 +147,8 @@ snippet: platform-bridging
142
147
> [!WARNING]
143
148
> The endpoint name used when creating a `BridgeEndpoint` is case-sensitive, even if one or both transports don't require it. This is to accommodate all transports, some of which require a case-sensitive endpoint name. More details can be found on [this issue](https://github.com/Particular/NServiceBus.MessagingBridge/issues/175).
144
149
150
+
partial: failed-messages
151
+
145
152
### Audit queue
146
153
147
154
Special considerations are required for the audit queue due to potentially high message volume. For example, a [dedicated ServiceControl audit instance](/servicecontrol/audit-instances/) could be created for each bridged transport, to make audit ingestion more efficient.
By default, when the bridge transfers a message to the ServiceControl error queue it will not attempt to translate the [`NServiceBus.ReplyToAddress`](/nservicebus/messaging/headers.md#messaging-interaction-headers-nservicebus-replytoaddress) message header.
4
+
This means that endpoints only need to be registered with the bridge if they are directly involved with messages transferred between transports.
5
+
The drawback is that if an endpoint is moved to a different transport, then any failed messages from that endpoint that perform a `ReplyTo` operation as part of the handler logic, cannot be retried since the value in the `NServiceBus.ReplyToAddress` header is unreachable.
By default, when the bridge transfers a message to the ServiceControl error queue it will not attempt to translate the [`NServiceBus.ReplyToAddress`](/nservicebus/messaging/headers.md#messaging-interaction-headers-nservicebus-replytoaddress) message header.
4
+
This means that endpoints only need to be registered with the bridge if they are directly involved with messages transferred between transports.
5
+
The drawback is that if an endpoint is moved to a different transport, then any failed messages from that endpoint that perform a `ReplyTo` operation as part of the handler logic, cannot be retried since the value in the `NServiceBus.ReplyToAddress` header is unreachable.
6
+
7
+
This behavior can be changed by configuring the bridge to translate the `NServiceBus.ReplyToAddress` message header for failed messages.
> Since any endpoint can generate a failed message, enabling translation of the `NServiceBus.ReplyToAddress` header requires that all endpoints are registered with the bridge.
13
+
> Message that fail during bridge address translation due to unknown endpoints will be moved to the `bridge.error` queue.
14
+
15
+
> [!NOTE]
16
+
> Translating the `NServiceBus.ReplyToAddress` message header for failed messages will become the default behavior in a future major version of the bridge.
0 commit comments