I am trying to configure NServicebus.MessagingBridge to bridge traffic between a rabbit transport and MSMQ endpoints running on a different machine using the latest 3.0.3 version of the MessagingBridge package. In this scenario, it doesn’t seem to be possible to correctly add an endpoint hosted on another machine.
When I instantiate the MSMQ endpoint instances, using the constructor:
var endpoint = new BridgeEndpoint("EndpointName", "EndpointName@Machine");
It results in a QueueAddress on the BridgeEndpoint that has the BaseAddress set, but without a machine value in the Properties dictionary. When this is later consumed in MsmqTransportInfrastructure.TranslateAddress it then gets suffixed with the current machine name, resulting in an endpoint name like EndpointName@Machine@CurrentMachine which fails to route.
The BridgeEndpoint constructors don’t appear to expose a way to instantiate it with a valid QueueAddress in this scenario, as the string queueaddress parameter gets passed directly to the internal QueueAddress baseaddress parameter.
Can anyone advise if I have missed something please?
We have a lot of endpoints, which all started on MSMQ. We are currently migrating them to Rabbit and have already moved a significant portion over. We still have some endpoints on MSMQ, a number of which are deployed to different machines to the machine we are deploying the bridge component to. We are using several MSMQ servers and we haven’t yet scheduled the upgrade of the remaining endpoints. We were previously using the community router implementation to handle this but decided to replace this with the NSB bridge package when we started upgrading our Rabbit endpoints to Net8 & NSB 9.
Then you would have a bridge on Server A and Server B to ensure successful communication between all the endpoints. Because in each scenario the bridge is local to the MSMQ server, you do not need to specify the @machine for the queue address.
I don’t think that is quite right. In our scenario, we have the old MSMQ queues for the migrated services on server C, which the bridge needs to be able to read from, so we have deployed the bridge there. The MSMQ endpoints on Server A and Server B are still addressing messages to the original MSMQ queues on Server C. The bridge doesn’t need to read from queues on server A or B, but ideally would be able to dispatch messages back to those endpoints, rather then needing differently configured bridge instances on servers A and B as well to allow the services now running on rabbit to send messages back to the older MSMQ services.
I’ve been able to work around the limitations of the exposed configuration api and get this working with a single bridge deployed to server C with the following code:
public static BridgeEndpoint Create(string endpointAddress)
{
var addressParts = endpointAddress.Split('@');
if (addressParts.Length > 1)
{
var endpoint = new BridgeEndpoint(addressParts[0]);
var fieldInfo = typeof(BridgeEndpoint).GetField("<QueueAddress>k__BackingField", BindingFlags.NonPublic | BindingFlags.Instance);
var queueAddress = new QueueAddress(addressParts[0], properties: new Dictionary<string, string> { { "machine", addressParts[1] } });
fieldInfo!.SetValue(endpoint, queueAddress);
return endpoint;
}
return new BridgeEndpoint(addressParts[0]);
}
Obviously this isn’t ideal, and I was hoping this would be something that would be available in the configuration api, as the comments in the constructor for BridgeEndpoint that accepts a queueAddress suggest that this should be possible.
I’ve been helping Jo investigate this and it looks like this is a bug on our end, we are doing some testing to verify this and will keep you posted on progress on a potential bug fix.