Nservicebus: Patch old versions of NSB to include logical endpoint information in the subscribe messages

[SzymonPobiega]

This will streamline integration with V6 in MSMQ scale-out scenarios. Currently when V5 subscribes to an event published by a V6 scaled-out endpoint, that endpoint needs to have distributor in front of it.

Background

In V5 the only scale-out option for MSMQ is the distributor. In that mode workers, when subscribing, send Subscribe messages containing the type they want to subscribe and, in NServiceBus.ReplyTo header, the address of the distributor. This was we ensure that each event is send only once (to the distributor). If the workers would have subscribed with their own addresses, each of them would have got its own copy of the event.

In V6 we can have a non-distributor cluster of MSMQ instances. The distribution happens on sender side is the sender is a V6 endpoint. Instances of such a cluster subscribe with their own address (in the SubscriberTransportAddress header) and also include the logical endpoint name (in the SubscriberEndpoint header). This way the V6 publisher can figure out that he has multiple subscriptions belonging to same logical endpoint and send each even to a single instance.

V5 publisher would ignore SubscriberTransportAddress and SubscriberEndpoint headers and only process ReplyTo which would result in each instance of the cluster getting a copy of event. To prevent this from happening, we advice to put a distributor in front of a V6 cluster _if that cluster is a subscriber for events published by a V5 endpoint_.

Proposed change

With this change users would have a choice when upgrading scaled-out MSMQ publishers to V6:

• keep the distributor around
• upgrade subscribers to latest 5 (assuming upgrading to 6 is not an option)

NOTE: This won't affect command messages so if V5 endpoint sends commands to a scaled-out endpoint, distributor will still be need when the latter is upgrade to V6. V5 can't and won't be able to distribute commands.

Plan of attack

• Add additional headers (SubscriberTransportAddress and SubscriberEndpoint) to V5 subscribe messages.
• Test via https://github.com/Particular/NServiceBus.ScenarioTests

[timbussmann]

@SzymonPobiega can you describe what exactly would be required for v5 endpoints to be able to properly subscribe to v6 endpoints?

[danielmarbach]

Thought: In those kinds of scenarios a graphic illustrating the various moving parts might be helpful

[SzymonPobiega]

@timbussmann added plan of attack that outlines the changes. As for the plan to validate if they work, I think a sample would be a better idea then the Scenario tests.

[SzymonPobiega]

@danielmarbach I'll try to explain it as a sequence of steps.

[SzymonPobiega]

@timbussmann @danielmarbach updated the description with a detailed explanation.

[bording]

Given that even if we do this, you'll still need the distributor if the endpoint sends commands, does it seem worth it to do this? Overall it complicates the story. Instead of just saying "you need the distributor when v5 -> scaled out v6", we would now have to explain all the caveats around when you might or might not have to have it.

[timbussmann]

@Particular/nservicebus-maintainers Since that maintainer-prio tag wasn't added by maintainers, we should quickly review whether this label is still valid here.

At first glance I tend to agree with @bording : The value of these additional headers which allows to remove the distributor for v5 endpoints only works in very specific setups and it quickly becomes more complicated when more than just subscriptions are involved.

[danielmarbach]

My hunch is this needs a proper TF and should not be handled as Maintainer Prio

[bording]

@danielmarbach I'm still not convinced this change is worth making, not enough benefit to be worth the effort.

[andreasohlund]

Seems to me that this doesn't fully solve the issue (we can't guarantee that users run on the latest patch) so we would have to write/provide the same amount of guidance.

I guess that the motivation could be that v6 that doesn't want to run a distributor in front would now have a way to avoid it? (by making sure to upgrade the publisher cluster to latest v5)

This looks like something we can do after the release of v6?

[timbussmann]

since no real objections to @bording and my opinion were raised I'm closing this for the reasons mentioned above. Please feel free to reopen if you strongly disagree.